100 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Devin Foley	4b0e324c63	ci: activate the Docker context integrity gate for PRs (#12860) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Pull request CI runs through `pr.yml`, which pins the reusable `pr-trusted.yml` workflow by commit SHA, so `pr-trusted.yml` changes take effect only when the pin moves. > - PRs #12855 and #12858 added the `docker_context_integrity` job and wired it into the `verify` aggregate, but the pin still points at a commit from before them. > - Until the pin moves, a pull request that strips a committed Docker build input still merges green and breaks every post-merge image build. > - This pull request bumps the pin to the #12858 merge commit, the standard second step of every `pr-trusted.yml` change. > - The benefit is that the Docker context integrity gate now blocks merges, which closes out the 2026-09-04 image-publishing incident end to end. ## Linked Issues or Issue Description Refs #12855 and #12858 (the gate this activates) and #12769 (the incident that motivated it). **What happened?** The `docker_context_integrity` job exists on master but does not run on pull requests, because `pr.yml` pins `pr-trusted.yml` at `a0a78ee6`, which predates it. **Expected behavior** Pull requests run the gate, and the `verify` required check fails when a change strips a committed Docker build input. **Steps to reproduce** 1. Open any pull request before this change: the ci run shows no "Docker context integrity" job. 2. After this change, the job runs on every full-CI pull request and `verify` requires its result. **Paperclip version or commit** Pin moves from `a0a78ee60946a5f79f85b2bd0584fc766fae43bb` to `03609aa6` (the #12858 merge commit). **Deployment mode** GitHub Actions pull request CI. ## What Changed - `.github/workflows/pr.yml`: the `pr-trusted.yml` pin moves to the #12858 merge commit. One line. ## Verification - The pinned commit is master's current tip and contains the job, the `verify` wiring, and both probe revisions; its own CI (on #12855 and #12858) is fully green. - This PR's ci run itself executes the newly pinned workflow, so the gate's first live run is visible on this very pull request. ## Risks - Low. Identical mechanism to every previous pin bump. If the new lane misbehaves on some runner, reverting this one line restores the previous pin. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used Claude Fable 5 (Anthropic, model id `claude-fable-5`), extended thinking, agentic tool use in Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass (one-line pin bump; the pinned workflow's tests ran green on #12855/#12858) - [x] I have added or updated tests where applicable (covered by the pin tests updated in #12855) - [x] I have updated relevant documentation to reflect my changes (not applicable to a pin bump) - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-09-04 17:22:15 -07:00
Devin Foley	03609aa6ec	ci: keep traceability regression tests in the Docker build context (#12858) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - GitHub Actions builds the Docker images that ship Paperclip, and the image build re-runs the runner's committed-artifact checks. > - PR #12855 restored the capability-contract files that PR #12769's context slimming stripped, and image builds then progressed one step further in the chain. > - The next check, `check:runner-workflow-traceability`, access()es every regression test its spec names — `src/**/*.test.ts` files that the same slimming block also strips. > - Every image build since #12855 merged now fails there with ENOENT, so image publishing is still down. > - This pull request restores those files with one more narrow exception and teaches the context probe to derive the required paths from the spec itself. > - The benefit is that image publishing recovers, and the probe now covers this input class without a hand-maintained path list that could rot. ## Linked Issues or Issue Description Refs #12855 (first restoration from the same incident) and #12769 (the context-slimming change). **What happened?** After #12855 merged, every `Docker` workflow run on master still failed, now inside `check:runner-workflow-traceability`: `Error: ENOENT ... access '/app/packages/paperclip-runner/src/contracts/native-execution.test.ts'`. The check access()es all 29 regression tests named by `spec/evals/stress-workflow-traceability.json`; they are `src/**/*.test.ts` files, and the `packages/paperclip-runner/**/*.test.ts` ignore rule strips them from the build context. **Expected behavior** The Docker build context must contain every file the image build reads. The context-integrity probe must catch this class on the pull request, including inputs named dynamically by a spec. **Steps to reproduce** 1. Check out master after #12855. 2. Run `docker buildx build -f .github/docker-context-checks.Dockerfile .` with this PR's probe, or the real `Docker` workflow build. 3. Observe the ENOENT above; with this PR's `.dockerignore` exception, both pass. **Paperclip version or commit** `bb920fb8` (first post-#12855 failing image build) through master tip. **Deployment mode** GitHub Actions image builds (`docker.yml`), consumed by managed cloud deployments. ## What Changed - `.dockerignore`: re-include `packages/paperclip-runner/src/**/*.test.ts` and `.tsx` — the traceability spec references only files under `src`, so the remaining test exclusions stay. - `.github/docker-context-checks.Dockerfile`: new spec-driven existence walk that replicates the traceability check's own access() loop against the exact build context. The path list comes from the spec at probe time, so a future spec change is covered automatically; the check itself still runs only inside the real image build, where `dist/` exists. ## Verification - `docker buildx build -f .github/docker-context-checks.Dockerfile .` without the `.dockerignore` exception: fails with the exact production ENOENT (`src/contracts/native-execution.test.ts`). - Same command with the exception: passes end to end (all probe stages, including the drift checks from #12855). - Static re-sweep of the remaining image-build chain steps (`build:binary`, replay goldens, semantic-action catalog) against the ignore rules: their inputs are all in the context; cargo needs no `tests` directories (no crate declares an explicit `[[test]]` target). ## Risks - Low. The exception re-adds source test files to the build context only; image contents do not change (tests are neither compiled into the production output nor run in the image build — the check only requires that the referenced files exist). - The probe addition is one dependency-free Node one-liner. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used Claude Fable 5 (Anthropic, model id `claude-fable-5`), extended thinking, agentic tool use in Claude Code: GitHub Actions log forensics, spec-driven path inventory, and local docker buildx verification in both failing and fixed states. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass (the probe in both failing-before and passing-after states) - [x] I have added or updated tests where applicable (the spec-driven probe walk is the regression test) - [x] I have updated relevant documentation to reflect my changes (inline comments explain the invariant) - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-09-04 16:39:13 -07:00
Devin Foley	bb920fb859	ci: keep the Docker build context complete and guard it on every PR (#12855) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - GitHub Actions builds the Docker images that ship Paperclip, and downstream deployments consume the `-cloud` image variant on every master merge. > - PR #12769 slimmed the Docker build context with a broad `.dockerignore` block for `packages/paperclip-runner`, and the block also removed three files the image build itself reads. > - The image build re-runs the runner's generated-file drift checks, so it found no committed capability contract in the context and failed on every master commit after the merge. > - PR CI never runs those checks against the Docker context, so the pull request stayed green and the breakage only appeared post-merge, on every image build. > - This pull request restores the three files with narrow `.dockerignore` exceptions and adds a PR CI job that runs the drift checks against the exact Docker build context. > - The benefit is that image publishing works again now, and the next context-slimming regression fails the pull request instead of every post-merge image build. ## Linked Issues or Issue Description Refs #12769 (the context-slimming change that exposed this) and #12608 (which committed the generated contract outputs the image build checks). **What happened?** Every `Docker` workflow run on master failed from 2026-09-04 12:58Z onward, in both the `build-and-push` and `build-and-push-cloud` jobs. The failing step reported `Generated contract drift: generated/capability/capability-contract.md` from `check:capability-contract` inside `pnpm --filter @paperclipai/server build`. The committed contract file is current — regeneration on a full checkout is a no-op. The file was simply absent from the build context: the new `packages/paperclip-runner/**/*.md` ignore rule strips the committed drift-check outputs (`generated/capability/capability-contract.md`, `generated/capability/downstream-handoff.md`), and the `packages/paperclip-runner/docs` rule also strips `docs/capability-contract.md`, which `check:capability-inventory` reads next in the chain. No cloud image published for eight hours, which stalled every downstream deployment that consumes the canary images. **Expected behavior** The Docker build context must contain every file the image build reads, and a change that removes one must fail the pull request that introduces it, not every image build after the merge. **Steps to reproduce** 1. Check out master at any commit from `af3023f1` onward. 2. Run `docker buildx build -f .github/docker-context-checks.Dockerfile .` (the probe added by this PR), or start the real `Docker` workflow build. 3. Observe `Generated contract drift: generated/capability/capability-contract.md` — while `node packages/paperclip-runner/scripts/generate-capability-contract.mjs --check` passes on the same checkout outside Docker. **Paperclip version or commit** `d593463ab` (master tip at diagnosis time; first failing commit `af3023f1`). **Deployment mode** GitHub Actions image builds (`docker.yml`), consumed by managed cloud deployments. ## What Changed - `.dockerignore`: narrow exceptions (last match wins) re-include the committed drift-check outputs (`!packages/paperclip-runner/generated/**`) and the inventory check's documentation input (`!packages/paperclip-runner/docs/capability-contract.md`). Every other exclusion from #12769 stays: no crate declares an explicit `[[test]]` target, so cargo builds without the `tests` directories, and the image build chain never runs the excluded smoke scripts. - `.github/docker-context-checks.Dockerfile` (new): a small probe that COPYs the real build context — identical `.dockerignore` semantics — and runs the dependency-independent drift checks inside it (`generate-capability-contract.mjs --check`, `check-capability-inventory.mjs`). ajv installs in an isolated directory for schema validation only; codegen checks such as `generate-protocol-schema-module` stay out because their emitted bytes vary with the ajv release and would raise false drift alarms outside the locked dependency tree. - `.github/workflows/pr-trusted.yml`: new `docker_context_integrity` job builds the probe on every full-CI pull request, and the existing `verify` aggregate now requires its result, so the guard gates merges through the same required check as the other lanes. - Activation note: `pr.yml` pins `pr-trusted.yml` by commit SHA, so the new job starts gating pull requests after the usual follow-up `ci: activate ...` pin bump once this merges. The `.dockerignore` fix needs no activation — `docker.yml` reads it directly, so image builds recover on the first master commit after this merges. ## Verification - `docker buildx build -f .github/docker-context-checks.Dockerfile .` on master (before the `.dockerignore` fix): fails with the exact production error, `Generated contract drift: generated/capability/capability-contract.md`. - Same command with the `.dockerignore` exceptions applied: passes, which also proves BuildKit honors the `!` exceptions, including the file inside the excluded `docs` directory. - `node scripts/generate-capability-contract.mjs --check` on a full checkout: passes both before and after, which confirms the committed contract was never stale — only missing from the context. - Static sweep of every script in the image build chain (`build`, `build:typescript` and their `check:*` steps) against the ignore rules: the three restored files are the only build inputs the #12769 block strips. - YAML for `pr-trusted.yml` lints clean. ## Risks - Low. The `.dockerignore` exceptions only re-add three committed files to the build context; image contents do not change otherwise. - The probe job adds one context transfer and two Node scripts per full-CI pull request run (about one to two minutes, no dependency install beyond one isolated ajv package). - The `verify` aggregate now also requires the new job, mirroring the existing pattern for the other lanes; on non-full-CI runs the job skips and `verify` asserts the skip, unchanged from how the other lanes behave. - The new job only takes effect for pull requests after a follow-up pin bump in `pr.yml` (same two-step flow as every `pr-trusted.yml` change). > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used Claude Fable 5 (Anthropic, model id `claude-fable-5`), extended thinking, agentic tool use in Claude Code: GitHub Actions log forensics to isolate the failing check, static analysis of the build-chain scripts against the ignore rules, and local docker buildx runs to reproduce the failure and verify the fix. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass (the docker probe, both failing-before and passing-after; the drift checks themselves on a full checkout) - [x] I have added or updated tests where applicable (the probe IS the regression test for this class) - [x] I have updated relevant documentation to reflect my changes (inline comments in `.dockerignore` and the probe explain the invariant) - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-09-04 15:35:10 -07:00
Devin Foley	54dd0f4868	feat(agents): grant new agents hire permission by default (#12814) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Agent permissions control which agents can create or hire other agents (`canCreateAgents`) > - Today only CEO-role agents get this permission by default; every other agent starts without it > - Teams that want agents to delegate and build out their own teams must flip the toggle on each hire, and most operators want delegation to work out of the box > - This pull request makes `canCreateAgents` default to enabled for new standard-trust agents, while low-trust agents keep a disabled default > - The benefit is that agent teams can grow without per-agent permission toggling, while low-trust containment and checkout protection stay intact ## Linked Issues or Issue Description Related (not fixed by this PR): #8064 also decouples an authority from `agents:create`. **Subsystem affected** Server agent permissions (`server/src/services/agent-permissions.ts`), authorization (`server/src/services/authorization.ts`), the shared `agentPermissionsSchema` validator, and the UI trust-preset helper. **Problem or motivation** New agents cannot hire other agents unless an operator enables `canCreateAgents` on each one. Only CEO-role agents get the permission by default. This blocks delegation-by-default workflows. Operators must toggle the permission for every hire. **Proposed solution** Default `canCreateAgents` to `true` for newly created agents. Apply and persist the default at creation only. Stored rows without an explicit value stay fail-closed at read and enforcement time. Keep the default at `false` when the agent's permissions record marks it low-trust (the `low_trust_review` preset or a trust boundary). Explicit values always win. Decouple `tasks:manage_active_checkouts` from `canCreateAgents` so the default-on flag does not let a peer agent write over another agent's checked-out issue. **Alternatives considered** Granting the default only at the route layer would leave stored rows and enforcement out of sync. Keeping the checkout authority coupled to `canCreateAgents` would void the active-checkout write protection once the flag is default-on. A per-company setting adds configuration surface without a clear need; explicit per-agent overrides already exist. **Roadmap alignment** Governance and trust-preset work already separates standard-trust from low-trust agents. This change follows that line: capability by default for standard trust, containment by default for low trust. ## What Changed - `normalizeAgentPermissions` now takes a `create`/`stored` context. Creation writes get the new default: enabled unless `permissionsImplyLowTrust()` detects the low-trust review preset or a trust boundary. Stored rows without an explicit value normalize to disabled (fail-closed). The role parameter is gone. - `agentPermissionsSchema` no longer injects `canCreateAgents: false` when the field is omitted. The server-side default applies instead. - `authorization.ts` normalizes raw agent rows for `agents:create`, so enforcement matches what the API reports for legacy rows. - `tasks:manage_active_checkouts` no longer rides on `canCreateAgents`. CEO role, explicit grants, and the manager chain remain the paths. - `agents:create` is denied outright inside any resolved low-trust execution context (agent, project, issue, or run policy). The default-on flag can never reach the legacy creator allow there. - The UI trust-preset helper sets `canCreateAgents: false` when an agent is switched to the low-trust preset, instead of carrying the old value forward. - `doc/CLI.md` describes the new default for `teams install`. - Tests pin the default matrix (standard, low-trust, explicit overrides) on the server and in the UI helper. ## Verification - `cd server && npx vitest run src/__tests__/agent-permissions-service.test.ts src/__tests__/agent-permissions-routes.test.ts src/__tests__/low-trust-red-team-routes.test.ts src/__tests__/authorization-service.test.ts` — 143 tests pass. - Broader sweep: 18 suites that touch `canCreateAgents` (hire, pending-approval, teams catalog, portability, built-in agents, plugin-managed agents) pass locally. - `cd ui && npx vitest run src/lib/trust-policy-ui.test.ts src/components/TrustPresetSection.test.tsx src/pages/NewAgent.test.tsx src/pages/Agents.test.tsx` — passes. - Typecheck is clean for the changed files in `packages/shared`, `server`, and `ui`. ## Risks - Behavioral shift: agents created after this change persist `canCreateAgents: true` unless low-trust. Pre-existing agents keep their stored value. Legacy or malformed permission records without an explicit value stay fail-closed at read and enforcement time; they never gain the authority retroactively. - Low-trust runs can no longer create agents at all, even when the agent carries an explicit `canCreateAgents: true`. Before this change, that combination could hire. The red-team suite and a new authorization test pin the denial. - Narrowing: a non-CEO agent with `canCreateAgents: true` loses implicit `tasks:manage_active_checkouts`. The manager chain and explicit grants still provide it. This narrowing is deliberate; without it, the default-on flag would let any peer bypass active-checkout write protection. - No migrations. No API shape changes. Low-trust defaults are covered by the red-team regression suite. ## Model Used - Claude Fable 5 (`claude-fable-5`), Anthropic — via Claude Code CLI with extended thinking and tool use (code search, editing, local test execution). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-09-03 23:26:51 -07:00
Devin Foley	c38b59484c	fix(ui): remove the Account badge and version line from the account menu (#12818) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The web UI has a sidebar account menu that opens from the user's name in the lower left > - The menu header shows an "Account"/"Local" badge and a "Paperclip <sha>" (or "Paperclip v<version>") build line next to the user's identity > - These labels add noise to the header and repeat information that is available elsewhere: the email line already shows the sign-in state, and the opt-in "Server" debug section in the same menu shows the running commit > - This pull request removes the badge and the build line so the header shows only the user's name and email > - The benefit is a cleaner account menu that shows only identity information ## Linked Issues or Issue Description No existing issue. Related: #9637 (closed) added the source-sha rendering that this PR removes from the menu header. Description follows the enhancement template: **What existing behavior does this improve?** The sidebar account menu popover. Its header shows the user's name, an "Account" or "Local" badge, the email, and a build identifier line ("Paperclip <short sha>" with branch/commit links for source builds, or "Paperclip v<version>" for release builds). **Current behavior** The popover header mixes identity information with deployment and build metadata. The badge and the version line take space and do not help daily use. **Proposed behavior** The popover header shows only the user's name and email. Build information stays available in the "Server" section at the bottom of the same menu when the server-info debug view is enabled in experimental instance settings. **Reason and benefit** Less visual noise in a menu that users open often. No information is lost: sign-in state is clear from the email line, and the running commit remains visible through the server-info debug view. **Breaking changes** None. The `SidebarAccountMenu` components no longer accept the `serverGit` and `version` props; both call sites in the two `Layout` variants are updated in this PR. ## What Changed - `ui/src/components/SidebarAccountMenu.tsx` and `SidebarAccountMenu.production.tsx`: remove the "Account"/"Local" badge and the full version block (source-build branch/commit links and the release-version fallback); drop the now-unused `serverGit`/`version` props, the sha-parsing helper, and the `Badge` import - `ui/src/components/Layout.tsx` and `Layout.production.tsx`: stop passing the removed props at all four call sites - `ui/src/components/SidebarAccountMenu.test.tsx`: delete the source-build sha test; the sign-out test now pins that the popover contains neither "Account" nor "Paperclip v" - `ui/storybook/stories/navigation-layout.stories.tsx`: stop passing the removed `version` prop in the account-menu story ## Verification - `pnpm vitest run ui/src/components/SidebarAccountMenu.test.tsx ui/src/components/Layout.test.tsx` — 36 tests pass - `tsc --noEmit` for the `ui` package passes - Manual: open the app, click your name in the lower left. The popover header shows only name and email. ## Risks - Low risk. UI-only removal with no data or API changes. - Users who relied on the header sha to identify a source build must enable the experimental server-info debug view to see the running commit in the same menu. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - Claude (Anthropic), Claude Fable 5, model ID `claude-fable-5`, extended thinking enabled, via Claude Code CLI with tool use (file edit, shell, test runner) ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-09-03 23:26:08 -07:00
Devin Foley	446577d174	fix(ui): honor PAPERCLIP_HIDDEN_SETTINGS in the production switcher menu (#12788) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Operators control which settings surfaces appear via the `PAPERCLIP_HIDDEN_SETTINGS` env var (keys like `company.invites`, `company.members`) > - The sidebar organization switcher has an "Invite people" shortcut that points at the company Invites surface > - The streamlined switcher menu already hides that shortcut when the Invites/Members surface is hidden, but the production-shell menu (rendered when the streamlined UI is disabled) renders the invite row unconditionally > - So an operator that hides the Invites surface still sees the shortcut in the production shell — the hide is not fully honored > - This pull request gates the production menu's invite shortcut on the same hide keys, so `PAPERCLIP_HIDDEN_SETTINGS` controls it in both shells > - The benefit is one consistent, per-deployment knob: a hoster that wants the shortcut gone (e.g. Paperclip Cloud, whose managed stacks set `company.invites`) drops it by setting the env var, and every other hoster keeps it by leaving the key unset ## Linked Issues or Issue Description No existing issue. Description follows the enhancement template: **What existing behavior does this improve?** `PAPERCLIP_HIDDEN_SETTINGS` coverage for the organization switcher's "Invite people" shortcut in the production shell. **Subsystem affected** UI — `ui/src/components/SidebarCompanyMenu.production.tsx`. **Current behavior** The streamlined switcher menu hides the "Invite people" shortcut when `company.invites` or `company.members` is hidden. The production-shell menu renders the invite row unconditionally, so the hide keys have no effect there. **Proposed behavior** The production menu computes `showInvitePeople` from the same hide keys and gates the invite row on it. With no hidden settings (the default) the shortcut still shows; hiding either surface removes it in both shells. **Reason and benefit** This is the per-deployment knob operators already use for the Invites surface. Making the production shell honor it gives one consistent mechanism: Paperclip Cloud drops the shortcut on its managed stacks (which set `company.invites`, because the managed invite accept flow is being overhauled), while other hosters keep it by leaving the key unset — no cloud-specific branching in the app. **Breaking changes** None. Default behavior (no hidden settings) is unchanged; this only makes an existing env var take effect where it previously did not. ## What Changed - `SidebarCompanyMenu.production.tsx` imports `useHiddenSettings` + `hidesCompanyPage`, computes `showInvitePeople` exactly as the streamlined menu does, and renders the invite row only when it is true. - Tests: the production shell shows the shortcut by default and hides it when `company.invites` is hidden. - The streamlined menu is unchanged (it already honored the keys). ## Verification - `cd ui && npx vitest run src/components/SidebarCompanyMenu.test.tsx` — 20 tests pass. - `cd ui && npx tsc -p tsconfig.json --noEmit` — clean. - Manual: with `PAPERCLIP_HIDDEN_SETTINGS=company.invites`, the switcher's "Invite people" row is absent in both the streamlined and production shells; with the key unset it is present in both. ## Risks Low risk. UI-only visibility change; default (no hidden settings) is unchanged, and it only extends an existing, documented env var to a shell that was missing it. ## Model Used Claude Fable 5 (`claude-fable-5`, Anthropic), extended thinking, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-09-03 17:39:56 -07:00
Devin Foley	2392a9895e	fix(ui): drop the "Open invite" action from the invites section (#12787) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The Members page has an Invites tab where an admin mints single-use invite links for people > - After a link is created, the section offers two actions: "Copy link" and "Open invite" > - "Open invite" opens the inviter's own single-use link in a new tab, which is never what the inviter means — the link is for the invitee > - This pull request removes the "Open invite" button and keeps "Copy link" as the only action > - The benefit is that the section no longer invites a mistake, and the one remaining action matches the section's purpose ## Linked Issues or Issue Description No existing issue. Description follows the enhancement template: **What existing behavior does this improve?** The latest-invite panel on the Members page Invites tab. **Subsystem affected** UI — `ui/src/components/access/InvitesSection.tsx`. **Current behavior** After an invite is created, the panel shows a "Copy link" button and an "Open invite" button. "Open invite" opens the invite URL in a new tab as the inviter. **Proposed behavior** The panel shows only "Copy link". The invite URL field itself stays visible and selectable. **Reason and benefit** Invite links are single-use and addressed to the invitee. The inviter opening their own link at best shows them their own landing page and at worst walks the link toward consumption. Removing the button removes the trap. **Breaking changes** None. No API or data change. ## What Changed - Removed the "Open invite" anchor button from `InvitesSection`. - Removed the now-unused `ExternalLink` icon import. - The component test now asserts the action is absent. ## Verification - `cd ui && npx vitest run src/components/access/InvitesSection.test.tsx` — 3 tests pass. - `cd ui && npx tsc -p tsconfig.json --noEmit` — clean. - Manual: create an invite on the Members page Invites tab; the latest-invite panel shows the URL field and "Copy link" only. ## Risks Low risk. UI-only removal of one button; the invite URL remains fully visible and copyable. ## Model Used Claude Fable 5 (`claude-fable-5`, Anthropic), extended thinking, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-09-03 15:02:27 -07:00
Devin Foley	236588c753	fix(ui): stamp the service worker with a per-build id so deploys reach parked tabs (#12725) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The web UI ships a service worker (`ui/public/sw.js`) plus update logic (`ui/src/lib/service-worker-updates.ts`) whose job is to keep long-lived, parked SPA tabs on the freshly deployed bundle. > - That reload-on-update path fires only on `controllerchange` — i.e., only when the browser installs a new `sw.js`. > - But `sw.js` was a static public asset (`CACHE_NAME = "paperclip-v2"`), copied verbatim and never varying per deploy, so a normal deploy (new app bundle, unchanged `sw.js`) installed no new worker and triggered no reload. > - So a parked tab kept running the old bundle after a deploy until a manual reload — the exact failure the update logic was written to prevent. > - This pull request makes `sw.js` change whenever the app bundle changes, by stamping it with a per-build id at build time. > - The benefit is that shipped UI fixes actually reach open tabs, instead of waiting for each user to reload by hand. ## Linked Issues or Issue Description No separate issue. Describing the bug in-PR using the bug-report fields: **What happened?** After a deploy that changes the app bundle but not `sw.js`, tabs left open across the upgrade keep running the old bundle indefinitely. The network-first service worker means a manual reload always recovers, but nothing triggers that reload automatically. Concretely, the `2026.831.1` onboarding fix did not reach tabs that were open on `2026.831.0`. **Expected behavior** When a new bundle is deployed, the existing update machinery (`registration.update()` on visibility/interval, reload on `controllerchange`) should bring parked tabs onto the new bundle without a manual reload. **Steps to reproduce** 1. Open the app and leave the tab open. 2. Deploy a build that changes the app bundle but not `sw.js` (the common case — `sw.js` was static). 3. Observe the open tab keeps running the previous bundle; no new worker installs, so no `controllerchange` and no reload. **Paperclip version or commit** Reproduced against `2026.831.1` and `master` before this change. **Deployment mode** Any web deployment that serves the built UI (local trusted quickstart, managed, or self-hosted). Related PRs (searched open + closed before opening this one): - Refs #12198 (merged) — added the parked-tab `update()`/`controllerchange` reload logic this PR completes by making `sw.js` actually change per deploy. - Refs #9951 (open) — an alternative "prompt to reload on new build" approach to the same problem; this PR instead reuses the existing silent auto-reload path. Reviewers may want to pick one. - Refs #8112 (open) — serves `sw.js` with `no-cache`; complementary (that keeps the worker script itself fresh; this makes the script vary per build). ## What Changed - `ui/public/sw.js`: derive `CACHE_NAME` from a `__PAPERCLIP_BUILD_ID__` placeholder so the worker source varies per build. - `ui/src/lib/vite-sw-build-id.ts`: new Vite build plugin that rewrites the placeholder in the emitted `sw.js` with the entry chunk's content hash (stable when the app is unchanged, new when it changes). Throws if the placeholder is missing, so the worker can never silently stop rotating. - `ui/vite.config.ts`: register the plugin. - `ui/src/lib/vite-sw-build-id.test.ts`: unit tests for the stamping helper, the build-id derivation, and a contract test that `public/sw.js` still carries the placeholder. ## Verification - `vitest run ui/src/lib/vite-sw-build-id.test.ts` — 7 tests pass. - `vite build` — the emitted `dist/sw.js` contains `BUILD_ID = "index-<hash>"` matching the entry chunk `dist/assets/index-<hash>.js`, and the `__PAPERCLIP_BUILD_ID__` placeholder is gone. A subsequent build with unchanged app code produces the same id (no needless worker churn); a build with changed code produces a new id. - Dev (`vite serve`) leaves the literal placeholder in `sw.js`, where HMR (not the worker) drives refreshes. ## Risks - Low risk, build-time only. No runtime service-worker logic changes beyond the cache name being build-specific; the activate handler already deletes all caches, so a rotating name is inert there. - If a future edit removes the placeholder, the build fails loudly rather than silently shipping a non-rotating worker. ## Model Used - Claude (Anthropic), model id `claude-fable-5` (Claude Fable 5), used with tool use, shell commands, file editing, and test execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-09-03 13:08:19 -07:00
Devin Foley	db4eeb1688	fix(server): validate project goal ids exist and belong to the company (#12779) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Projects can link to goals, through the `goalIds` list or the legacy `goalId` field. The project service writes those links on create and update. > - The service never checked the goal ids. A nonexistent id died at the `projects.goal_id` foreign key as an opaque 500, and the caller got no actionable feedback — observed live on 2026-09-03, where one caller retried the same bad id four times. > - The foreign key also only proves a goal exists, not who owns it. A goal id from another company linked silently on a multi-company instance. > - This pull request asserts every resolved goal id exists under the caller's company before any write, and rejects with a 422 that names the unknown ids. > - The benefit is a clear, actionable client error instead of a 500, and no cross-company goal links. ## Linked Issues or Issue Description **What happened?** `POST /companies/:companyId/projects` with a `goalIds` entry that does not exist fails with an internal error: `insert or update on table "projects" violates foreign key constraint "projects_goal_id_goals_id_fk"`. The caller sees a 500 and retries. A goal id that exists but belongs to a different company is accepted and linked. **Expected behavior** The request fails fast with a 422 that names the unknown goal id(s). Goals from other companies are rejected the same way. Valid links behave exactly as before. **Steps to reproduce** 1. Create a company and no goals. 2. `POST /companies/:companyId/projects` with `{ "name": "Rocket", "goalIds": ["<any-uuid>"] }`. 3. Before this change: 500 from the foreign key. After: 422 naming the id. **Deployment mode** Any; observed on an authenticated public deployment. ## What Changed - `assertGoalsBelongToCompany` in the project service: one query for the resolved ids scoped to the company; unknown ids produce `unprocessable` (422) with the ids in the message and details - called on create (before the project row insert, so no partial writes) and on update (scoped to the existing project's company); both `goalIds` and the legacy `goalId` field flow through the same resolution - new embedded-Postgres test file: valid link, nonexistent id on create with no partial insert, legacy field, another company's goal on create, and a foreign-goal update that leaves existing links unchanged ## Verification - `pnpm vitest run src/__tests__/project-goal-validation.test.ts` — 5 passed - adjacent suites (`project-icon-persistence`, `project-shortname-resolution`, `issue-goal-fallback`, `project-goal-telemetry-routes`, `heartbeat-referenced-projects`, `projects-list-archived-routes`) — 35 passed ## Risks - Low risk. One extra indexed select per create/update that carries goal ids. Requests that previously 500ed now 422; requests that silently linked a foreign goal now fail — both are corrections, not regressions. - Existing rows with foreign links (written before this check) are untouched; only new writes validate. ## Model Used Claude Fable 5 (claude-fable-5) via Claude Code, extended thinking with tool use. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above (none found for goal-id validation) - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes (doc comments; no user-facing docs affected) - [x] I have considered and documented any risks above	2026-09-03 12:17:27 -07:00
Devin Foley	2177b85eb5	fix(server): retry cloud-tenant auth sync once on a dropped DB connection (#12773) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Managed-cloud deployments authenticate tenant requests through trusted headers. The middleware syncs the tenant's user, company, and membership rows on the way through. > - Pooled Postgres endpoints sometimes close an established connection under an in-flight query (pooler recycle, compute suspend). The driver reconnects on the next query, but the statement on the wire fails. > - In this path a single dropped statement fails the whole request with a 500. This happened live on 2026-09-03: the idempotent company bootstrap insert died with `write CONNECTION_CLOSED`. > - This pull request retries the actor resolution exactly once when the error chain carries a postgres.js closed-connection code. The sync is idempotent end to end, so the replay is safe. > - The benefit is that a routine pooler blip no longer fails an authenticated request on the entry path. ## Linked Issues or Issue Description **What happened?** A cloud tenant request hit the trusted-header authentication middleware while the pooled Postgres endpoint closed the connection mid-query. The insert failed with `write CONNECTION_CLOSED <host>:5432` wrapped in a `Failed query: insert into "companies" …` error, and the request failed. **Expected behavior** The driver reconnects on the next query, and every statement in the tenant sync is idempotent (upserts, on-conflict inserts, deletes; the write debounce records only after the full sync succeeds). One in-request retry should absorb the blip and serve the request. Non-transient failures must keep failing fast. **Steps to reproduce** 1. Run an authenticated public deployment against a pooled Postgres endpoint. 2. Have the pooler close the connection while the middleware's tenant sync insert is on the wire. 3. Before this change the request fails with a 500; after it the retry serves the request. **Deployment mode** Authenticated public (managed cloud), external pooled PostgreSQL. ## What Changed - `resolveCloudTenantActor` now delegates to the (unchanged) resolution body through `retryOnTransientDbConnectionError`, which retries exactly once on a transient closed-connection failure - `isTransientDbConnectionError` walks the error `cause` chain (drizzle wraps the driver error) for the postgres.js codes `CONNECTION_CLOSED`, `CONNECTION_ENDED`, `CONNECTION_DESTROYED`; both helpers are exported for tests - New unit test file `cloud-tenant-transient-db-retry.test.ts`: detection matrix (including a `23505` staying non-transient), retry-once-then-succeed, no-retry on non-transient, propagate-on-second-failure ## Verification - `pnpm vitest run src/__tests__/cloud-tenant-transient-db-retry.test.ts` — 5 passed - `pnpm vitest run src/__tests__/cloud-tenant-company-provisioning.test.ts` — 7 passed against embedded Postgres, driving the real resolution path through the new wrapper ## Risks - Low risk. The retry is bounded to one attempt, gated on three explicit driver codes, and wraps an operation that is already idempotent by design. Every other failure propagates unchanged. - A genuinely down database now fails after two attempts instead of one — a few milliseconds of added latency on an already-failing request. ## Model Used Claude Fable 5 (claude-fable-5) via Claude Code, extended thinking with tool use. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above (none found for connection-retry work in this path) - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes (doc comments; no user-facing docs affected) - [x] I have considered and documented any risks above	2026-09-03 12:16:55 -07:00
Devin Foley	174e35a144	fix(server): stop paging Sentry for supervised boot races in managed cloud (#12772) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The server refuses to boot when its database is not migrated, or when an authenticated public deployment has no `DATABASE_URL`. These refusals are deliberate and correct. > - In managed cloud, a supervisor creates each stack, migrates its fresh database, applies configuration, and restarts the app. The app container often boots before those steps finish. > - Each early boot hits one of the two refusals, exits, and captures the refusal to Sentry. One fleet build batch produces hundreds of identical expected events. Real errors get buried. > - This pull request classifies exactly those two refusals as expected transients when `PAPERCLIP_CLOUD_API_ORIGIN` marks a supervised deployment, and skips only the Sentry capture for them. > - The benefit is a clean error signal: expected provisioning noise stops, and every real failure still reports. ## Linked Issues or Issue Description **What happened?** A managed-cloud stack boots its app container before the supervisor migrates the empty database or finishes applying configuration. The container refuses to start, crash-loops briefly, and converges after the supervisor restarts it. Every refused boot sends an error event to Sentry. A batch of new stacks produces hundreds of these expected events. **Expected behavior** The refusal logs and exits nonzero, so the supervisor can act. Sentry receives no event for an expected provisioning transient. Sentry still receives events for real failures: schema drift, malformed configuration, and every refusal outside managed cloud. **Steps to reproduce** 1. Set `PAPERCLIP_MIGRATION_AUTO_APPLY=false`, `PAPERCLIP_MIGRATION_PROMPT=never`, `SENTRY_DSN`, and `PAPERCLIP_CLOUD_API_ORIGIN`. 2. Point `DATABASE_URL` at an empty database and start the server. 3. The server refuses to start. Before this change it also captures the refusal to Sentry on every boot. **Deployment mode** Authenticated public (managed cloud). ## What Changed - New `server/src/startup-refusals.ts`: a `StartupRefusalError` class for refusals whose remedy belongs to the deployment supervisor, `migrationRefusalError()` to classify a pending-migrations refusal (zero applied migrations = never migrated = supervised transient; any applied history = drift = plain always-reported `Error`), and `shouldReportStartupFailure()` for the capture decision. - `server/src/index.ts`: the pending-migrations refusal uses the classifier; the missing-`DATABASE_URL` refusal under the authenticated-public contract becomes a `StartupRefusalError` (the malformed-URL refusal stays a plain `Error`); the startup crash handler consults `shouldReportStartupFailure()` before `captureException`. Logging and the nonzero exit are unchanged. - New `server/src/__tests__/startup-refusals.test.ts` covering the classification and decision matrix, including the unchanged self-hosted paths. ## Verification - `pnpm vitest run src/__tests__/startup-refusals.test.ts` — 7 passed. - Review the decision matrix in the test file: refusals report when `PAPERCLIP_CLOUD_API_ORIGIN` is absent or blank; non-refusal errors and non-`Error` throwables always report; drift always reports. ## Risks - Low risk. The change only skips a Sentry capture in one narrow, marker-gated case. Boot behavior, logging, and the exit code do not change. - Self-hosted deployments do not set `PAPERCLIP_CLOUD_API_ORIGIN`, so their reporting is unchanged, and the tests pin that. - A supervised deployment with a genuinely stuck migration runner loses per-boot Sentry events for that stack. The supervisor's own health checks and monitoring own that signal, and the container logs still carry the refusal. ## Model Used Claude Fable 5 (claude-fable-5) via Claude Code, extended thinking with tool use. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above (none found for startup Sentry suppression) - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes (module doc comment; no user-facing docs affected) - [x] I have considered and documented any risks above	2026-09-03 10:02:42 -07:00
Devin Foley	8eaa5caa05	docs(release): add v2026.831.1 stable notes to master (#12710) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The release pipeline keeps a canonical stable note at `releases/vX.md` on master for every published stable. > - Stable `2026.831.1` was a hotfix cut from a branch off `v2026.831.0`, with its notes committed into the source tree. > - In that path the workflow resolves notes in `source_tree` mode and skips `canonicalize_stable_notes`, which is the job that normally copies the note to master. > - As a result `releases/v2026.831.1.md` exists on the tag but never landed on master, so the stable-notes history has a gap. > - This pull request adds the canonical copy of that note to master. > - The benefit is a complete, consistent stable-notes history for readers and for the release tooling. ## Linked Issues or Issue Description No separate issue. Describing the gap in-PR with the docs template fields: **Issue type** Documentation gap in the release-notes history on master. **Where is the issue?** `releases/` on the master branch — the file `releases/v2026.831.1.md` is missing, although the stable `2026.831.1` release has already published. **What's wrong?** The `2026.831.1` patch was published from a hotfix branch whose notes lived in the source tree (`source_tree` notes mode). That mode skips `canonicalize_stable_notes`, the job that copies a stable's note onto master. So every other stable has a `releases/vX.md` on master, but `2026.831.1` does not. **Suggested fix** Add the canonical `releases/v2026.831.1.md` to master, identical to the copy published with the tag. ## What Changed - Add `releases/v2026.831.1.md` to master, copied verbatim from the published `v2026.831.1` tag. ## Verification - `diff` of the added file against `git show v2026.831.1:releases/v2026.831.1.md` is empty (identical to the shipped note). - Docs-only change: no code, tests, or build outputs are affected. ## Risks - Low risk. The change adds one Markdown file and touches no code, schema, or configuration. ## Model Used - Claude (Anthropic), model id `claude-fable-5` (Claude Fable 5), used with tool use, shell commands, and file editing.	2026-09-01 22:53:44 -07:00
Devin Foley	0b00029672	docs(release): canonicalize stable notes for v2026.831.0 (#12708) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The release process drafts stable notes under a beta-keyed path during the soak and renames them to the versioned path after the stable ships > - Stable v2026.831.0 published, but its release run failed at the tag push (workflows-permission error), so the automated canonicalize job never ran > - The canonical layout requires the notes at `releases/v2026.831.0.md` > - This pull request performs the rename the skipped job would have pushed > - The benefit is that the repository returns to the canonical release-notes layout ## Linked Issues or Issue Description **Issue type** Missing content **Where is the issue?** `releases/` — the stable notes for v2026.831.0 still live at the beta-keyed path `releases/beta/v2026.828.0-beta.0.md`. **What's wrong?** The stable release run failed at the tag push, so the `canonicalize_stable_notes` job was skipped and the rename branch was never pushed. The published GitHub Release points at content that should live at `releases/v2026.831.0.md`. **Suggested fix** `git mv releases/beta/v2026.828.0-beta.0.md releases/v2026.831.0.md`, exactly as the workflow's canonicalize job does. ## What Changed - Renamed `releases/beta/v2026.828.0-beta.0.md` to `releases/v2026.831.0.md` (pure rename, no content changes) ## Verification - `git show --stat` reports a 100% rename with no content delta - The file matches the published GitHub Release body for v2026.831.0 ## Risks - Low risk: a pure file rename restoring the canonical layout. ## Model Used - Claude (Anthropic), model ID `claude-fable-5` (Claude Fable 5), extended thinking enabled, tool use via Claude Code ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-09-01 18:13:02 -07:00
Devin FoleyandPaperclip	314ff24b7a	refactor(docker): declare the build stage's C toolchain explicitly (#12673) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The Docker images compile the Rust runner (paperclip-runnerd) during the build stage > - The previous change replaced apt's cargo/rustc with a pinned rustup install > - apt's cargo package pulled gcc in as a dependency; rustup does not install a C toolchain > - Every master docker build now fails with "linker `cc` not found" in the build scripts > - This pull request installs gcc, libc6-dev, and pkg-config explicitly in the build stage > - The benefit is that the build stage declares its own C toolchain instead of inheriting one by accident ## Linked Issues or Issue Description **What happened?** Master `docker.yml` builds fail in `pnpm --filter @paperclipai/server build`: cargo build scripts (`libc`, `quote`, `proc-macro2`) die with `` error: linker `cc` not found ``, and the job exits with code 101. **Expected behavior** Master docker builds compile the runner and publish images. **Steps to reproduce** 1. Run the `docker.yml` workflow on current `master`. 2. Observe the `build-and-push` job fail with the linker error above. **Paperclip version or commit** `master` after commit `317394456` (the rustup change); example failing run: docker.yml on `86ebdf842`. ## What Changed - The build stage installs `gcc`, `libc6-dev`, and `pkg-config` explicitly, with a comment recording why: the old apt cargo brought gcc in as a dependency and the pinned rustup install does not. ## Verification - Replicated the build stage's exact package sequence in `node:24-trixie-slim` — base-stage packages only (which include no compiler), then this new line, then the pinned, checksum-verified rustup install: the runner compiles (`Finished release`) with `rustc 1.97.1` and `cc 14.2.0`. - Note: `docker.yml` triggers only on master pushes, so a PR run cannot exercise the image build itself; the container replication above is the pre-merge check. No test files: build-infrastructure fix (`fix:` on the Dockerfile only). ## Risks - Low risk. Three packages added to the build stage only; the production stage is unchanged. ## Model Used - Claude Fable 5 (`claude-fable-5`), Anthropic — Claude Code harness, extended thinking + tool use. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-09-01 10:38:53 -07:00
Devin Foleyandgithub-actions[bot]	b5fd13e09f	docs(release): stable notes for the 2026.828.0-beta.0 soak (v2026.831.0) (#12610) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The release process promotes a soaked beta to stable; the stable's GitHub Release body comes from `releases/beta/v<beta-version>.md` on `master` > - The `draft_stable_notes` job seeded this file as a raw commit-log skeleton when `2026.828.0-beta.0` published > - The stable preflight fails without the merged file, and the skeleton is not fit to publish as release notes > - This pull request rewrites the skeleton into finished stable notes for the v2026.831.0 promotion > - The benefit is that the stable release ships with accurate, readable, user-facing notes on time ## Linked Issues or Issue Description **Issue type** Missing content **Where is the issue?** `releases/beta/v2026.828.0-beta.0.md` — the drafted stable-notes skeleton for the `2026.828.0-beta.0` soak. **What's wrong?** The file holds the auto-generated skeleton (grouped commit subjects with nested PR summaries). The stable promotion publishes this file verbatim as the GitHub Release body, so it must be rewritten into release-notes voice before the stable dispatch. **Suggested fix** Rewrite the skeleton at full stable depth per `.agents/skills/release-changelog/SKILL.md`: verified breaking changes with upgrade paths, delta-aware highlights, grouped improvements and fixes with inline PR attribution, an upgrade guide covering migrations and new environment variables, and a contributors section. ## What Changed - Rewrote `releases/beta/v2026.828.0-beta.0.md` from the generated skeleton into finished notes titled `# Paperclip v2026.831.0` - Six breaking changes, led by the Node.js 24.11.0 minimum; each has an upgrade path - Five highlights: runtime skill delivery to agents, the Kimi Code adapter, operator settings-visibility controls, the HTTP/2 sandbox callback bridge, and the shortened onboarding arc - Upgrade guide covers migrations `0223`–`0230` (each attributed from its SQL) and the new `PAPERCLIP_HIDDEN_SETTINGS`, `PAPERCLIP_SETTING_DEFAULTS`, `SENTRY_DSN`, and `PAPERCLIP_WORKSPACE_REAPER_COOLDOWN_DAYS` variables - Entries already shipped to stable users in v2026.824.1 are noted as such instead of re-announced - Contributors section lists 7 verified community handles; core maintainers and bots are excluded per the canonical list ## Verification - Range verified as `664052f8e..dbf052577` (baseline v2026.824.1 merge-base to the `beta/v2026.828.0-beta.0` source commit); every entry traces to a commit in that range - Stable version confirmed with `./scripts/release.sh stable --date 2026-08-31 --print-version` → `2026.831.0` - Migration list confirmed with `git diff --name-only 664052f8e..dbf052577 -- packages/db/src/migrations/` and each file's SQL read at the source commit - Environment variable names confirmed against `docs/deploy/environment-variables.md` and source at `dbf052577` - Contributor handles confirmed via `gh pr view <n> --json author` for each attributed community PR ## Risks - Low risk: a single markdown file; no source changes. The main risk is a factual error in the notes — mitigated by verifying each claim against the source commit rather than commit messages alone. If the promotion date slips past 2026-08-31 UTC, the title needs a re-date (the beta-keyed filename makes this harmless). ## Model Used - Claude (Anthropic), model ID `claude-fable-5` (Claude Fable 5), extended thinking enabled, tool use (git/GitHub CLI research against the release range) via Claude Code ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>	2026-08-31 19:17:10 -07:00
Devin FoleyandPaperclip	3173944561	refactor(docker): install rust via a verified rustup, pinned by rust-toolchain.toml (#12605) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The Docker images ship the server together with the Rust runner binary (paperclip-runnerd) > - The Dockerfile installed rust from Debian trixie's apt archive, which provides rustc 1.85 > - The runner's dependency tree and its `rust-toolchain.toml` now require rustc 1.97.1, so every master docker build fails while hosted CI (with a newer preinstalled rust) stays green > - No image has been published since the dependency refresh, so deployments cannot receive current builds > - This pull request installs rustup from a version-pinned, checksum-verified installer and defers the compiler choice to the runner's own `rust-toolchain.toml` > - The benefit is one toolchain pin, owned by the runner package, shared by CI and image builds, installed without executing an unverified remote script ## Linked Issues or Issue Description **What happened?** Every `docker.yml` build on `master` fails since the runner dependency refresh. The failing step is `pnpm --filter @paperclipai/server build`, which runs `cargo build` for `paperclip-runnerd`. Cargo reports: `rustc 1.85.0 is not supported by the following packages: icu_collections@2.3.0 requires rustc 1.88` (and sibling icu crates). The build exits with code 101 and no image is published. **Expected behavior** Master docker builds compile the runner and publish images. **Steps to reproduce** 1. Run the `docker.yml` workflow on current `master`. 2. Observe the `build-and-push` and `build-and-push-cloud` jobs fail in the server build step with the rustc version error. **Paperclip version or commit** `master` (first failing build ~2026-08-31 12:21 UTC; last successful image build `fd7cb77d8`). ## What Changed - The docker build stage downloads a pinned `rustup-init` (1.29.0) for the build architecture, verifies it against an embedded sha256, and installs with `--default-toolchain none`. - The compiler version comes from `packages/paperclip-runner/rust-toolchain.toml` (1.97.1) — one pin, no drift between the Docker layer and the runner package. - A comment records why apt rust is not used: Debian's archive lags the ecosystem. ## Verification - In the exact base image (`node:24-trixie-slim`): the checksum check passes, rustup installs with no default toolchain, and `cargo build --release --manifest-path runner/Cargo.toml --locked -p paperclip-runner-core --bin paperclip-runnerd` completes with `rustc 1.97.1` selected from the toml. - This PR's own docker build exercises the same path end to end for both architectures. - No test files: this is a build-infrastructure refactor with no runtime code change (hence the `refactor:` prefix); the docker build itself is the executable check. ## Risks - Low risk. The change is scoped to the docker build stage; the production stage is unchanged. The rustup installer version and checksums are pinned; bumping rust later means editing only `rust-toolchain.toml`. ## Model Used - Claude Fable 5 (`claude-fable-5`), Anthropic — Claude Code harness, extended thinking + tool use. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-31 14:16:17 -07:00
Devin Foley	300a89ec13	Detect the qualifier-less Claude usage-limit message in quota classification (#12475) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The heartbeat runtime classifies adapter run failures, and the recovery service uses that classification to decide between automatic retry, a timed provider-quota wait, and a board escalation > - The Claude CLI changed its subscription-limit stop message to "You've hit your limit · resets 2:30am (UTC)", and no quota matcher knows this qualifier-less wording > - A limit-hit run therefore classifies as `adapter_failed` (or `claude_auth_required`), recovery burns its continuation retries against a hard limit, and the issue blocks with the opaque "No live execution path" notice instead of waiting for the reset and retrying automatically > - This pull request teaches the adapter and the recovery service the new wording, and titles stranded-escalation notices from the classified run error code so operators see the cause at a glance > - The benefit is that usage-limit stops self-heal at the provider reset time, and the notices that do post say "Error: usage limit reached" or "Error: not logged in to Claude" instead of a generic title ## Linked Issues or Issue Description No public issue exists; the underlying problem follows the bug template: **What happened?** On a staging deployment, an assigned `in_progress` issue hit the Claude subscription usage limit. The run recorded the error `Claude run failed: subtype=success: You've hit your limit · resets 2:30am (UTC)`. The automatic continuation retry failed the same way in 34 seconds with `errorCode: adapter_failed`. Terminal-run recovery then escalated: the issue moved to `blocked` with the notice "No live execution path" and a board-owned recovery action. The notice gave the operator no indication that the cause was a usage limit with a known reset time. **Expected behavior** A usage-limit stop classifies as `provider_quota` with the reset clock parsed into `retryNotBefore`. The recovery service takes its provider-quota wait path: a system-owned recovery action that waits for the reset time and retries the original assignee automatically. If an escalation notice does post, its title names the classified cause. **Steps to reproduce** 1. Run a `claude_local` agent on an issue until the Claude subscription limit is hit, so the CLI result is "You've hit your limit · resets \<time\> (UTC)". 2. Let terminal-run recovery retry the continuation. 3. Observe the issue block with the "No live execution path" notice instead of a timed quota wait. `classifyAdapterFailureForRecovery` returns `null` for the recorded error text; `CLAUDE_PROVIDER_QUOTA_RE` and `PROVIDER_QUOTA_ERROR_RE` both fail to match it. ## What Changed - `CLAUDE_PROVIDER_QUOTA_RE` and `CLAUDE_EXTRA_USAGE_RESET_RE` (claude-local adapter) accept "you've hit your limit" with no qualifier, alongside the existing "session"/"usage" wordings, so the run classifies as `provider_quota` and the reset clock lands in `retryNotBefore`. - `PROVIDER_QUOTA_ERROR_RE` and `isProviderQuotaRecovery` (recovery service) accept the same wording, so runs recorded before the adapter fix (errorCode `adapter_failed` with the limit text in the error) also route to the quota wait. - `parseProviderQuotaClockReset` parses the "resets 2:30am (UTC)" clock shape alongside the existing "try again at" shape. - `buildStrandedRecoveryEscalationNotice` titles the notice from the source run's classified error code when one is mapped: `provider_quota` → "Error: usage limit reached", `claude_auth_required` → "Error: not logged in to Claude", `acpx_auth_required` → "Error: agent login required". The raw failure text stays withheld from the issue thread; only the server-classified code is surfaced. Unmapped codes keep the existing seed/cause titles. ## Verification - `pnpm vitest run packages/adapters/claude-local/src/server/parse.test.ts server/src/services/recovery/provider-failure-classification.test.ts server/src/services/recovery/stranded-notice.test.ts` — 72 tests pass, including 5 new cases that use the exact new CLI message. - `pnpm vitest run server/src/__tests__/issue-recovery-actions.test.ts server/src/__tests__/heartbeat-retry-scheduling.test.ts server/src/__tests__/heartbeat-process-recovery.test.ts` — 189 tests pass (no reroute regressions from the widened matchers). - `tsc --noEmit` clean for `@paperclipai/adapter-claude-local` and `@paperclipai/server`. ## Risks - Low risk. The regex widenings are additive; every previously matched wording still matches, and the existing negative test ("Workspace storage capacity limit reached." stays unclassified) still passes. - Behavioral shift, intended: an `adapter_failed` run whose error text is the new limit wording now routes to the silent system-owned quota wait instead of a board escalation. This matches how the older limit wordings already behave. - The notice title change only affects escalations whose source run carries one of the three mapped error codes; all other notices render exactly as before. ## Model Used Claude Fable 5 (`claude-fable-5`, Claude Code CLI, extended thinking with tool use). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-31 13:40:11 -07:00
Devin Foley	dbf052577d	Follow the current onboarding arc in the release smoke (#12423) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - A release is gated by the release smoke: it installs the published `paperclipai` artifact into a Docker container and drives the sign-in → onboarding → first-agent path with Playwright > - That suite runs only from the release pipeline, never on a pull request, so it sees the UI only after the UI has already changed > - The onboarding wizard was rebuilt into the agent arc. The "Name your organization" step, the "Start Onboarding" launcher, and the agent role picker are all gone > - The spec still waited for those, so it failed on its first assertion and blocked every nightly and beta release > - The failure was also hard to read. The workflow uploaded no container logs, because it learned the container's name only after the harness succeeded, and the harness ran the container with `--rm` and deleted it before anything read it > - This pull request rewrites the spec to follow the current arc, and repairs the log capture at both ends > - The benefit is that nightly and beta releases are unblocked, and the next failure arrives with the logs attached ## Linked Issues or Issue Description No existing issue. Describing it inline, following `.github/ISSUE_TEMPLATE/bug_report.yml`. Refs #12274 (removed the company-naming step from the wizard). Refs #12135 (the previous alignment of this spec, before #12274). Refs #12316 (open; also edits `scripts/docker-onboard-smoke.sh`, in the bootstrap helpers rather than the container lifecycle, so the two changes do not overlap. Whichever lands second should rebase and re-run). **What happened?** The release smoke fails. `tests/release-smoke/docker-auth-onboarding.spec.ts` never gets past its first wait: ``` ✘ tests/release-smoke/docker-auth-onboarding.spec.ts:43:3 › Docker authenticated onboarding smoke › logs in, completes onboarding, and hires the lead agent Error: expect(locator).toBeVisible() failed — element(s) not found (timeout 20000ms) > 33 | await expect(wizardHeading.or(startButton)).toBeVisible({ timeout: 20_000 }); ``` The spec waits for an `h3` reading "Name your organization" or a "Start Onboarding" button. Neither exists. #12274 removed the company-naming step; the string now survives only in a code comment and in `ui/src/components/OnboardingWizard.step.test.tsx`, which asserts it is *absent*. The steps after the first wait are stale too: the CTA on step 1 is "Continue" and not "Next", the organization input's placeholder changed, and the agent step's `#onboarding-agent-role` picker is gone, so every onboarding hire is filed under the neutral `general` role. The suite runs only from the release pipeline, so nothing on a pull request saw the drift. Both `smoke_nightly` and `smoke_beta` call the same reusable workflow, so every nightly and every beta was blocked. The failure also arrived without diagnostics. The job's "Capture Docker logs" step is `if: always()`, but it is guarded on `SMOKE_CONTAINER_NAME`, which the "Launch Docker smoke harness" step writes to `$GITHUB_ENV` only *after* the harness returns. On any failure before that the guard is false, the step does nothing, and the upload reports "No files were found". Below that, `scripts/docker-onboard-smoke.sh` starts the container with `docker run -d --rm`, so the `docker stop` in its EXIT trap deletes the container and its logs together — and a container that crashes on its own is removed the instant its process exits. **Expected behavior** The spec walks the onboarding arc the app actually presents, and proves the company is created, the lead agent is hired, and the first task is seeded and dispatched. When the smoke fails, the run's artifact carries the container's logs. **Steps to reproduce** 1. Run the Release Smoke workflow against a published artifact that carries #12274, or run it locally: `PAPERCLIPAI_VERSION=2026.828.0-canary.3 SMOKE_DETACH=true ./scripts/docker-onboard-smoke.sh` 2. Run `pnpm run test:release-smoke` against that container. 3. The single spec fails at `openOnboarding()` after 20 seconds. 4. In CI, open the run's `release-smoke` artifact. It has no `docker-onboard-smoke.log`. **Paperclip version or commit** `2026.828.0-canary.3` (commit 8316ceb0b). **Deployment mode** Docker. **Installation method** npm / pnpm global install (the container runs `npx paperclipai@<version>`). **Node.js version** v24.20.0 inside the container. **Relevant logs or output** ``` Running 1 test using 1 worker ✓ 1 [chromium] › tests/release-smoke/docker-auth-onboarding.spec.ts:76:3 › Docker authenticated onboarding smoke › logs in, completes onboarding, and hires the lead agent (7.0s) 1 passed (8.7s) ``` That is the result after this change. Before it, the same command failed at the first wait, as quoted above. ## What Changed - `tests/release-smoke/docker-auth-onboarding.spec.ts` now follows the current arc. It signs in, opens `/onboarding`, names the organization and presses "Continue" (which creates the company and routes straight to the agent step, because onboarding no longer asks for a mission), names the lead and presses "Next", presses "Connect" on the default adapter to hire, then presses "Get started" to launch. - The spec addresses controls by role and accessible name, or by id where one exists (`#onboarding-agent-name`). Step 1's field has no id and no associated label, so it is found as the wizard's only text box rather than by its placeholder copy. - The spec asserts the hired agent's role is `general`, which is what the arc files every onboarding hire under. Every other API assertion is unchanged. - The spec navigates to `/onboarding` explicitly and drops any saved onboarding draft first, so it can run twice against one instance. The suite retries once in CI. It still asserts that a company-less board routes sign-in into onboarding, guarded on the board actually being empty. - `scripts/docker-onboard-smoke.sh` accepts `SMOKE_CONTAINER_NAME`, drops `--rm`, removes the container itself, and dumps `docker logs` to `SMOKE_LOG_FILE` before the teardown. - `.github/workflows/release-smoke.yml` pins the container name in the job's `env`, so every `always()` step has it before anything runs. The capture step refreshes the log from a live container when there is one, keeps the harness's dump when there is not, and writes a one-line explanation when there is neither. The upload's paths are literals, and `if-no-files-found: error` makes a broken diagnostics path fail rather than warn. - `scripts/docker-onboard-smoke.test.mjs` pins that wiring. It is added to `test:release-registry`, which runs on every pull request. - `doc/DOCKER.md` documents `SMOKE_CONTAINER_NAME` and `SMOKE_LOG_FILE`. ## Verification The spec was run against a real container built from the published `2026.828.0-canary.3` artifact, exactly as the workflow runs it. ```sh SMOKE_CONTAINER_NAME=release-smoke-onboard \ HOST_PORT=3232 DATA_DIR=<tmp>/smoke-data \ PAPERCLIPAI_VERSION=2026.828.0-canary.3 \ SMOKE_READY_TIMEOUT_SECONDS=420 SMOKE_DETACH=true \ SMOKE_METADATA_FILE=<tmp>/release-smoke.env \ SMOKE_LOG_FILE=<tmp>/docker-onboard-smoke.log \ ./scripts/docker-onboard-smoke.sh PAPERCLIP_RELEASE_SMOKE_BASE_URL=http://localhost:3232 \ PAPERCLIP_RELEASE_SMOKE_EMAIL=smoke-admin@paperclip.local \ PAPERCLIP_RELEASE_SMOKE_PASSWORD=paperclip-smoke-password \ PAPERCLIP_PLAYWRIGHT_CHANNEL=chrome \ pnpm run test:release-smoke ``` ``` Running 1 test using 1 worker ✓ 1 [chromium] › tests/release-smoke/docker-auth-onboarding.spec.ts:76:3 › Docker authenticated onboarding smoke › logs in, completes onboarding, and hires the lead agent (7.0s) 1 passed (8.7s) ``` The same command was run a second time against the same, now non-empty, instance. That covers the retry path, and it also passes. The log capture was verified by making the container die during startup: ```sh PAPERCLIPAI_VERSION=0.0.0-no-such-version \ SMOKE_CONTAINER_NAME=release-smoke-onboard SMOKE_LOG_FILE=<tmp>/fail.log \ ./scripts/docker-onboard-smoke.sh ``` `<tmp>/fail.log` was written and carried the cause: ``` npm error code ETARGET npm error notarget No matching version found for paperclipai@0.0.0-no-such-version. ``` The container was removed afterwards. On `master` this file is never written, because `--rm` deletes the container the moment its process exits. The workflow's capture step was run by hand against three states: a live container (258 lines), a removed container with the harness's dump already on disk (258 lines kept), and neither (a one-line explanation). Unit coverage: ```sh pnpm run test:release-registry # 93 tests, 93 pass ``` Nothing under `ui/` changed, so `pnpm --filter @paperclipai/ui typecheck` was not required. `tests/release-smoke` is outside the TypeScript project references; Playwright compiles it at run time, which the runs above did three times. ## Risks Low risk. Nothing ships to users. The change touches one Playwright spec, one smoke script, and one workflow. Points worth a reviewer's attention: - **This suite gates every nightly and beta, and it runs only post-merge.** `smoke_nightly` and `smoke_beta` both call `release-smoke.yml`, and no pull request runs it. Drift between the wizard and this spec is therefore invisible until a release is already blocked, which is how this bug reached a release train. I think the arc deserves an earlier check. The cheapest version is the one added here: `scripts/docker-onboard-smoke.test.mjs` runs on every pull request and pins the harness wiring. The full container smoke is too slow for the pull request path, but a UI-level test of the arc's step sequence would catch exactly this class of drift, and `ui/src/components/OnboardingWizard.step.test.tsx` is already the right home for it. I did not add it here, to keep this change to the repair. - **Dropping `--rm`.** The container is now removed by the script's cleanup instead of by Docker. The script already ran `docker rm -f` before starting, and the workflow's final step removes it too, so a leaked container is cleaned up on the next run either way. A developer who kills the script with `SIGKILL` will leave a stopped container behind, where previously they would not. - **`if-no-files-found: error` on the upload.** The capture step now always writes the log file, so the upload always has at least one path to match. If that ever stops being true, the job fails instead of warning. That is deliberate. - **The spec drops the saved onboarding draft before it walks.** A stale draft makes step 1 skip company creation and hire into the previous run's company. That state only exists when the spec runs twice against one instance. A fresh release-smoke container never has it. ## Model Used Claude (Anthropic), Claude Opus, 1M context, extended thinking, agentic tool use via Claude Code. The container, the Playwright runs, and the failure injection were driven as real commands on a local Docker host. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-28 07:21:08 -07:00
Devin Foley	8316ceb0b9	Add the Better Auth issuer column so signup and sign-in work (#12396) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - A self-hosted install in `authenticated` mode signs users in with Better Auth, mounted at `/api/auth` over a hand-written Drizzle `account` table in `packages/db` > - Better Auth 1.7.0 added a required `issuer` field to that `account` model, plus a unique index on `(issuer, accountId)` > - The dependency bump in #11886 changed only `server/package.json` and the lockfile, so the Drizzle table never grew the column > - The Drizzle adapter checks the model against the schema on every write, so `linkAccount` throws and sign-up answers 500 with an empty body; a fresh install cannot create its first user, and an upgraded install locks out every existing user > - This pull request adds the `issuer` column and its unique index, and migrates the column in with a backfill that covers every existing row > - The benefit is that sign-up and sign-in work again, on a new install and after an upgrade ## Linked Issues or Issue Description No existing issue. Describing it inline, following `.github/ISSUE_TEMPLATE/bug_report.yml`. Refs #11886 (the dependency bump that introduced the required field). Refs #12269 (an earlier attempt at this fix; its backfill covers only `provider_id = 'credential'`). **What happened?** Sign-up fails on a self-hosted install. `POST /api/auth/sign-up/email` answers HTTP 500 with a zero-byte body. The server log carries: ``` [Better Auth]: The field "issuer" does not exist in the "account" Drizzle schema. # SERVER_ERROR: [BetterAuthError: The field "issuer" does not exist in the "account" Drizzle schema.] ``` The request writes the `user` row and then fails on the `account` row. The address is stuck after that: a second sign-up answers 422 `USER_ALREADY_EXISTS`, sign-in answers 401, and password reset answers 400 `RESET_PASSWORD_DISABLED` because the account that would hold the password does not exist. An upgraded install is worse. `sign-in/email` matches the credential account on `account.issuer === 'local:credential'`. Rows written before the upgrade have no issuer, so every existing user is locked out. **Expected behavior** `POST /api/auth/sign-up/email` answers 2xx and writes both the `user` row and its credential `account` row. `POST /api/auth/sign-in/email` then answers 2xx and sets a session cookie. An install that upgrades keeps its existing users. **Steps to reproduce** 1. Start a server from `master` with `PAPERCLIP_DEPLOYMENT_MODE=authenticated` against an empty database. 2. `curl -X POST http://127.0.0.1:<port>/api/auth/sign-up/email -H 'Content-Type: application/json' -H 'Origin: http://127.0.0.1:<port>' --data '{"name":"A","email":"a@example.com","password":"a-long-password"}'` 3. The response is HTTP 500 with an empty body. **Paperclip version or commit** `master` at 4436cf0. The defect starts at 69e8585 (#11886), which moved Better Auth from 1.6.28 to 1.7.0. **Deployment mode** `authenticated`. `local_trusted` does not sign users in, so it is not affected. Hosted tenants are not affected either: that path resolves the actor from a trusted header and never reads `account`. **Database mode** Both. Embedded PostgreSQL and external PostgreSQL use the same Drizzle schema. **Relevant logs or output** Reproduced in a test by reverting the schema change: ``` stderr | better-auth-credential-signup.integration.test.ts [Better Auth]: The field "issuer" does not exist in the "account" Drizzle schema. AssertionError: expected 500 to be 200 ``` ## What Changed - `packages/db/src/schema/auth.ts`: adds `issuer` (text, NOT NULL) to `authAccounts`, and the `(issuer, account_id)` unique index that mirrors the index Better Auth declares on the model. The field name, type, requiredness, and index all come from `@better-auth/core/dist/db/get-tables.mjs` in 1.7.0. - `packages/db/src/migrations/0230_better_auth_account_issuer.sql`: adds the column, backfills every existing row, sets NOT NULL, and creates the unique index. - `packages/db/src/migrations/meta/0230_snapshot.json` and `_journal.json`: regenerated with `pnpm --filter @paperclipai/db generate`. - `packages/db/src/better-auth-account-issuer-migration.test.ts`: new. Asserts the schema shape, then rewinds the migration on a real database, seeds pre-upgrade rows, and re-applies it. - `server/src/__tests__/better-auth-credential-signup.integration.test.ts`: new. Real sign-up and sign-in through the Better Auth mount, against the real Drizzle schema and a migrated PostgreSQL. - `cli/src/__tests__/worktree.test.ts`: the worktree seed fixture writes a credential `account` row, so it now writes `issuer` too. `server/package.json` and `pnpm-lock.yaml` are untouched. The dependency is correct; the schema was what was missing. ### The issuer values, and where they come from Better Auth builds these itself, in `@better-auth/core/src/db/schema/account.ts`: ```ts export function createLocalAccountIssuer(providerId: string): string { return `local:${encodeURIComponent(providerId)}`; } export function createOAuthAccountIssuer(providerId: string): string { return `local:oauth:${encodeURIComponent(providerId)}`; } ``` Sign-up and sign-in both call `createLocalAccountIssuer("credential")`, so a credential account is `local:credential`. An OAuth account whose provider declares no `accountIssuer` of its own is `local:oauth:<providerId>` — no built-in social provider declares one. The migration writes exactly those two forms: ```sql ALTER TABLE "account" ADD COLUMN IF NOT EXISTS "issuer" text; UPDATE "account" SET "issuer" = CASE WHEN "provider_id" = 'credential' THEN 'local:credential' ELSE 'local:oauth:' || "provider_id" END WHERE "issuer" IS NULL; ALTER TABLE "account" ALTER COLUMN "issuer" SET NOT NULL; CREATE UNIQUE INDEX IF NOT EXISTS "account_issuer_account_id_uq" ON "account" USING btree ("issuer","account_id"); ``` Two limits are worth stating plainly. The OAuth branch reproduces `createOAuthAccountIssuer` for provider ids that need no percent-encoding, which covers every built-in provider id; a provider id with a character `encodeURIComponent` would escape would get a slightly different string. And a generic-OAuth provider that sets `accountIssuer` explicitly (Okta, Auth0, Keycloak, Slack, Line) uses the real issuer URL, which this migration cannot know. Neither case can arise on Paperclip today: `createBetterAuthInstance` configures `emailAndPassword` only and registers no social or generic-OAuth provider, so every existing row is a credential row. The OAuth branch is there so the backfill stays total rather than leaving a NULL that aborts `SET NOT NULL`. ## Verification - `pnpm --filter @paperclipai/db check:migrations` — passes. - `pnpm --filter @paperclipai/db typecheck` — passes. - `packages/db` suite: 30 files, 107 tests, all pass. - `npx tsc --noEmit` in `server/` — no error in any changed file. (The wrapped `pnpm typecheck` builds the runner vendor first, which needs cargo; that toolchain was not available here, so the pre-existing "cannot find module" errors from the unbuilt workspace packages remain in the bare run.) - `node --test scripts/__tests__/run-vitest-stable-shard.test.mjs` — passes with the new server suite in the file list. - The two new tests were confirmed to fail without the fix: - Reverting `packages/db/src/schema/auth.ts` to its `master` content makes the server test fail with the reported error and `expected 500 to be 200`. - Narrowing the backfill to `WHERE "issuer" IS NULL AND "provider_id" = 'credential'` makes the migration test fail with `column "issuer" of relation "account" contains null values` — the failure mode of #12269. - End to end against a server built from this branch, started with `PAPERCLIP_DEPLOYMENT_MODE=authenticated` on embedded PostgreSQL: - `POST /api/auth/sign-up/email` → 200 with a user and token. - `POST /api/auth/sign-in/email` → 200 with a session cookie. - `GET /api/auth/get-session` → 200 with the session. - The stored row is `issuer = 'local:credential'`, `provider_id = 'credential'`, `account_id = user_id`, and `pg_indexes` lists `account_issuer_account_id_uq`. - `scripts/docker-onboard-smoke.sh` was not used as proof: it installs `paperclipai` from npm inside the container, so it exercises a published release rather than this branch. ## Risks - **Migration.** The migration backfills every existing row before `SET NOT NULL`, so an install that upgrades keeps working and its users keep signing in. `account` is one row per user per provider, so the full-table `UPDATE` and the index build are cheap; `packages/db/src/table-size-estimates.ts` already classes `account` as small, and `check:migrations` passes with no new safety finding. - **New unique index.** `(issuer, account_id)` is the key Better Auth resolves accounts by, so a duplicate would already be a defect. Better Auth writes one credential account per user keyed on the user id, so the pair is unique by construction. An install that somehow holds a duplicate would fail the index build rather than corrupt anything, and the migration is a single transaction. - **Orphaned users are not repaired.** An address that hit the broken window has a `user` row and no `account` row. This migration does not delete or repair those rows, so that address stays unusable after the upgrade: sign-up says the user exists, and there is no credential account to sign in as or reset. Only installs that ran a build containing #11886 are affected, and the repair — deleting the orphaned `user` rows — is a judgment call about live data that does not belong in an automatic migration. - **Not a behavior change anywhere else.** Only the `account` table changes. Hosted tenants resolve their actor from a trusted header and never read it. ## Model Used Claude (Anthropic), Claude Opus, 1M context, extended thinking, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-27 22:31:35 -07:00
Devin Foley	bdd8f1bedb	Repair the drizzle snapshot so generate emits no spurious migration (#12333) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Paperclip keeps its state in PostgreSQL, and `packages/db` owns that schema through Drizzle > - `drizzle-kit generate` writes a new migration by diffing `packages/db/src/schema/` against the newest snapshot in `packages/db/src/migrations/meta/`, so the snapshot must describe the schema that the migrations produce > - Snapshot `0228` recorded the new `error_count` column on the wrong table, and snapshot `0229` inherited the error, so the newest snapshot no longer matched the schema > - Because of that, `generate` on `master` folded the drift into any new migration: it emitted an `ADD COLUMN` for a column that migration `0228` already creates, which fails on a fresh database, plus an out-of-scope `DROP COLUMN` > - This pull request moves the column entry to the correct table in both snapshots and adds a test that repeats the diff `generate` performs > - The benefit is that the next person who generates a migration gets only their own change, and CI fails if the snapshot drifts again ## Linked Issues or Issue Description No existing issue. The description below follows `.github/ISSUE_TEMPLATE/bug_report.yml`. **What happened?** `drizzle-kit generate` on `master` emits a wrong migration. The newest snapshot, `packages/db/src/migrations/meta/0229_snapshot.json`, disagrees with the schema in two places. It omits `issue_question_response_deliveries.error_count`, which `0228_nasty_grim_reaper.sql` creates. It also carries `decision_archive_notification_outbox.error_count`, which no migration ever creates and the Drizzle schema never declared. Snapshot `0228` introduced both halves of the error: it added the new `error_count` column to `decision_archive_notification_outbox` instead of the table that the same migration creates. Snapshot `0229` copied it forward. Any new migration therefore starts with two statements that do not belong to it: ```sql ALTER TABLE "issue_question_response_deliveries" ADD COLUMN "error_count" integer DEFAULT 0 NOT NULL; ALTER TABLE "decision_archive_notification_outbox" DROP COLUMN "error_count"; ``` The `ADD COLUMN` fails on a fresh database, because migration `0228` already creates that column. The `DROP COLUMN` targets a column that does not exist on any deployment. **Expected behavior** `drizzle-kit generate` reports "No schema changes, nothing to migrate" on a clean checkout of `master`, and a new migration contains only the author's own schema change. **Steps to reproduce** 1. Check out `master` at commit `bc1a21564`. 2. Run `pnpm install`. 3. Run `pnpm --filter @paperclipai/db generate`. 4. Read the emitted `packages/db/src/migrations/0230_*.sql`. It contains the two statements above, and no schema file was changed. **Paperclip version or commit** `master` at `bc1a21564`. The drift entered in #12307 (snapshot `0228`) and was carried forward by #12291 (snapshot `0229`), which worked around it by building its snapshot by hand. **Deployment mode** Not deployment specific. It affects anyone who generates a migration, and it affects any fresh database that would later run the bad migration. **Database mode** All PostgreSQL modes: embedded, local Docker, and hosted. ## What Changed - Moved the `error_count` column entry from `decision_archive_notification_outbox` to `issue_question_response_deliveries` in `packages/db/src/migrations/meta/0228_snapshot.json` and `packages/db/src/migrations/meta/0229_snapshot.json`. Both files keep their `id` and `prevId`, so the snapshot chain is unchanged. - Added `packages/db/src/migration-snapshot-drift.test.ts`. It reads the newest snapshot named by `_journal.json`, serializes the schema modules with `generateDrizzleJson`, and asserts that `generateMigration` returns no statements. This is the same diff that `generate` performs. - Documented the snapshot rule in `doc/DATABASE.md` under a new "Migration snapshots" section. No migration SQL was added, renumbered, or edited. No schema file changed. The database is correct as it is; only the snapshot was wrong. Why both snapshots and not only the newest one: `0229` is the file that `generate` reads, so repairing it is what fixes the bug. `0228` holds the same error, and `drizzle-kit drop` removes the last migration and its snapshot, which would promote `0228` back to newest and bring the drift back. Repairing both removes that trap. Snapshots are never applied to a database, so neither edit changes any deployment. ## Verification Commands run from the repository root. - `pnpm --filter @paperclipai/db generate` — "No schema changes, nothing to migrate 😴". It writes no SQL file, no snapshot, and no journal entry. `git status` stays clean. Before the fix, the same command wrote `0230_fast_caretaker.sql` with the two spurious statements. - The repaired `0229_snapshot.json` is byte-identical to the snapshot that a real `generate` run produced, except for the `id` and `prevId` that keep the chain intact. - Chain check: the repaired `0228` and `0229` snapshots now differ by exactly the two columns that `0229_drop_company_brand_color_and_attachment_max_bytes.sql` drops, `companies.brand_color` and `companies.attachment_max_bytes`, and by nothing else. - Database check: applied all 229 migrations in order to an embedded PostgreSQL, then compared the live schema with the repaired snapshot. 179 tables and 2687 columns match, with no missing column, no extra column, and no nullability difference. The same comparison against the pre-fix snapshot reports exactly two problems: `column only in snapshot: decision_archive_notification_outbox.error_count` and `column only in database: issue_question_response_deliveries.error_count`. This harness was a scratch script and is not part of the pull request. - `pnpm --filter @paperclipai/db typecheck` — pass. It runs `check:migrations`, which is `check-migration-numbering` and `check-migration-safety`. - `npx vitest run --root packages/db` — 28 files, 102 tests, all pass. This includes the new test. - New test, negative case: with the pre-fix `0229_snapshot.json` restored, `migration-snapshot-drift.test.ts` fails and prints exactly the two spurious statements, plus the instruction to run `generate`. It passes on the repaired snapshot. It takes about 1.2 seconds and needs no database. - `node scripts/check-forbidden-tokens.mjs` and `node scripts/check-no-git-push.mjs` — pass. ## Risks Low risk. A Drizzle snapshot is a build-time record for `drizzle-kit generate`. It is never applied to a database, so this change cannot alter any deployment, and no operator action is needed. Databases that already ran migrations `0228` and `0229` are correct today and stay correct. The proof is a clean `generate`: the command that produced the wrong migration now reports "No schema changes, nothing to migrate" and writes nothing. Two smaller notes: - The new test depends on `drizzle-kit/api`, which is already a dev dependency of `packages/db`. If a future `drizzle-kit` upgrade changes that surface, the test fails loudly at import rather than passing silently. - The test imports every module in `packages/db/src/schema/`, which is the same set that `drizzle.config.ts` points the CLI at. It deduplicates by object identity, because the barrel re-exports the same table objects and `drizzle-kit` rejects a table it sees twice. ## Model Used Claude (Anthropic), Claude Opus, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-27 12:56:07 -07:00
Devin Foley	bc1a21564f	Remove the company brand color and per-company attachment limit (#12291) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - A company is the top-level container, and the company General page holds its settings > - Two of those settings did almost nothing: the brand color only tinted the generated company icon, and the attachment size limit sat under the deployment-level `PAPERCLIP_ATTACHMENT_MAX_BYTES` cap that already bounded every upload > - A setting that changes one icon hue, and a setting that can only lower a limit the operator already set, are not worth the page space or the code that carries them > - This pull request deletes both settings from the UI, the validators, the API contract, the server, and the database > - With the deployment cap as the only limit left, the message a person sees when an upload is rejected has to name that limit in terms they can act on, so the raw byte count becomes a human-readable size > - The benefit is a shorter company General page for every deployment, one attachment limit instead of two, and less code between an upload and its ceiling ## Linked Issues or Issue Description No existing issue. The description below follows `.github/ISSUE_TEMPLATE/enhancement.yml`. **What existing behavior does this improve?** The company General page (`/company/settings`), the `PATCH /api/companies/{companyId}` and `PATCH /api/companies/{companyId}/branding` request contracts, and the attachment upload limit on task, case, and company-import uploads. **Subsystem affected** Cross-cutting: `ui/`, `server/`, `packages/shared`, `packages/db`. **Current behavior** The company General page shows an "Appearance" section with three controls: Logo, Brand color, and Attachment size limit. The brand color is a hex value that feeds one thing — the hue of the generated company pattern icon. Companies that never set one already get a hue derived from the company name. The attachment size limit is a per-company byte count stored on `companies.attachment_max_bytes`. Every upload path clamps it against the deployment-level `PAPERCLIP_ATTACHMENT_MAX_BYTES` cap, so the per-company value can only lower a limit the operator already chose. **Proposed behavior** The Appearance section keeps the Logo control only. The company pattern icon always derives its hue from the company name. Every attachment path reads the deployment cap directly, so `PAPERCLIP_ATTACHMENT_MAX_BYTES` is the single limit. An upload rejected by that limit says so in human units — "File is larger than the 10 MB limit" rather than a raw byte count. The `companies.brand_color` and `companies.attachment_max_bytes` columns are dropped, and both fields leave the company API contract. **Reason and benefit** Both settings ask an operator to make a decision that changes almost nothing. The brand color moves one icon hue on a page that also lets you upload a real logo, which overrides the icon entirely. The attachment limit reads as a real control but cannot raise anything, so it is a second place to look when an upload is rejected. Removing both shortens the page every deployment sees, removes a company-scoped read from the task attachment upload path, and leaves one attachment limit to reason about instead of two. **Breaking changes** The company API responses no longer include `brandColor` or `attachmentMaxBytes`, and `GET /api/invites/{token}` no longer includes `companyBrandColor`. `PATCH /api/companies/{companyId}/branding` is strict, so a request that sends `brandColor` now returns 400; the non-strict `PATCH /api/companies/{companyId}` schema strips it. Company packages exported by older versions still import: the portability company manifest schema is non-strict, so the retired keys are stripped and ignored rather than rejected. Companies that stored a brand color lose it — their icon reverts to the name-derived hue that every company without a color already used. ## What Changed - Removed the "Brand color" and "Attachment size limit" fields from the company General page, along with their state, dirty checks, save payload, and Save-button gating. - Removed `brandColor` and `attachmentMaxBytes` from `createCompanySchema`, `updateCompanySchema`, and `updateCompanyBrandingSchema`, and deleted the now-orphaned `DEFAULT_COMPANY_ATTACHMENT_MAX_BYTES` and `MAX_COMPANY_ATTACHMENT_MAX_BYTES` constants. - Removed both fields from the `Company` type, the portability manifest type and schema, and the `companiesApi.update` payload allowlist. - Dropped `brandColor` from `CompanyPatternIcon` and its callers, so the icon hue always comes from the company name. Deleted the now-unused `hexToHue` helper and the now-unused `pickTextColorForSolidBg` export. - Stopped emitting `brandColor` from the company service selection and from the invite-summary and invite-branding payloads in `server/src/routes/access.ts`. - Replaced `normalizeIssueAttachmentMaxBytes` with the deployment cap: task attachments, case attachments, and company import now use `MAX_ATTACHMENT_BYTES` directly. The helper is deleted. - Added `formatAttachmentSize()` next to `MAX_ATTACHMENT_BYTES` and routed every over-limit message through it, so a rejected upload names the limit in human units instead of raw bytes: `Image exceeds 10485760 bytes` becomes `Image is larger than the 10 MB limit`. Enforcement is unchanged — the same single cap, the same multer limits, the same status codes and response shapes. - Added migration `0229_drop_company_brand_color_and_attachment_max_bytes.sql` and removed both columns from the Drizzle `companies` schema. - Kept legacy imports working: the portability company manifest schema is non-strict, so older packages carrying the retired keys still import with the keys ignored. - Updated the skill API reference and the implementation spec, and pruned the token-extraction allowlist entries that the removed code made stale. ## Verification Commands run from the repository root: - `pnpm --filter @paperclipai/shared typecheck` — pass - `pnpm --filter @paperclipai/db typecheck` — pass (includes `check:migrations`, which validates the new migration number and journal entry) - `pnpm --filter @paperclipai/ui typecheck` — pass - server typecheck via `node_modules/.bin/tsc --noEmit` in `server/` — pass. `pnpm --filter @paperclipai/server typecheck` could not run locally because it builds the Rust runner first and `cargo` is not installed on this machine; the TypeScript step it wraps is the command above. - `npx vitest run packages/shared/src/validators/company.test.ts` — 6 passed - `npx vitest run server/src/__tests__/company-portability.test.ts` — 90 passed - `npx vitest run server/src/__tests__/attachment-types.test.ts server/src/__tests__/assets.test.ts server/src/__tests__/issue-attachment-routes.test.ts server/src/__tests__/company-portability.test.ts server/src/__tests__/cases-routes.test.ts` — 165 passed (the human-readable limit messages) - `npx vitest run server/src/__tests__/company-branding-route.test.ts server/src/__tests__/issue-attachment-routes.test.ts server/src/__tests__/invite-summary-route.test.ts server/src/__tests__/openclaw-invite-prompt-route.test.ts server/src/__tests__/companies-route-cross-company-authz.test.ts` — all passed - `npx vitest run cli/src/__tests__/company.test.ts cli/src/__tests__/company-delete.test.ts` — 27 passed - `npx vitest run` in `ui/` — 4425 passed, 1 pre-existing failure unrelated to this change (`OnboardingWizard.test.tsx` "renders instead of throwing when the browser denies storage access", which also fails on `master`) - `npx vitest run` in `server/` — see the note below - `node scripts/check-token-gates.mjs` — no new violations; the only reported violations are the pre-existing `PillGuy.tsx` ones present on `master` New tests added: - `packages/shared/src/validators/company.test.ts` — the create and update schemas strip the retired keys, the strict branding schema rejects `brandColor`, and the portability manifest schema accepts a legacy entry carrying both keys and drops them. - `server/src/__tests__/company-branding-route.test.ts` — `PATCH /api/companies/{companyId}/branding` returns 400 for `brandColor` and does not call the company service. - `server/src/__tests__/company-portability.test.ts` — a legacy package that declares `brandColor` and `attachmentMaxBytes` imports successfully, and neither key reaches `companies.create`. - `server/src/__tests__/issue-attachment-routes.test.ts` — the effective task attachment limit is the deployment cap, and the route no longer loads the company to size an upload. - `server/src/__tests__/attachment-types.test.ts` — `formatAttachmentSize()` renders the default cap as `10 MB`, keeps one decimal place for fractional sizes and drops a trailing `.0`, falls back to KB and bytes for small caps, steps up to GB, and never emits `NaN` for a degenerate input. - `server/src/__tests__/assets.test.ts` — the asset-image and company-logo routes both return the human-readable limit message on an over-cap upload. ## Merge with master `master` moved while this was open, and the merge needed two resolutions: - **`ui/src/pages/CompanySettings.tsx`.** #12243 reworded the user-facing copy from "company" to "organization", and that rewording landed inside the "Brand color" and "Attachment size limit" hints — the two fields this change deletes. Both fields are removed, so the conflicted block is dropped whole. The Logo field and every other copy change from #12243 are kept. - **Migration renumbered 0228 -> 0229.** #12307 landed `0228_nasty_grim_reaper`, so this migration is now `0229_drop_company_brand_color_and_attachment_max_bytes`. Its snapshot is rebuilt from master's `0228_snapshot.json` with only the two `companies` columns removed, and `meta/_journal.json` is master's journal plus a single `idx: 229` entry. `pnpm --filter @paperclipai/db check:migrations` passes. The snapshot was rebuilt by hand rather than taken from `drizzle-kit generate`, because master's `0228_snapshot.json` has drifted from master's own schema: `issue_question_response_deliveries.error_count` is created by master's 0228 SQL but missing from its snapshot, and the snapshot still carries `decision_archive_notification_outbox.error_count`. Regenerating folds both into this migration, and the resulting `ADD COLUMN error_count` would fail on a fresh database where master's 0228 already created that column. Rebuilding from master's snapshot leaves that drift exactly where it is and keeps this migration to the two column drops. The drift is pre-existing on master and is not addressed here. ## Risks - **The migration is a destructive column drop.** `0229_drop_company_brand_color_and_attachment_max_bytes.sql` removes `companies.brand_color` and `companies.attachment_max_bytes`. It is safe because both features are removed in the same change and nothing reads either column after it. The statements use `DROP COLUMN IF EXISTS`, matching the convention of the recent drop migrations in this repository. The drop is not reversible: a downgrade after this migration loses any stored values. - **Stored brand colors are lost.** A company that had set a color now renders the name-derived icon hue that every company without a color already used. No other surface changes, and an uploaded logo still overrides the icon. - **API response shape narrows.** `brandColor` and `attachmentMaxBytes` leave the company payloads, and `companyBrandColor` leaves the invite summary payload. A client reading those fields now sees `undefined`. The bundled UI and CLI are updated in this change. - **Legacy imports are covered.** Packages exported by older versions still carry both keys. The manifest schema is non-strict, so the keys are stripped rather than rejected, and a test locks that in. - **The over-limit message strings changed.** Anything matching on the old `... exceeds N bytes` text — a test, a script, or a client that string-matches `body.error` — needs updating. The status codes (422) and response shapes are unchanged, so structured clients are unaffected. - **Attachment limits can only widen.** A deployment that had lowered a company below the deployment cap now allows uploads up to the cap for that company. Lower `PAPERCLIP_ATTACHMENT_MAX_BYTES` if a smaller ceiling is needed. - **Storybook visual baselines shift** for the `CompanyPatternIcon` matrix story, because those fixtures had brand colors. That workflow runs only on a PR labeled `storybook-visual`, so it does not gate this PR; regenerate the baselines if the label is added. ## Model Used Claude (Anthropic), Claude Opus, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-27 12:11:05 -07:00
Devin Foley	7b91fe9ea7	Hide host-path and execution-engine surfaces in managed-sandbox-only mode (#12293) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - An instance can turn on the `enableManagedSandboxOnly` feature, which hides the local environment and runs every agent in the platform-managed environment > - That feature already gated the environment pickers, the onboarding wizard, and the server-side run selection, but many other screens still showed absolute paths on the execution host and still let the user pick an execution engine > - On such an instance those controls name a filesystem the user cannot reach; a path written there is stored and then ignored, which reads as a broken control > - This pull request hides the remaining host-path and execution-engine surfaces behind the same feature, adds a server rule that refuses a project-workspace path write while the feature is on, and closes a related route gap in the isolated-workspace pages > - The benefit is that a managed instance shows no host path and no folder picker anywhere, and a write that carries a path now fails with a clear message instead of being silently discarded ## Linked Issues or Issue Description No public issue exists. The description below follows `.github/ISSUE_TEMPLATE/enhancement.yml`. **What existing behavior does this improve?** The `enableManagedSandboxOnly` instance feature, and the UI surfaces that show a host filesystem path: project properties, the new-project dialog, the project workspace and execution workspace detail pages, the workspace and task cards, plugin local folders, and the agent configuration form with its per-adapter fields. It also improves route gating for `enableIsolatedWorkspaces`. **Subsystem affected** Cross-cutting (`ui/` and `server/`). **Current behavior** When `enableManagedSandboxOnly` is on, the local environment disappears from the environment pickers and the server refuses to run an agent on the local host. Everything else stays visible. A user still sees: - the project "Local folder" row, its absolute path, and the Set/Change/Clear buttons - the "Local folder" field and its "Choose" folder picker in the new-project dialog - the "Local path" field and fact row on a project workspace - the "Paths" and "Lifecycle commands" groups on an execution workspace - the working directory on workspace cards, task properties, and runtime service rows - the plugin "Local folders" section - "Working directory (deprecated)", "Command", "Execution engine", "ACP server command", "ACP state directory", and "Agent instructions file" in the agent configuration form A path typed into any of these names a filesystem no agent on the instance uses. The project workspace API also accepts a `cwd` write and stores it. Separately, `/workspaces`, `/execution-workspaces/*`, and `/projects/:projectId/workspaces/:workspaceId` render for anyone who types or bookmarks the URL, even with `enableIsolatedWorkspaces` off. Only the sidebar entry reads that flag. **Proposed behavior** With `enableManagedSandboxOnly` on, none of those surfaces render. A project whose codebase came from a managed checkout keeps its one-line "Paperclip-managed folder." label and shows no path. The non-path controls stay: repo URL, branch, service URL, port, command output, ACP session mode, ACP non-interactive permissions, Codex fast mode, and the sandbox toggles. The project-workspace create and patch routes, and the nested workspace on project create, answer `422` with "This instance runs agents only in the platform-managed environment; local folders are not configurable." when the payload carries a non-null `cwd`. A `cwd: null` write still passes, so an instance that just turned the feature on can clear a stale path. With `enableIsolatedWorkspaces` off, the three workspace route groups redirect to the dashboard. **Reason and benefit** A control that cannot do anything is worse than a missing control: the user fills it in, saves, and gets no error and no effect. The server rule turns that silent no-op into a clear refusal. The route gate stops a feature that an instance has turned off from staying reachable by URL, which is the same standard the Cases, Pipelines, and hidden-settings pages already meet. **Breaking changes** None for a default instance: both flags are off by default for self-hosted and managed instances, so nothing changes unless an operator turns them on. Stored `adapterConfig` values are never cleared, so turning the feature off restores every previous value. ## What Changed - Add `ui/src/hooks/useManagedSandboxOnly.ts`, modelled on `useAppsEnabled`, for components that do not already read the experimental settings. It exposes `hideHostPaths`, which fails closed while the settings query is in flight, so a cold cache never flashes a host path before the policy resolves. Components that keep their own settings read compute the same gate from `isFetched`. - Add `managedSandboxOnly` to `AdapterConfigFieldsProps` and populate it where `AgentConfigForm` builds the adapter field props. Resolve the effective instructions-file gate once as `hideInstructionsFile || hideHostPaths`, so every adapter hides that path field with no per-adapter edit. - Hide under the flag: the project "Local folder" block and its absolute-path edit panel (a managed checkout keeps its label, without the path); the new-project "Local folder" field; the project-workspace "Local path" field and fact row; the execution-workspace "Paths" and "Lifecycle commands" groups; the working directory on the workspace summary card, the task workspace card, the task properties "Folder" row, and the runtime service rows; the plugin "Local folders" section; "Working directory (deprecated)" and "Command" in the agent form; and the per-adapter "Execution engine", "ACP server command", and "ACP state directory" for `claude_local`, `codex_local`, and `gemini_local`. - Drop two working-directory fallbacks that had no gate to read: the close-workspace dialog now falls back to "No additional details", and the reuse-existing workspace label and picker subtitle fall back to a neutral phrase. - Refuse a non-null `cwd` with `422` on `POST /projects/:id/workspaces`, `PATCH /projects/:id/workspaces/:workspaceId`, and the nested workspace on `POST /companies/:companyId/projects`, following the `assertNoAgentHostWorkspaceCommandMutation` precedent on those routes. - Add `IsolatedWorkspacesRouteGate` and wrap the `/workspaces`, `/execution-workspaces/*`, and `/projects/:projectId/workspaces/:workspaceId` routes with it. - Leave the SSH "Remote workspace path" and the workspace file browser alone, with a comment explaining why. ## Verification Automated: - `pnpm --filter @paperclipai/ui exec vitest run` — 479 of 480 files pass (4455 of 4456 tests). The one failure is `OnboardingWizard.test.tsx > renders instead of throwing when the browser denies storage access`, which also fails on `origin/master` and is unrelated to this change. - `pnpm --filter @paperclipai/server exec vitest run project workspace instance-settings` — 45 of 50 files pass. Four files fail on macOS for reasons unrelated to this change: `workspace-instance-cleanup`, `workspace-runtime`, `execution-workspace-runtime-control-conflict`, and `workspace-runtime-exposure` compare `/var/...` against the resolved `/private/var/...` or bind real ports. The same files fail on a clean `master` checkout on the same machine. - `pnpm --filter @paperclipai/ui typecheck` - `tsc --noEmit` in `server/` (after `pnpm --filter @paperclipai/plugin-sdk ensure-build-deps`). The package `typecheck` script also builds the Rust runner, which needs `cargo`; it is not installed on the machine that ran this. New and extended tests: - `ui/src/adapters/managed-sandbox-only-config-fields.test.tsx` — the three adapters drop the execution engine, the ACP paths, the instructions-file path, and every "Choose" button when the flag is on, and keep the non-path controls. - `ui/src/components/AgentConfigForm.render.test.tsx` — flag-on and flag-off renders for the working directory, the command, the engine, the ACP paths, and the resolved adapter field props. - `ui/src/components/ProjectProperties.managed-sandbox.test.tsx`, `ui/src/components/NewProjectDialog.managed-sandbox.test.tsx`, `ui/src/pages/ProjectWorkspaceDetail.test.tsx`, `ui/src/components/ProjectWorkspaceSummaryCard.test.tsx`, `ui/src/components/WorkspaceRuntimeControls.test.tsx`. - `ui/src/components/IsolatedWorkspacesRouteGate.test.tsx` — redirect when off, render when on, and render nothing while the flag query is in flight. - "Still loading" cases for the project properties, the new-project dialog, the workspace summary card, the runtime service rows, and the agent configuration form, each asserting that no host path renders before the policy resolves. - `server/src/__tests__/project-workspace-managed-sandbox-routes.test.ts` — the `422` on all three write paths, the `cwd: null` pass-through, and the flag-off pass-through. Manual check to reproduce: turn on Managed Environment Only in instance experimental settings, then open a project, the new-project dialog, an agent's configuration, and a workspace page. No path, folder icon, or "Choose" button appears. Turn the setting off and each control returns with its stored value. No documentation change was needed. The operator-facing text for both settings lives in the feature catalog entry, which already states the contract this pull request now enforces across the UI. ## Risks - Low. Both flags default to off, so a default instance is unchanged. - The hidden fields are presentation only. No stored `adapterConfig` value is cleared, because an import carries adapter configuration written on another instance and clearing it would break that flow. Turning the setting off shows every previous value again. - The `422` is the one behavior change for an API caller, and only while the setting is on. `cwd: null` still passes so a stale path can be cleared. - The route gate renders nothing until the flag query settles, so an instance with isolated workspaces on never flashes a redirect. An instance with the feature off now redirects a bookmarked workspace URL to the dashboard. - Every host-path guard fails closed while the settings query is in flight, so a default instance shows those controls a moment later than before on a cold load. That is the safe direction: the alternative flashes a path a managed instance must never show. - Two path surfaces stay on purpose, each with a comment: the SSH "Remote workspace path" is a path on the user's own remote host, and the workspace file browser shows workspace-relative paths. The instance Adapters page also keeps its "Local path" install option, since that page is an instance-admin surface the hosting operator can already hide through the hidden-settings mechanism. ## Model Used Claude (Anthropic), Claude Opus, 1M context window, extended thinking, agentic tool use through Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-27 11:59:14 -07:00
Devin Foley	76f7019bdf	feat(server): derive hosted-tenant issue prefixes from the company name and follow renames (#12292) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Every company has an issue prefix. It is the visible half of each task and case identifier, and a self-hosted company derives it from the name it was created with > - A hosted or managed instance does not use the create-company flow. The trusted-header auth path claims the tenant company instead > - That path minted the prefix from a hash of the stack id, and it wrote a placeholder description that nobody chose > - So a hosted company showed opaque task IDs such as `PC7F2A-14`, and a rename never changed them > - This pull request derives the prefix from the company name on that path too. It re-derives the prefix when the name changes on a managed instance, and it rewrites the stored issue and case identifiers so existing tasks follow the rename > - It also repairs each company that an earlier build claimed. The repair runs once, on the next authenticated request > - The benefit is that task IDs on a hosted instance read like the ones on a self-hosted instance, and they stay correct after a rename ## Linked Issues or Issue Description No public issue exists. The description below follows `.github/ISSUE_TEMPLATE/enhancement.yml`. **What existing behavior does this improve?** The tenant company claim in `resolveCloudTenantActor` (`server/src/middleware/auth.ts`) and the company update in `companyService.update` (`server/src/services/companies.ts`). Both decide the `issue_prefix` and the `description` of a company on a hosted or managed instance. **Subsystem affected** `server/` — REST API and orchestration services. One small hint was also added in `ui/`. **Current behavior** A self-hosted company gets its issue prefix from its name. "Acme Robotics" becomes `ACM`, and its tasks read `ACM-14`. A hosted or managed instance claims the company through the trusted-header auth path. That path wrote a different prefix: `"PC"` plus the first four hex characters of the SHA-256 of the stack id. The same path also wrote a placeholder description, `"Provisioned by ... for stack <stack id>."`. The result is a task ID such as `PC7F2A-14`. It says nothing about the company. A later rename of the company does not change it, because nothing re-derives the prefix after creation. **Proposed behavior** The claim path derives the prefix from the company name, exactly as the create-company flow does. It writes no description. On a managed instance, a rename re-derives the prefix. The stored issue and case identifiers move with it, so `ACM-14` becomes `NOR-14` when "Acme Robotics" becomes "Northwind Traders". A rename that keeps the same three-letter base keeps the current prefix, including any disambiguating suffix. A self-hosted instance is unchanged. A rename there still keeps the prefix the company was created with. Companies that an earlier build already claimed get a one-time repair on their next authenticated request. The repair re-derives the prefix from the current name, re-keys the identifiers, and clears the placeholder description. **Reason and benefit** A task ID is the primary handle for a task. People type it, paste it into chat, and read it in a URL. On a hosted instance that handle was an opaque hash, and it disagreed with the company name that the same user chose during signup. The name is the only prefix source a hosted user ever supplies, so the prefix now follows it. **Breaking changes** Yes, on hosted and managed instances only. A company rename now rewrites the stored issue and case identifiers. Links that carry an old identifier stop resolving after the rename. The company settings page states this before the user saves. The one-time repair applies the same rewrite once to companies that carry the old hash prefix. Self-hosted behavior does not change. ## What Changed - Added `server/src/services/issue-prefix.ts`. It holds the prefix helpers that used to live inside the `companyService` closure: `ISSUE_PREFIX_FALLBACK`, `deriveIssuePrefixBase`, `issuePrefixSuffixForAttempt`, and `isIssuePrefixConflict`. The companies service now imports them. - Added `pickAvailableIssuePrefix` to that module. It reads the prefixes in one base family and returns the first free candidate. A standalone `INSERT` can retry on a unique violation, because each failed statement is its own implicit transaction. A caller that already holds a transaction cannot, because the violation aborts the whole transaction. Such a caller picks first, then writes. - Added `rekeyCompanyIssueIdentifiers` to that module. It rewrites the prefix of the stored `issues.identifier` and `cases.identifier` values of one company in the caller's transaction, and it returns the two row counts. - `companyService.update` re-derives the prefix when the name changes on a managed instance, re-keys both tables in the same transaction, and writes a `company.updated` activity entry after the commit. - `resolveCloudTenantActor` claims the company with a name-derived prefix and a null description. The claim retries with the next suffix when the prefix is taken. - `resolveCloudTenantActor` also runs a one-time repair for companies that carry the old hash prefix. An exact-match fence on the update lets a concurrent rename win. The repair is idempotent, because its guards stop matching after it lands. - The rename takes a row lock on the company before it compares anything against it, and it re-keys from the prefix it reads under that lock. Only patch and environment facts gate the lock, so no stale read can steer the decision. Two overlapping updates would otherwise leave a company whose prefix disagrees with its own identifiers, in either direction: two renames, where the second re-keys from a prefix the first already moved; or a rename plus a stale form that resubmits the original name, where the second sees an unchanged name, skips re-derivation, and restores the old name on top of the first rename's prefix. Only a managed instance takes the lock, and only for an update that carries a name. - Both helpers compare an exact identifier head instead of a LIKE pattern. A stored prefix is data, so it must never be read as a pattern. - The company settings page shows a hint under the name field on a managed instance: renaming can change the task ID prefix. ## Verification Automated tests: ``` pnpm --filter @paperclipai/server exec vitest run \ src/services/issue-prefix.test.ts \ src/__tests__/companies-service.test.ts \ src/__tests__/cloud-tenant-company-provisioning.test.ts \ src/middleware/cloud-tenant-actor.test.ts \ src/__tests__/auth-session-route.test.ts \ src/__tests__/cloud-routes.test.ts \ src/__tests__/cloud-instance.test.ts \ src/__tests__/company-branding-route.test.ts \ src/__tests__/company-cloud-floor.test.ts \ src/__tests__/companies-route-cross-company-authz.test.ts \ src/__tests__/companies-route-path-guard.test.ts \ src/__tests__/company-portability.test.ts pnpm --filter @paperclipai/ui exec vitest run pnpm --filter @paperclipai/ui typecheck ``` New coverage: - `server/src/services/issue-prefix.test.ts` covers the derivation, the suffix ladder, the cause-chain walk of the unique-violation detector, and `pickAvailableIssuePrefix` against a stubbed select. - `server/src/__tests__/companies-service.test.ts` covers a managed rename against a real Postgres database: the prefix moves, both identifier tables are re-keyed, and the activity entry is written. It also covers a same-base rename, a collision that takes the suffixed candidate, a non-name patch, and a self-hosted rename that leaves the prefix alone. Two more tests drive the overlap cases: two concurrent renames of the same company, and a rename racing a stale form that resubmits the original name. Both assert that the surviving name's base matches the company prefix and that the stored identifiers sit on that prefix. - `server/src/__tests__/cloud-tenant-company-provisioning.test.ts` covers the claim path and the repair against a real Postgres database: a name-derived prefix, a null description, a suffixed prefix on collision, the full repair, a second pass that changes nothing, a description-only repair, and an operator-written description that the repair leaves alone. - `ui/src/pages/CompanySettingsRenameHint.test.tsx` covers the hint on a managed instance and its absence on a self-hosted instance. The `substring` cast in `rekeyCompanyIssueIdentifiers` is load-bearing and the database tests prove it. The driver binds the offset as text. Without the `::int` cast Postgres resolves the SQL-regex overload of `substring`, and every identifier becomes NULL. ## Risks - **Re-keying changes existing identifiers and URLs.** This is deliberate, and it happens on hosted and managed instances only. After a rename, a link that carries an old task identifier stops resolving. The settings page warns about this before the user saves. - **Identifiers inside comment text are not rewritten.** Only the `identifier` columns of `issues` and `cases` move. A task ID that someone typed into a comment, a description, or a document keeps the old prefix. - **A lost prefix race inside the rename transaction surfaces as a conflict.** The rename picks a free prefix and then writes, because a unique violation inside a transaction aborts the whole transaction. Two *different* companies renamed onto the same base at the same moment can still collide. The loser sees its PATCH fail with the unique violation. The write is retryable by the client, and the window is a single statement wide. Two renames of the *same* company no longer race: the row lock serializes them, and the second one re-keys from what the first committed. - **The rename holds a row lock.** A managed rename takes `SELECT ... FOR UPDATE` on its own company row for the rest of the transaction. It is one row, and no other path in the transaction locks a company row, so there is no lock-order cycle. A self-hosted instance and every non-rename company update never reach the lock. - **The one-time repair is best effort.** It runs inside a try/catch and logs a warning on failure, so it never blocks authentication. A failed pass is retried on the next request, because its guards still match. - No schema change and no migration. ## Model Used - Provider: Anthropic (Claude) - Model: Claude Opus, model id `claude-opus-5[1m]` - Context window: 1M - Reasoning mode: extended thinking - Capabilities used: agentic tool use through Claude Code (file edits, shell, test runs against an embedded Postgres database) ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-27 11:34:42 -07:00
Devin Foley	a4f1b3c533	Move company invites into a tab of the Members page (#12289) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Company settings include member management and invites, which are one workflow: invite someone, watch the join request, manage the membership > - Today invites sit on a standalone settings page, costing a sidebar entry and forcing people to bounce between two pages for one task > - Merging invites into the Members page keeps the workflow in one place without losing any capability > - This pull request turns the Members page into a Members/Invites tab bar, redirects the old URL, and keeps both operator-visibility keys meaningful > - The benefit is a tighter settings surface for every deployment, with `company.invites` now hiding just the tab while `company.members` hides the whole page ## Linked Issues or Issue Description No public issue exists; describing the issue inline per the enhancement template: **What existing behavior does this improve?** Company invites live on a standalone settings page separate from the Members page, even though inviting someone and managing the resulting membership are one workflow. **Subsystem affected** Web UI (company settings) **Current behavior** `/company/settings/invites` is its own page with its own sidebar entry (gated by `company.invites`); the Members page (`company.members`) is separate. The sidebar company menu's "Invite people" shortcut links to the invites page and is not gated by the hidden-settings mechanism at all. **Proposed behavior** The Members page carries a Members/Invites tab bar, addressable via `?tab=invites`. The invite creation flow, latest-link panel, and invite history move unchanged into an `InvitesSection` component. The old URL redirects to the tab (still behind its `HiddenSettingsPageGate`). `company.members` hides the whole page; `company.invites` hides just the Invites tab, and the tab bar collapses when only Members remains. The "Invite people" shortcut points at the tab and hides when either surface is operator-hidden. **Reason and benefit** One settings surface for one workflow: fewer sidebar entries and no bouncing between two pages to invite someone and then manage the membership. Operators keep the same visibility controls, with a sharper meaning for each key. **Breaking changes** None. Bookmarks to the old invites URL redirect to the tab, invite and membership APIs are unchanged, and both hidden-settings keys keep working. ## What Changed - `ui/src/pages/CompanyInvites.tsx` → `ui/src/components/access/InvitesSection.tsx` (page chrome and breadcrumbs dropped; content unchanged), with its tests moved alongside. - `ui/src/pages/CompanyAccess.tsx`: Members/Invites tabs via the shared `PageTabBar`, `?tab=invites` search param, `company.invites` gating with tab snap-back; legacy "Open Invites" button retargeted. - `ui/src/App.tsx`: the invites route becomes a gated redirect to `/company/settings/members?tab=invites`. - `CompanySettingsSidebar` / `CompanySettingsNav`: standalone Invites entry/tab removed; the old path maps to the members tab. - `ui/src/components/SidebarCompanyMenu.tsx`: "Invite people" now links to the tab and hides when `company.members` or `company.invites` is hidden (closes an existing gating gap). - Tests: moved invites tests, new tab coverage (default tab, deep link, operator-hidden tab skips the invites fetch), sidebar/nav suites updated. ## Verification - `npx vitest run ui/src/components/CompanySettingsSidebar.test.tsx ui/src/components/access/CompanySettingsNav.test.tsx ui/src/pages/CompanyAccess.test.tsx ui/src/components/access/InvitesSection.test.tsx` — 24 tests passing. - `pnpm --filter @paperclipai/ui typecheck` — clean. ## Risks - Low. Pure UI restructure: invite APIs, membership APIs, and the hidden-settings registry keys are unchanged. Bookmarks to the old invites URL redirect (and stay gated). The `company.invites` key's meaning narrows from "hide the page" to "hide the tab", which is the same effective surface. ## Model Used Claude (Anthropic), model id `claude-fable-5`, extended thinking, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-27 11:34:32 -07:00
Devin Foley	7551b63ef2	Remove the instance Heartbeats settings page (#12282) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Instance settings collect deployment-wide controls; one of them was the Heartbeats page, an instance-wide list of scheduler heartbeat agents with enable/disable toggles > - The same controls live on each agent's own configuration surface, so the standalone list duplicates them, and its framing no longer matches how heartbeat agents are managed > - Keeping a settings view that no longer makes sense costs every deployment navigation noise and maintenance > - This pull request removes the page, its route, its navigation entries, and its hidden-settings key for all deployments > - The benefit is a smaller, coherent settings surface, with operator hidden-settings lists that still mention the retired key continuing to work unchanged ## Linked Issues or Issue Description No public issue exists; describing the issue inline per the enhancement template: **What existing behavior does this improve?** The instance settings surface — specifically the Settings → Heartbeats page, which listed scheduler heartbeat agents instance-wide with enable/disable toggles. The view no longer makes sense as a standalone settings page: the same controls are available on each agent's configuration surface, and the instance-wide list framing does not match how heartbeat agents are managed. **Subsystem affected** Cross-cutting: `ui/` (page, route, navigation), `packages/shared` (settings-visibility registry), docs. **Current behavior** The page renders at `/company/settings/instance/heartbeats`, appears in the settings sidebar and tab bar, and is hideable by hosting operators via the `instance.heartbeats` key of `PAPERCLIP_HIDDEN_SETTINGS`. **Proposed behavior** The page, route, and navigation entries are removed for every deployment. The `instance.heartbeats` registry key is retired; operator lists that still send it are logged and ignored, so mixed-version fleets keep working. Remembered settings paths pointing at the old page remap to the settings root. Heartbeat APIs are unchanged. **Reason and benefit** A smaller, coherent settings surface with no duplicated controls; less navigation noise and maintenance for every deployment. **Breaking changes** None functional. Bookmarks and remembered paths to the removed page land on the settings root; `PAPERCLIP_HIDDEN_SETTINGS` lists that still include `instance.heartbeats` log a warning and are otherwise honored unchanged. ## What Changed - Deleted `ui/src/pages/InstanceSettings.tsx` (the Heartbeats view) and its route in `ui/src/App.tsx`. - Removed the sidebar entry (`CompanySettingsSidebar`) and tab-bar item (`CompanySettingsNav`). - Removed `"/heartbeats"` from the remembered-settings-path allowlist; remembered heartbeats paths now remap to the settings root. - Retired the `instance.heartbeats` key from the shared settings-visibility registry and the environment-variables doc; documented that retired keys are ignored with a warning. - Dropped the now-unused UI client wrapper for the instance scheduler-agent list (`heartbeatsApi.listInstanceSchedulerAgents`); the server endpoint stays. - Removed the unused `schedulerHeartbeats` query key. ## Verification - `npx vitest run packages/shared/src/settings-visibility.test.ts ui/src/lib/instance-settings.test.ts ui/src/components/CompanySettingsSidebar.test.tsx ui/src/components/access/CompanySettingsNav.test.tsx` — 24 tests passing. - Full `ui` vitest suite: 4426 tests, 4 failures — all in files this PR does not touch; 3 were load-induced timeouts that pass on rerun, and `OnboardingWizard.test.tsx` "renders instead of throwing when the browser denies storage access" fails identically on a clean master checkout (pre-existing). - `pnpm --filter @paperclipai/ui typecheck` and `pnpm --filter @paperclipai/shared typecheck` — clean. - Merged `master` to clear a conflict (see below) and re-ran the four focused suites (24 passing), `ui/src/App.test.tsx` and `ui/src/plugins/bridge.test.ts` (22 passing), and both typechecks — all clean. Full CI is green on the merge commit. ## Merge With master `master` gained the `company` → `organization` copy pass (#12243), which reworded strings inside `ui/src/pages/InstanceSettings.tsx` — the page this branch deletes — producing a modify/delete conflict. Resolved by keeping the deletion: the page is going away, so the rewording of its copy has nothing to apply to. Every other file merged cleanly, and `master`'s rewording in `App.tsx`, `App.test.tsx`, and `CompanySettingsSidebar.tsx` sits away from this branch's structural removals, so both changes survive. The net diff against `master` is unchanged from the pre-merge review: the same 13 files, 23 insertions, 330 deletions. ## Risks - Low. Pure removal of a UI surface; heartbeat data and APIs are untouched. Operators still listing `instance.heartbeats` in `PAPERCLIP_HIDDEN_SETTINGS` get a warning log and otherwise unchanged behavior (covered by the registry's unknown-key handling). Bookmarks and remembered paths to the old page land on the settings root. ## Model Used Claude (Anthropic), model id `claude-fable-5`, extended thinking, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-27 11:31:43 -07:00
Devin Foley	8f195c2f49	Let operators supply defaults for selected instance settings (#12285) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Hosting operators (a managed cloud, an internal shared server) tune the settings surface with `PAPERCLIP_HIDDEN_SETTINGS`, but hiding a control never changes its value > - An instance whose stored feedback-sharing preference is still the schema default ("prompt") keeps prompting users even when the operator hid the control, leaving them no way to answer > - More generally, operators have no supported way to change what a setting defaults to without patching code > - This pull request adds `PAPERCLIP_SETTING_DEFAULTS`, a generic operator-supplied read-time default overlay for registry-listed general settings > - The benefit is that any hosting operator can pair "hide the control" with "default the value", while explicit user choices and self-hosted stock behavior stay untouched ## Linked Issues or Issue Description No public issue exists; following the enhancement template: **What existing behavior does this improve?** Hosting operators need to supply the default value of selected instance settings (first: `feedbackDataSharingPreference`) via configuration, without patching code and without a hard-coded, opinionated constant in the product. **Subsystem affected** Server (instance-settings service, feedback service, boot) and `packages/shared` (settings schemas). **Current behavior** Setting defaults are fixed in the shared zod schemas. `PAPERCLIP_HIDDEN_SETTINGS` can hide the feedback-sharing control and floor writes, but the stored value stays "prompt", so issue-chat surfaces keep prompting with no way to answer. **Proposed behavior** `PAPERCLIP_SETTING_DEFAULTS` takes a JSON object validated against a shared registry of defaultable fields. The operator value substitutes for the schema default at read time: a field whose effective value is still the schema default resolves to the operator value; an explicit non-default user choice always wins. Never persisted; unsetting the variable restores stock behavior. Malformed JSON or an invalid value for a known field refuses startup (fail closed); unknown field names warn and are ignored (mixed-version fleet safe). **Reason and benefit** Any hosting operator can pair "hide the control" with "default the value" without forking the product. Explicit user choices and self-hosted stock behavior stay untouched. **Breaking changes** None. With the variable unset, every read path is byte-identical to before. ## What Changed - New `packages/shared/src/setting-defaults.ts`: `SETTING_DEFAULTS_ENV_KEY`, `DEFAULTABLE_GENERAL_SETTINGS` registry (currently `feedbackDataSharingPreference`), `parseSettingDefaults` (fail-closed for policy content, warn-ignore unknown fields), `applyOperatorGeneralDefaults` (pure read-time overlay), `stripOperatorGeneralEchoes` (persist-time echo strip, see below), re-exported from the package index. - New `server/src/services/setting-defaults.ts`: parse-once accessor mirroring `settings-visibility.ts`. - `server/src/services/instance-settings.ts`: `toGeneralView` applies the overlay in `get`/`getGeneral`/update responses; persisted writes never carry operator values. Because general-settings writes materialize every field, a stored schema-default value is treated as unchosen — deliberate, documented, and covered by tests. - `server/src/services/feedback.ts`: the preference-persistence branch now checks the effective (overlaid) preference, so a stray prompt answer cannot overwrite an operator default; its local normalize fallback now returns full schema defaults. - `server/src/index.ts`: boot-time fail-fast parse with a log line naming the defaulted settings, mirroring the managed-config posture. - The hidden-settings write floor (`assertNoHiddenSettingChanges`) keeps comparing against effective values, so clients echoing a full GET response keep working. To keep the overlay strictly read-time, `updateGeneral` strips such echoes at persist time: a write of the operator value over a field whose stored value is still the schema default (unchosen) maps back to the schema default, so an echo cannot promote the operator value into an explicit stored choice and later changes to (or removal of) `PAPERCLIP_SETTING_DEFAULTS` still take effect. A write of any other value, or over an explicit stored choice, persists as given. - Docs: `PAPERCLIP_SETTING_DEFAULTS` row + "Operator setting defaults" section in `docs/deploy/environment-variables.md`. - Tests: `packages/shared/src/setting-defaults.test.ts` (parse matrix, overlay precedence, echo-strip matrix, immutability) and `server/src/__tests__/instance-settings-operator-defaults.test.ts` (accessor, substitution, explicit-choice wins, unset identity, never-persisted, full-GET echo stays unchosen, explicit non-default write persists). ## Verification - `npx vitest run packages/shared/src/setting-defaults.test.ts server/src/__tests__/instance-settings-operator-defaults.test.ts server/src/__tests__/instance-settings-managed-overlay.test.ts` — 33 tests passing. - `npx vitest run server/src/__tests__/instance-settings-routes.test.ts server/src/__tests__/instance-settings-service.test.ts` — 57 passing; `npx vitest run server/src/__tests__/feedback-service.test.ts server/src/__tests__/issue-feedback-routes.test.ts` — 18 passing. - `pnpm --filter @paperclipai/shared typecheck` and `pnpm --filter @paperclipai/server typecheck` — clean. ## Risks - Low. With the variable unset every read path is byte-identical to before (identity overlay, covered by tests). The overlay is read-time only and never persisted, so no migration and no data risk. Fail-closed parsing means a bad policy value is a loud boot failure rather than silent drift — consistent with the existing managed-config contract. ## Model Used Claude (Anthropic), model id `claude-fable-5`, extended thinking, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-27 11:29:05 -07:00
Devin Foley	e34ed9801b	Let operators hide the Provider vaults and Proposals tabs (#12284) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Hosting operators (a managed cloud, an internal shared server) tune the settings surface with `PAPERCLIP_HIDDEN_SETTINGS`, which today hides whole pages > - The Secrets page bundles four tabs, and two of them — Provider vaults and Proposals — do not apply to deployments where the operator provisions provider credentials itself > - Hiding the whole Secrets page is too coarse: the Secrets and My secrets tabs stay essential everywhere > - This pull request adds per-tab visibility keys (`company.secrets.vaults`, `company.secrets.proposals`) as a new company-section registry group > - The benefit is that any hosting operator can trim the Secrets page to what fits their deployment, with self-hosted behavior unchanged by default ## Linked Issues or Issue Description No public issue exists; following the enhancement template: **What existing behavior does this improve?** `PAPERCLIP_HIDDEN_SETTINGS` can hide the whole Secrets page (`company.secrets`) but not individual tabs. Operators of managed deployments need to hide the Provider vaults and Proposals tabs while keeping the rest of the page. **Subsystem affected** Settings visibility (`packages/shared/src/settings-visibility.ts`) and the Secrets page UI (`ui/src/pages/Secrets.tsx`). **Current behavior** The Secrets page always renders all four tabs (Secrets, My secrets, Provider vaults, Proposals), polls pending proposals for the badge, and offers "manage vaults" affordances that jump to the vaults tab. **Proposed behavior** Two new registry keys, `company.secrets.vaults` and `company.secrets.proposals`, hide the corresponding tab: the tab-bar entry disappears, an active hidden tab snaps back to Secrets, the manage-vaults affordances are suppressed, and the pending-proposals poll stops. UI visibility only — the provider-config and proposal APIs stay live for agents and integrations, matching the existing `company.*` precedent. Nothing changes when the variable is unset. **Reason and benefit** Any hosting operator (a managed cloud, an internal shared server) can trim the Secrets page to what fits their deployment — for example when the operator provisions provider credentials itself, so the vault and proposal flows do not apply — without losing the Secrets and My secrets tabs, which stay essential everywhere. **Breaking changes** None. With `PAPERCLIP_HIDDEN_SETTINGS` unset (or set to existing keys only) nothing changes; older app versions receiving the new keys ignore them with a warning by design. ## What Changed - `packages/shared/src/settings-visibility.ts`: new `HIDEABLE_COMPANY_SECTIONS` group (`company.secrets.vaults`, `company.secrets.proposals`), `HideableCompanySection` type, `hidesCompanySection()` helper, wired into `HideableSettingKey` / `HIDEABLE_SETTING_KEYS`, re-exported from the package index. - `ui/src/pages/Secrets.tsx`: tab-bar filtering, hidden-tab snap-back effect, gated pending-proposals query, conditional `onManageVaults` on both the import button and dialog (the button's "AWS vault disabled — manage" affordance renders nothing when vaults are hidden), hidden `TabsContent` blocks. - Docs: new bullet in `docs/deploy/environment-variables.md` under "Hiding settings surfaces". - Tests: registry membership/parse cases in `settings-visibility.test.ts`; new render cases in `Secrets.render.test.tsx` (hidden tabs absent + proposals poll skipped; default render keeps both tabs and the poll). ## Verification - `npx vitest run packages/shared/src/settings-visibility.test.ts ui/src/pages/Secrets.render.test.tsx` — 43 tests passing. - `pnpm --filter @paperclipai/shared typecheck` and `pnpm --filter @paperclipai/ui typecheck` — clean. ## Risks - Low. Nothing changes with `PAPERCLIP_HIDDEN_SETTINGS` unset (covered by the default-render test). The keys are UI-visibility only, so agent/integration API access is unaffected. Older app versions receiving the new keys ignore them with a warning by design. ## Model Used Claude (Anthropic), model id `claude-fable-5`, extended thinking, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-27 11:28:15 -07:00
Devin Foley	325041cb00	fix(assets): accept identity-provider characters in image upload namespaces (#12288) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Humans oversee those agents in teams, so each person has a login and a profile with an avatar > - Avatars, logos and pasted images all go to one asset upload API, which files each object under a namespace > - The avatar namespace embeds the user id, and a deployment can take user ids from an external identity layer, where a subject often holds ":", "|", "." or "@" > - But the namespace validator accepted only letters, numbers, "/", "_" and "-", so those users got a 400 "Invalid image metadata" error and could not set a profile photo > - This pull request widens the accepted characters, rejects "." and ".." path segments with a clear message, and cleans the namespace in the upload client > - The benefit is that profile photo upload works for every user, and a namespace the API refuses now returns a message that says what is wrong ## Linked Issues or Issue Description No existing issue or open pull request covers this. I searched the issue and pull request lists for "avatar upload", "profile photo", "Invalid image metadata" and "asset namespace" and found no duplicate. The bug report follows. **What happened?** Profile photo upload fails. `ui/src/pages/ProfileSettings.tsx` sends the namespace `profiles/${user.id}` to `POST /api/companies/:companyId/assets/images`. When the user id comes from an external identity layer it can contain ":", "|", "." or "@" — for example `oidc:example|jane.example@example.com`. `createAssetImageMetadataSchema` in `packages/shared/src/validators/asset.ts` accepted only `/^[a-zA-Z0-9\/_-]+$/`, so the route returned 400 "Invalid image metadata" (`server/src/routes/assets.ts`). The image bytes were never the problem, but the message pointed at the image, so the toast gave the user nothing to act on. A second case has the same cause. The agent instructions editor in `ui/src/pages/AgentDetail.tsx` builds a namespace that ends with a filename, such as `agents/<id>/instructions/SKILL.md`. The "." in the filename also failed the check. **Expected behavior** A profile photo uploads for any user id the app itself issues, and an image pasted into the agent instructions editor uploads for any instruction filename. A namespace the API does refuse returns a message that names the field and states the rule. **Steps to reproduce** 1. Run Paperclip with an external identity provider, so `user.id` holds an OIDC subject such as `oidc:example|jane.example@example.com`. 2. Open Settings, then Profile. 3. Choose an avatar image. 4. The upload fails and the page shows "Invalid image metadata". Or, with no identity provider: 1. Open an agent, then the instructions editor, and select a file whose name contains a "." such as `SKILL.md`. 2. Paste an image into the editor. 3. The upload fails with the same error. **Paperclip version or commit** `master` at eb86fcd49. **Deployment mode** Any deployment whose user ids come from an external identity layer. The instructions-editor case reproduces on a plain self-hosted install too. **Agent adapter(s) involved** Not adapter-specific (core bug). ## What Changed - `packages/shared/src/validators/asset.ts`: widen the namespace pattern to `/^[a-zA-Z0-9\/_.:@|-]+$/`, and reject any "/"-separated segment equal to "." or "..". A traversal attempt now gets a clean 400 from the validator instead of an error from the storage provider. - `packages/shared/src/validators/asset.ts`: add `sanitizeAssetNamespace()`, which maps any string to a namespace the schema accepts. It works per segment: it keeps the accepted characters, turns the others into "-", collapses repeated dashes, drops empty and dot-only segments, and caps the result at 120 characters. It returns `undefined` when no segment survives, and the caller then sends no namespace. - `packages/shared/src/validators/asset.ts`: export `ASSET_NAMESPACE_MAX_LENGTH` and `ASSET_NAMESPACE_RULE`, so the rule text and the API error cannot drift apart. - `ui/src/api/assets.ts`: run the namespace through `sanitizeAssetNamespace()` in `uploadImage`. This is one choke point for all callers, so no caller has to know the rule. - `server/src/routes/assets.ts`: name the field in the 400 message — `Invalid image metadata: "namespace" must be 1-120 characters of letters, numbers, or / _ - . : @ |, and cannot contain "." or ".." path segments`. The zod issue details stay in the response. The UI shows `body.error`, so the toast is now actionable. - Tests: a new `packages/shared/src/validators/asset.test.ts` accept/reject matrix for the schema and the sanitizer; three cases in `server/src/__tests__/assets.test.ts`; one case in `ui/src/pages/ProfileSettings.test.tsx`. ## Verification Targeted runs: ``` npx vitest run packages/shared/src/validators/asset.test.ts # 22 passed npx vitest run server/src/__tests__/assets.test.ts # 11 passed npx vitest run ui/src/pages/ProfileSettings.test.tsx # 2 passed ``` New cases: - Schema: accepts identity-provider ids that hold ":", "|", "." and "@"; accepts `agents/<id>/instructions/SKILL.md`; rejects `profiles/bad name!`, over-length input, and `.` or `..` segments. - Sanitizer: passes identity-provider ids through unchanged, replaces and collapses the other characters, drops the `.` and `..` segments while keeping a segment of three or more dots, caps at 120 characters without leaving a dot segment behind at the cut, and returns `undefined` when nothing survives. One case asserts the sanitizer output always parses. - Route: 201 for `profiles/oidc:example|jane.example@example.com`, and the storage service receives that namespace; 400 naming `namespace` for `profiles/bad name!`; 400 for `profiles/../secrets`. - UI: a session user id holding ":" and "|" uploads, and the namespace reaches the API unchanged. Typecheck: ``` pnpm --filter @paperclipai/shared typecheck # clean pnpm --filter @paperclipai/ui typecheck # clean cd server && npx tsc --noEmit -p tsconfig.json # clean ``` Package suites: ``` npx vitest run --project @paperclipai/shared --exclude "**/dist/**" # 586 passed, 8 pre-existing failures in src/worktree-seed-source.test.ts npx vitest run --project @paperclipai/ui --exclude "**/dist/**" # 4402 passed ``` CI runs the server suite as ten shards (five general, five serialized), which is the authoritative full run for this package. All shards pass on this branch. The `worktree-seed-source` failures reproduce on an unmodified checkout of the same base commit and are unrelated to this change. The UI failures seen in that run were 5-second test timeouts caused by running two suites at once on one machine; each file passes when it runs alone. No document states the namespace character rule — I checked `docs/` and `doc/`, where the asset upload endpoint appears only in an OpenAPI registry entry and a smoke-lab note, neither of which describes the metadata fields. The rule now lives in one exported constant that the API error reuses. ## Risks Low risk. - The wider character set does not widen what a caller can write to disk. `server/src/storage/service.ts` already replaces every character outside `[a-zA-Z0-9._-]` in each path segment, and `server/src/storage/local-disk-provider.ts` already rejects "." and ".." segments and any key that resolves outside the base directory. This change moves the "." and ".." refusal earlier, to the validator, so the caller gets a clear 400. - The API is more permissive than before, so no request that used to succeed can start failing. - Namespaces stored before this change keep working. The namespace is not a key that is looked up; it is a prefix under which new objects are filed. - One behavior change worth noting: the UI now cleans a namespace instead of sending it as typed, so a caller that passes an unusable namespace gets a cleaned prefix rather than a failed upload. ## Model Used - Claude (Anthropic), Claude Opus, 1M context window, extended thinking, agentic tool use through Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-27 11:27:31 -07:00
Devin Foley	d27998a230	Check the declared Lexical range with semver rules (#12319) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - People write almost every issue, goal, document, and chat message through the rich markdown editor, which wraps `@mdxeditor/editor` on top of Lexical > - #12317 fixed a dependency split that broke that editor everywhere, and it added `ui/src/lib/lexical-single-copy.test.ts` to keep the Lexical graph honest > - Greptile raised a P2 on the last assertion in that test. It compared the range `@mdxeditor/editor` declares to a literal string, so it rejected equivalent spellings such as `>=0.48.0 <0.49.0` even when the resolved version satisfies them > - A guard that fails on a healthy tree teaches people to delete it, which would give back the protection #12317 just added > - #12317 merged before the fix landed, so this pull request carries it > - This pull request stops the test from reading semver ranges at all, and asserts the mechanism that can actually break the graph > - The benefit is a guard that fails only on a real problem, and a smaller test file than before ## Linked Issues or Issue Description Refs #12317 — this addresses the Greptile P2 left on that pull request. No public issue exists, so the problem is described below with the bug report template. **What happened?** `ui/src/lib/lexical-single-copy.test.ts` asserted the declared range with an exact string comparison: ```ts const [major, minor] = versionOf("lexical", requireFromUi).split("."); expect(declared).toBe(`^${major}.${minor}.0`); ``` That accepts one spelling only. If `@mdxeditor/editor` published `>=0.48.0 <0.49.0`, or `^0.48.2`, or `^0.47.0 || ^0.48.0`, the test would fail even though the resolved Lexical version satisfies the declared range. The test would report a dependency split that does not exist. **Expected behavior** The test fails when the Lexical graph is actually split or forced. It passes on any healthy tree, whatever range syntax the editor happens to publish. **Steps to reproduce** 1. Check out `master` at c8a136fb0. 2. Edit `ui/node_modules/@mdxeditor/editor/package.json` and change `"lexical": "^0.48.0"` to the equivalent `"lexical": ">=0.48.0 <0.49.0"`. 3. Run `npx vitest run ui/src/lib/lexical-single-copy.test.ts`. 4. The range case fails, although 0.48.0 satisfies the range. **Paperclip version or commit** `master` at c8a136fb0. The assertion arrived with #12317. **Relevant logs or output** ``` AssertionError: expected '>=0.48.0 <0.49.0' to be '^0.48.0' // Object.is equality ``` ## What Changed The test no longer reads semver ranges. It asserts the mechanism instead. - Replaced the range assertion with a check that no `lexical` or `@lexical/*` key appears in the root `pnpm.overrides`. The failure message names the fix. - Removed the range assertion and the version-line comparison that stood in for it. Both needed range syntax to mean something specific. - Documented on the copy check why it now carries the whole guarantee. Why this is sufficient, and stronger: - An override is the only thing that can push a resolved version outside the range a package declares. Remove the override and pnpm honours every declared range by construction, so `@mdxeditor/editor` gets a Lexical it supports. No parser needed. - `@mdxeditor/editor` resolved its own Lexical from its own declared range. The copy check asserts the app resolved the same version. So an equal version proves the app sits on a line the editor supports, transitively. - It also closes the second half of the original bug. The old override list could only pin the packages it named, and `@lexical/extension` was reached transitively and never listed. A guard on "no Lexical override at all" has no such blind spot, while a guard on "the override pins the right version" would have. The file is 65 lines shorter than the first attempt and no longer carries a hand-rolled semver evaluator. I considered two alternatives and rejected both. A `semver` dependency in `ui` would work, but `ui` cannot resolve `semver` today and a new direct dependency is a heavy way to buy one assertion. A larger hand-rolled evaluator would have to cover partial versions, wildcards, hyphen ranges, and spaced comparators before it stopped producing false failures, which is a semver library with fewer tests. Nothing outside this test file changes. The Lexical pins from #12317 stay as they are, and `pnpm-lock.yaml` is untouched because no manifest changes. ## Verification - `npx vitest run ui/src/lib/lexical-single-copy.test.ts` — 3 passed. - `pnpm --filter @paperclipai/ui typecheck` — clean. - Regression still caught. I restored the pre-#12317 pins, which are the 0.49.0 `pnpm.overrides` block and the 0.49.0 pins in `ui/package.json`, ran `pnpm install`, and re-ran the guard. Two of the three cases failed, and the new one reports the cause and the fix together: ``` AssertionError: Pin Lexical through ui/package.json instead. An override cannot cover the packages it does not name, and it hides the range @mdxeditor/editor declares.: expected [ 'lexical', …(9) ] to deeply equal [] AssertionError: expected '0.48.0' to be '0.49.0' ``` I then restored the current pins and re-ran the guard, which passed 3 of 3. - `npx vitest run ui/src/lib/mention-deletion.test.ts ui/src/lib/mention-aware-link-node.test.ts ui/src/components/MarkdownEditor.test.tsx` — 42 passed, unchanged. ## Risks - Low risk. The change touches one test file and no application code. - The guard now forbids a legitimate tool. If someone later has a real need for a Lexical `pnpm.overrides` entry, this test blocks it. That is deliberate: an override is what broke the editor, and the block is one line to remove with a reviewer looking at it. The failure message states the supported alternative, which is pinning in `ui/package.json`. - The guard no longer checks the declared range directly. It relies on pnpm honouring declared ranges when no override is present, which is the package manager's contract and the same property `pnpm install --frozen-lockfile` depends on in CI. - The ordering #12317 set out still holds: a Lexical upgrade must wait for an `@mdxeditor/editor` release that supports it. Bumping `ui` past the editor's range now produces two copies, which the copy checks fail on. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used Claude (Anthropic), Claude Opus, agentic tool use via Claude Code. - Provider and model: Claude (Anthropic), Claude Opus - Capability: agentic tool use through Claude Code, with repository search, file edits, dependency installation, test and build runs ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes (the reasoning lives in comments in the test file; no document states a Lexical version or pinning policy) - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-27 11:26:06 -07:00
Devin FoleyandPaperclip	2a3c86f91d	fix(ui): keep the rich editor available for angle-bracket prose (#12290) ... ## Thinking Path > - Paperclip helps people manage AI agents and their work > - People use the rich markdown editor to write task descriptions, comments, and agent instructions > - The editor disables HTML processing, but the markdown parser still treats some angle-bracket text as HTML > - A value such as `<name>` could therefore stop the rich editor and show the raw-source fallback > - The retry action used the same input, so it could not recover > - This pull request escapes unsupported angle brackets only while the editor processes the value > - The benefit is that the rich editor works and stored markdown stays unchanged ## Linked Issues or Issue Description Fixes: #12197 Related prior attempt: #2696 **What happened?** The rich markdown editor did not start when prose contained a bare angle bracket, such as `<name>`. It showed the raw-source fallback. The retry action repeated the same failure. **Expected behavior** The rich editor starts for normal prose. It stores the text in its clean form because agent prompts can use this text. **Steps to reproduce** 1. Open a task description, comment, or other field that uses the rich markdown editor. 2. Enter `Rename <name> to the real name`. 3. Reload the field. 4. Observe the raw-source fallback. **Paperclip version or commit** `master` at d785b1921. **Deployment mode** All modes. The defect is in the UI package. ## What Changed - Escape only angle brackets that the parser treats as unsupported HTML constructs. - Restore the clean markdown before the editor sends a value to its parent. - Keep code, autolinks, link destinations, and existing escapes unchanged. - Apply the same conversion to pasted and inserted markdown. - Make the empty-editor fallback wait for editor initialization and confirm the empty state. - Re-arm the initial empty-change guard when the user retries the editor. - Add `MDE-PARSE`, `MDE-RENDER`, and `MDE-EMPTY` fallback codes. - Correct the editor mock and add regression tests for parsing, round trips, paste, insert, retry, and fallback behavior. ## Verification - `npx vitest run ui/src/lib/angle-bracket-markdown.test.ts ui/src/lib/blockquote-markdown.test.ts ui/src/components/MarkdownEditor.test.tsx` — 106 tests passed. - `pnpm --filter @paperclipai/ui typecheck` — passed. - `pnpm -r typecheck` — passed. - `pnpm build` — passed. - `pnpm check:token-gates` — reports nine existing color findings in `ui/src/components/onboarding/PillGuy.tsx`. This pull request does not change that file. - `pnpm test:run` — the local run found four existing port-allocation failures in unrelated workspace-runtime tests. The focused editor tests passed. The pull request CI runs these suites on clean workers. ## Risks - Low data risk. The conversion applies only while MDXEditor processes a value. Stored markdown keeps the clean form. - The scanner skips code, autolinks, link destinations, and existing escapes to prevent content changes. - The raw-source fallback can appear about 300 ms later because it now confirms that the editor stayed empty. - There is no database or API change. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - Original implementation: Anthropic Claude Opus, 1M context, with agentic tool use in Claude Code. - PR preparation and verification: OpenAI Codex with GPT-5, reasoning, code execution, and tool use. The runtime did not expose the context-window size. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-27 09:57:13 -07:00
Devin Foley	c8a136fb02	Restore a single Lexical copy so the rich editor renders (#12317) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - People write almost every issue, goal, document, and chat message through the rich markdown editor, which wraps `@mdxeditor/editor` on top of Lexical > - On `master` that editor renders its raw-source textarea instead. It shows "Rich editor unavailable for this markdown" on every field, for all content, including empty content > - Lexical throws at render time because the project holds two copies of `LexicalBuilder`. The root `pnpm.overrides` block forced the Lexical family past the version range the editor supports, and it missed the packages that are reached transitively > - Every markdown surface in the product degrades to plain text editing, so this is a full loss of a core authoring feature and not a cosmetic problem > - This pull request removes the Lexical entries from `pnpm.overrides`, pins the app to Lexical 0.48.0, and adds a test that guards the resolution graph > - The benefit is that the rich editor renders again, and a future override or bump that splits Lexical fails in CI instead of in the browser ## Linked Issues or Issue Description No public issue exists. The problem is described below with the bug report template. **What happened?** The rich markdown editor falls back to its raw-source textarea on every markdown field. The header reads "Rich editor unavailable for this markdown. Showing raw source instead." The fallback appears for all content, including empty content. React catches an error during the first render of the editor. The cause is dependency resolution. The root `package.json` `pnpm.overrides` block pinned the Lexical family to `0.49.0`. `@mdxeditor/editor@4.2.1` declares `lexical: "^0.48.0"`. A caret range on a `0.x` version pins the minor, so `^0.48.0` means `>=0.48.0 <0.49.0`. The override therefore pushed the editor past its only supported line. Lexical 0.49.0 also carries breaking `$config()` node changes. The override list was also incomplete. `@lexical/extension`, `@lexical/history`, and `@lexical/internal` are reached transitively and were never listed. Those packages stayed on 0.48 while the listed packages moved to 0.49. The graph mixed the two lines, and the built browser bundle carried two `Symbol.for("@lexical/extension/LexicalBuilder")` registrations. Commit 04432f82c (#10728) introduced this. It was a Dependabot bump from 0.46.0 to 0.49.0. **Expected behavior** The rich editor renders a live WYSIWYG surface on every markdown field. The raw-source fallback stays reserved for real markdown parse failures. **Steps to reproduce** 1. Check out `master` and run `pnpm install`. 2. Start the app and open any issue, goal, or document. 3. Look at any markdown field, for example the issue description. 4. The field shows the fallback banner and a plain textarea. The rich toolbar is absent. You can also see the split without the browser: ``` pnpm --filter @paperclipai/ui build grep -ohE 'Symbol\.for\("@lexical/extension/LexicalBuilder"\)' ui/dist/assets/index-*.js | wc -l ``` On `master` this prints `2`. A correct graph prints `1`. **Paperclip version or commit** `master` at 1ba7b2cc7. The regression entered at 04432f82c (#10728). **Relevant logs or output** ``` LexicalBuilder.fromEditor: The given editor was created with LexicalBuilder 0.48.0+dev.esm but this version is 0.49.0+dev.esm. A project should have exactly one copy of LexicalBuilder ``` React reports the error in `<LexicalExtensionEditorComposer>`. `MarkdownEditorRichErrorBoundary` catches it and shows the raw-source fallback. ## What Changed - Removed the Lexical entries from `pnpm.overrides` in the root `package.json`. This drops `lexical`, `@lexical/clipboard`, `@lexical/link`, `@lexical/list`, `@lexical/markdown`, `@lexical/plain-text`, `@lexical/react`, `@lexical/rich-text`, `@lexical/selection`, and `@lexical/utils`. The `rollup`, `react`, and `react-dom` overrides stay as they are. - Pinned `lexical` and `@lexical/link` to `0.48.0` in `ui/package.json`. The app subclasses `LinkNode` for mention-aware links and registers it into the Lexical instance that MDXEditor owns, so node identity needs one copy. `@lexical/link@0.48.0` pins `lexical` at `0.48.0` exactly. - Left `pnpm-lock.yaml` out of this commit on purpose. The `policy` job blocks manual lockfile edits, regenerates the lockfile from the manifests, and uploads it for the downstream `pnpm install --frozen-lockfile` jobs. I did regenerate the lockfile locally to verify the result. That local lockfile touched only Lexical and MDXEditor entries and held no Lexical 0.49 reference. - Added `ui/src/lib/lexical-single-copy.test.ts`. It asserts the app and the editor resolve the same `lexical` file, that `@lexical/link` and the transitively reached `@lexical/extension` sit on that version, and that the version satisfies the range the editor declares. `ui` is the only workspace package that declares a Lexical dependency, so nothing else changes. ### Why the overrides can go #9180 added the Lexical overrides for a good reason. At that time the app used Lexical 0.46.0 and `@mdxeditor/editor` declared `lexical@^0.35.0`. The two ranges could not meet, so an override was the only way to force one copy. That condition is gone. `@mdxeditor/editor@4.2.1` now declares `lexical: "^0.48.0"`. When the app also declares `0.48.0`, pnpm resolves one copy on its own and the override has nothing left to do. The override is now a liability. It can only pin the packages it lists by name. `@lexical/extension` did not exist when the list was written, so the list never covered it, and the list silently stopped covering the whole family. Natural resolution has no such blind spot, because every Lexical package carries its own exact pin on the core. The existing `lexical` alias in `ui/vite.config.ts` and `ui/vitest.config.ts` stays. It still resolves at 0.48.0. Note that the alias covers only the `lexical` core, which is why it did not prevent this bug and why the new test reads the resolution graph with `createRequire` instead of importing Lexical. ### Related pull requests - #10728 — the Dependabot bump that introduced the regression. Superseded by this change. - #10724 — the companion core bump merged the same day. - #9180 — added the overrides block that this change removes. See the explanation above. - #9179 — an older, still-open 0.46.0 bump. It is stale and this change does not depend on it. I found no open pull request that already fixes this problem. ## Verification All commands ran from the repository root. - `npx vitest run ui/src/lib/lexical-single-copy.test.ts` — 3 passed. - Guard proven against the broken tree. I restored the pre-fix `package.json`, `ui/package.json`, and `pnpm-lock.yaml`, ran `pnpm install`, and re-ran the guard. It failed 2 of 3: `expected '0.48.0' to be '0.49.0'` for `@lexical/extension`, and `expected '^0.48.0' to be '^0.49.0'` for the declared range. I then restored the fix and `pnpm install` reproduced the committed lockfile byte for byte. - `pnpm --filter @paperclipai/ui typecheck` — clean. The Lexical API calls in the app still compile on 0.48. - `npx vitest run ui/src/lib/mention-deletion.test.ts ui/src/lib/mention-aware-link-node.test.ts ui/src/components/MarkdownEditor.test.tsx` — 42 passed. - `pnpm --filter @paperclipai/ui build`, then the `grep` above — the bundle now holds 1 `LexicalBuilder` registration. It held 2 before this change. - Full `ui` project: `npx vitest run --project '@paperclipai/ui'` — 4426 of 4431 passed. I re-ran the 5 failures in isolation. Four passed, so they were load-induced 5 second timeouts in `CompanyEnvironments.test.tsx` and `IssuesList.test.tsx`. The last one, `OnboardingWizard.test.tsx > renders instead of throwing when the browser denies storage access`, also fails on clean `master` and is unrelated to this change. - Real render probe. I wrote a throwaway test that renders `MarkdownEditor` against the real `@mdxeditor/editor` with no mock. Before this change it produced the fallback banner and the `LexicalBuilder` error. After this change the editor mounts a live `contenteditable` surface and logs no error. The probe was temporary and is not part of this diff. ## Risks - This pins the app's Lexical to the line the editor supports rather than to the newest release. A future Lexical upgrade must wait for an `@mdxeditor/editor` release that supports it. I checked published `@mdxeditor/editor` through 4.2.3 and none supports Lexical 0.49, so fixing forward is not possible today. The new test enforces that ordering, so an upgrade attempt fails in CI with a clear reason. - Dependabot will offer the Lexical 0.49 bump again. The new test will fail that pull request. That is the intended behavior. A reviewer should keep the bump closed until MDXEditor moves first. - 04432f82c was a routine version bump and not a security fix, so this change reintroduces no known advisory. - The change is limited to dependency resolution and one new test. It alters no application code. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used Claude (Anthropic), Claude Opus, agentic tool use via Claude Code. - Provider and model: Claude (Anthropic), Claude Opus - Capability: agentic tool use through Claude Code, with repository search, file edits, dependency installation, test and build runs ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes (no document in the repository states a Lexical version or pinning policy, so the reasoning is recorded in the new test's header comment) - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-27 09:26:42 -07:00
Devin Foley	8ef39febd7	refactor(db): drop the vendored postgres teardown patch (reverts #12227) (#12234) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - #12227 vendored a pnpm patch of the `postgres` driver to stop a teardown race (`nextWrite` firing after the socket is nulled) from crashing the process and failing green CI shards > - Maintainer call: carrying a vendored driver patch is not worth it for a CI flake — the patch adds a maintenance obligation on every future driver upgrade > - The race is an upstream bug in `postgres@3.4.9`; the plan is to wait for an upstream release that fixes it and bump the dependency instead > - This pull request reverts #12227 in full: the patch file, its `package.json` registration, and the regression test that exercised the patched behavior > - The benefit is an unmodified dependency graph; the known flake signature returns and is retried when it bites ## Linked Issues or Issue Description Reverts #12227. **What existing behavior does this improve?** Dependency hygiene: `postgres@3.4.9` is consumed unmodified again, with no `pnpm.patchedDependencies` entry to re-evaluate on every driver upgrade. **Current behavior** The repo carries `patches/postgres@3.4.9.patch` (null-socket guard in the driver's deferred write flush, plus an `execute()` refusal on socketless connections) and a regression test for it. **Proposed behavior** Plain upstream `postgres@3.4.9`. The teardown race stays an upstream bug: a green test shard can occasionally fail with `Vitest caught 1 unhandled error` and `TypeError: Cannot read properties of null (reading 'write')` at `Immediate.nextWrite`; the remedy is retrying the shard until an upstream driver release fixes the race and we bump. **Reason and benefit** A vendored driver patch is a standing maintenance cost that outweighs the flake it suppressed. ## What Changed - Reverts #12227 (`6c7c0fd1f`) in full: removes `patches/postgres@3.4.9.patch`, its `pnpm.patchedDependencies` registration in root `package.json`, and `packages/db/src/postgres-driver-teardown.test.ts`. No lockfile involvement — the merged commit never touched `pnpm-lock.yaml` and the refresh bot had not yet recorded the patch. ## Verification - `pnpm install` on the reverted tree is coherent; the full `packages/db` suite passes (26 files / 100 tests). - `git revert` applied cleanly with no conflicts. ## Risks - Low. This restores the exact pre-#12227 state. The known flake signature returns; it fails jobs whose tests all passed and is cleared by retrying the shard. ## Model Used Claude Fable 5 (`claude-fable-5`, Anthropic) via Claude Code — agentic coding session with tool use. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-26 11:10:44 -07:00
Devin Foley	6c7c0fd1f2	fix(db): stop the postgres driver from crashing the process on a write/close race (#12227) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The server and its test suites talk to PostgreSQL through the `postgres` (postgres.js) driver, and tests routinely tear their databases down while connections still carry traffic > - The driver flushes small buffered frames from a `setImmediate`, and that deferred flush calls `socket.write()` without checking that the socket still exists; a reserved connection whose backend died keeps accepting queries, so the flush can fire with a null socket > - The resulting `TypeError` escapes from a timer callback with no try/catch above it, crashing the process — in CI this fails suites whose tests all passed ("Vitest caught 1 unhandled error"), and the same crash is reported against the driver in the wild after ECONNRESET > - The latest driver release (3.4.9) still has the bug, so this pull request adds a pnpm patch guarding the flush and normalizing timer state on close, plus a deterministic regression test > - The benefit is CI that no longer fails randomly on a teardown race, and production processes that survive a database connection dying at the wrong moment ## Linked Issues or Issue Description No public issue exists; the underlying problem follows the bug-report template. **What happened?** CI jobs fail with all tests passing: vitest reports `Vitest caught 1 unhandled error during the test run` with `TypeError: Cannot read properties of null (reading 'write')` at `postgres/src/connection.js` `Immediate.nextWrite`. The attribution points at whichever test file happened to be running (e.g. `native-codex-runner.integration.test.ts`), because the throw comes from a process-level timer callback, not from a test. The identical crash is reported against the upstream driver by other projects after `ECONNRESET` (e.g. immich-app/immich#25098). **Expected behavior** A connection dying between a write being scheduled and its deferred flush must settle the affected queries through the driver's normal connection-error path, never throw from a bare timer callback. **Steps to reproduce** Run the new `packages/db/src/postgres-driver-teardown.test.ts` with the patch removed: reserve a connection (`sql.reserve()` — the same surface `sql.begin()` uses), destroy the backend socket, wait for the client to process the close, then issue one query on the reserved connection. The deferred flush fires one tick later with `socket === null` and crashes the process with exactly the CI signature. **Paperclip version or commit** master `198fc8b28`, `postgres@3.4.9` (latest release; bug still present on the driver's master branch). ## What Changed - `patches/postgres@3.4.9.patch` (new, wired via `pnpm.patchedDependencies`): `nextWrite` returns without writing when `socket === null`, dropping the buffered bytes — the close path has already settled every in-flight query, so those bytes have nowhere to go. The `closed()` and `terminate()` handlers additionally reset `nextWriteTimer`/`chunk` after `clearImmediate`, so a stale cleared handle cannot silently block a future reconnect's first flush. All three shipped builds (`src`, `cjs`, `cf`) get the identical change. - `packages/db/src/postgres-driver-teardown.test.ts` (new): deterministic reproduction against a minimal in-process fake wire server (startup auth + an empty result for the `fetch_types` bootstrap). Asserts the late query settles with `CONNECTION_DESTROYED` through `sql.end()` instead of crashing the process. ## Verification - The regression test fails against unpatched `postgres@3.4.9` with the exact CI signature (verified by running the same scenario against an unpatched checkout) and passes with the patch. - Full `packages/db` suite: 27 files / 101 tests pass. - Spot-checked server suites that exercise the database through the patched driver. ## Risks - Low. The behavioral change activates only in a state that previously crashed the process (write flush with no socket). Dropping the buffered bytes matches what the connection's close path already promised callers: every in-flight query has been settled with a connection error. - The timer/chunk reset in `closed()`/`terminate()` prevents a theoretical stale-handle hang after reconnect; on the normal path both were already reset by `nextWrite`. - The patch pins to `postgres@3.4.9`; a future driver upgrade will surface the patch for re-evaluation (pnpm fails loudly on version mismatch), and the guard can be dropped if the fix lands upstream. ## Model Used Claude Fable 5 (`claude-fable-5`, Anthropic) via Claude Code — agentic coding session with tool use (driver source analysis, wire-protocol fake server, local test execution). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-26 10:19:19 -07:00
Devin Foley	ca02d2463a	fix(ui): keep the installed service worker fresh on parked tabs (#12198) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The web UI registers a service worker (`/sw.js`) that caches the app shell for an offline fallback. > - Browsers only re-fetch a worker script on navigation or a ~24h timer, and Paperclip is a parked-tab SPA: a tab can sit open for weeks without one navigation. > - An installed worker — and the shell it cached — can therefore keep serving an old bundle long after a deploy, and the server let `sw.js` inherit the generic 1h static TTL on top of that. > - This pull request adds explicit update checks (tab-visible + hourly), applies a discovered update with one reload while the tab is hidden, and serves `sw.js` with `Cache-Control: no-cache`. > - The benefit is that a deploy reaches every open tab within about an hour, instead of some tabs silently running stale UI indefinitely. ## Linked Issues or Issue Description Refs #11292 (the network-first `sw.js` fallback fix; this PR closes the delivery gap that can keep clients pinned on a pre-#11292 worker). **What happened?** A browser that had an older cache-first worker installed kept rendering a stale app shell — old feature set, old naming — while the server was verified to be running the current release. Nothing on the client checks for a new worker outside navigations, so a parked tab never picked up the fixed worker, and `sw.js` was served with a 1h cache TTL that further delayed update checks. **Expected behavior** Every open tab converges to the deployed bundle shortly after a release, without users unregistering workers in DevTools or hard-reloading. **Steps to reproduce** Install a build's service worker, deploy a newer build, and leave the tab parked (no navigation): the tab keeps running the old bundle indefinitely; the worker update check only happens if the user navigates, and even then a cached `sw.js` can answer it. ## What Changed - New `ui/src/lib/service-worker-updates.ts`: registers `/sw.js`, runs `registration.update()` when the tab becomes visible and on an hourly timer, and on `controllerchange` of a previously-controlled page applies the update with a single reload — only while the tab is hidden, so an update never yanks the page mid-session; a takeover while visible defers the reload to the next hidden transition. First-ever installs never reload. - `ui/src/main.tsx`: replaces the fire-and-forget `register()` with the new module. - New `server/src/static-ui-cache.ts` (`staticUiCacheControl`): `index.html` and `sw.js` are served `Cache-Control: no-cache`; other non-hashed statics keep the 1h default. `server/src/app.ts` uses it in the static middleware. ## Verification - `npx vitest run ui/src/lib/service-worker-updates.test.ts` — 8 tests: registration, hidden-takeover reload (once), deferred reload on visible takeover, no reload on first install, visibility-triggered and timer-triggered update checks, cleanup, no-container no-op. - `npx vitest run server/src/__tests__/static-ui-cache.test.ts` — 3 tests incl. the `sw.js.map` lookalike keeping the default TTL. - `tsc -b` (ui) and `tsc --noEmit` (server) clean; `pnpm check:tokens` clean. ## Risks - Behavioral shift: tabs now reload once, while hidden, after a deploy lands. Unsaved in-page state in a hidden tab is lost at that moment — the same exposure as a browser discarding a background tab, which SPAs must already tolerate. - Self-hosted behavior is otherwise unchanged: same worker script, same registration URL, one added conditional header. - Low risk on the server side: the header change only widens revalidation. ## Model Used Claude Fable 5 (`claude-fable-5`, Anthropic) via Claude Code — agentic coding session with tool use and extended thinking. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 16:12:02 -07:00
Devin Foley	9c03443c48	feat: hideable company settings pages, with import floored on cloud-managed instances (#12199) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The app can run self-hosted or as a cloud-managed instance, where a hosting platform provisions the instance with its company already materialized (the existing `isCloudManagedInstance()` predicate and `cloud_managed` floors) > - The company Import/Export surface lets an operator materialize whole companies from an export bundle; on a cloud-managed instance this bypasses the existing `cloud_managed` company-creation floor and conflicts with platform-owned provisioning > - Importing should be disabled on cloud-managed instances, while export stays open as the data-portability escape hatch > - This pull request floors every import route with 403 `code=cloud_managed` on cloud-managed instances and hides the Import UI there, using the existing predicate and the established floor pattern > - It also extends the operator-hidden settings registry with keys for every top-level company settings page, so a hosting operator can hide any of them with `PAPERCLIP_HIDDEN_SETTINGS` alone next time > - The benefit is one consistent managed-instance policy: cloud-managed instances cannot import companies, self-hosted installs keep the full import surface unchanged ## Linked Issues or Issue Description No public issue exists; the underlying problem follows the enhancement template. **What existing behavior does this improve?** The company import surface (`/api/companies/import*`, `/api/companies/:companyId/imports/*`) and its UI entry points on cloud-managed instances. **Subsystem affected** Server routes (`server/src/routes/companies.ts`) and UI navigation/pages (settings sidebar, settings tabs, org chart, `/company/import` route). **Current behavior** A cloud-managed instance floors direct company creation (`POST /api/companies` answers 403 `cloud_managed`), but the import routes still accept company bundles, so an import can materialize companies the hosting platform did not provision. The UI offers Import entry points that lead to a surface that is not available on cloud-managed instances. **Proposed behavior** On instances where `isCloudManagedInstance()` is true, every import route answers 403 `code=cloud_managed` before auth and body work, and the Import UI (sidebar entry, settings tab, org-chart button, `/company/import` route) is hidden or redirected. Export remains fully available. Self-hosted instances are unchanged. **Reason and benefit** Cloud-managed instances keep one consistent provisioning authority, and users do not see an Import surface that dead-ends in a 403. ## What Changed - `server/src/routes/companies.ts`: a router-level floor mounted at the `/import` and `/:companyId/imports` prefixes. It covers the single-shot upload, preview, job polling, chunked transfer declare/part-upload/status/preview/apply, and the agent-safe per-company import routes. It throws `forbidden(..., { code: "cloud_managed" })` on cloud-managed instances, or `403 settings_operator_managed` when the operator hides `company.import` — both before auth and body validation, mirroring the company-creation floor. - `packages/shared/src/settings-visibility.ts`: new `HIDEABLE_COMPANY_PAGES` registry group — `company.members`, `company.invites`, `company.secrets`, `company.export`, `company.import` — with a `hidesCompanyPage` helper. The company General page stays non-hideable (settings root). `company.import` floors its API; the other keys are UI-visibility only, as documented in the registry, so membership/invite/secret/export APIs stay live for agents. - `ui/src/components/CloudManagedPageGate.tsx` (new): route gate that redirects cloud-managed instances to `/company/settings`, modeled on `HiddenSettingsPageGate`. - `ui/src/App.tsx`: wraps the `company/import` route in `CloudManagedPageGate`. - `ui/src/components/CompanySettingsSidebar.tsx`, `ui/src/components/access/CompanySettingsNav.tsx`, `ui/src/pages/OrgChart.tsx`: hide the Import entry points when `useCloudInstance()` reports a managed instance, and honor the new `company.*` hidden-settings keys for every company page entry (sidebar item, tab, org-chart buttons). - `ui/src/App.tsx`: `HiddenSettingsPageGate` route gates for the members (incl. the legacy access route), invites, secrets, export, and import pages under their `company.*` keys. - `docs/deploy/environment-variables.md`: documents the new keys and their semantics; the CLI and board-operator guides note that import is unavailable on cloud-managed instances. - Tests: new `server/src/__tests__/company-import-cloud-floor.test.ts` and `ui/src/components/CloudManagedPageGate.test.tsx`, registry cases in `packages/shared/src/settings-visibility.test.ts`, plus cloud and hidden-key cases in the sidebar, settings-nav, and org-chart suites. ## Verification - TypeScript typechecks pass for every workspace package (`tsc` in shared, server, ui; the runner's Rust leg needs a local cargo toolchain and is covered by CI). - `pnpm test` on this branch fails only in 9 files that also fail on a clean `origin/master` checkout on the same machine (environment-dependent suites: live-listener probes, workspace/native-runtime spawns, skill materialization). Zero branch-only failures against that baseline; every suite touched by this change passes. - `server/src/__tests__/company-import-cloud-floor.test.ts` asserts: every import route answers 403 `cloud_managed` under the server-token signal; the managed-config signal alone also floors; every import route answers 403 `settings_operator_managed` when `company.import` is hidden; hiding other company pages leaves import open; the floor applies before auth and body validation; export stays open on cloud-managed instances; self-hosted import preview and job polling still work. - `packages/shared/src/settings-visibility.test.ts` covers the new `company.*` keys and `hidesCompanyPage`. - UI suites assert the Import tab, sidebar entry, and org-chart button disappear on a cloud-managed instance while Export stays, that `/company/import` redirects through the gate, and that the `company.*` keys hide their sidebar entries and tabs. ## Risks - Low risk for self-hosted installs: the floor is inert unless a cloud signal (`PAPERCLIP_CLOUD_TENANT_SERVER_TOKEN` or `PAPERCLIP_MANAGED_CONFIG`) is present, and the self-hosted paths are regression-tested. - On cloud-managed instances this is a deliberate behavioral removal: import (including agent-driven safe imports and resumable transfers) stops working the moment an instance runs this build. In-flight chunked transfers on such instances cannot be applied afterward; they answer 403. - CLI import commands against a cloud-managed instance now fail with the `cloud_managed` error; the message names the reason. - The new `company.*` keys change nothing unless an operator sets them: `PAPERCLIP_HIDDEN_SETTINGS` unset keeps behavior identical, and older images ignore unknown keys by design. The four non-import company keys hide UI only; their APIs stay live, which the registry documents explicitly. ## Model Used Claude Fable 5 (`claude-fable-5`, Anthropic) via Claude Code — agentic coding session with tool use (code search, editing, local test execution). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 16:06:35 -07:00
Devin Foley	a5c2add7be	fix(adapter-utils): repair referenced-source ignore resolution type break and symlink descendant check (#12201) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Referenced projects are staged into run sandboxes, and a recent change made each staging site resolve the project's Git-ignored paths explicitly (`ignoreResolution` on `SandboxAdditionalSource`) > - One test call site was left without the now-required property, so `tsc` fails in adapter-utils and every Build/Typecheck CI job on master is red (surfaced when the TypeScript 7 bump landed in the same window) > - Separately, the new descendant check compares a logical caller path against the physical toplevel git prints, so any symlinked path fails ignore resolution spuriously — three of the suite's own tests fail on macOS because temp dirs live under the `/var` → `/private/var` symlink > - This pull request supplies the missing property at the test call site and makes the descendant comparison symlink-safe via realpath on both sides > - The benefit is a green master again, plus referenced-project staging that works from symlinked checkouts and temp directories ## Linked Issues or Issue Description No public issue exists; the underlying problem follows the bug-report template. **What happened?** `packages/adapter-utils` fails `tsc` on master: `src/sandbox-managed-runtime.test.ts(2284,29): error TS2741: Property 'ignoreResolution' is missing in type '{ localPath: string; projectId: string; }' but required in type 'SandboxAdditionalSource'.` Every Build/Typecheck CI job is red. Independently, `resolveReferencedSourceIgnore` returns `{ kind: "failed", reason: "referenced project path is not a descendant of its own Git top level: /var/... under /private/var/..." }` for any symlinked project path, and three tests in the suite fail on macOS. **Expected behavior** Master typechecks. A referenced project whose path reaches git through a symlink (macOS temp dirs, symlinked checkouts) resolves its ignore set normally, and the descendant check still fails closed for genuinely foreign paths. **Steps to reproduce** 1. `pnpm --filter @paperclipai/adapter-utils exec tsc --noEmit` on master — TS2741 at `sandbox-managed-runtime.test.ts:2284`. 2. On macOS: `pnpm vitest run packages/adapter-utils/src/sandbox-managed-runtime.test.ts` — three `resolveReferencedSourceIgnore` tests fail with the "not a descendant" reason above. **Paperclip version or commit** master `29d12045f`. ## What Changed - `sandbox-managed-runtime.test.ts:2284`: the one call site missing `ignoreResolution` now passes `{ kind: "other" }`, matching every sibling call site from the same change. - `sandbox-managed-runtime.ts`: `resolveReferencedSourceIgnore` resolves both the git toplevel and the caller's `localPath` through a new `physicalPath` helper (realpath with a resolve fallback) before the descendant comparison. Git prints physical toplevels, so both sides must be physical; the fallback keeps the check failing closed when a path vanishes mid-run. ## Verification - `pnpm vitest run packages/adapter-utils/src/sandbox-managed-runtime.test.ts` — 61/61 pass on macOS (previously 58 passing, 3 failing, plus the typecheck break). - `tsc --noEmit` in `packages/adapter-utils` is clean. ## Risks - Low. The behavioral change is confined to path normalization before an existing comparison; a realpath failure falls back to the prior string comparison, so the fail-closed property is preserved. ## Model Used Claude Fable 5 (`claude-fable-5`, Anthropic) via Claude Code — agentic coding session with tool use (code search, editing, local test execution). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 15:48:24 -07:00
Devin Foley	9fc2f594ae	feat(ui): dashboard banner for paused imported agents with Resume all (#12142) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Company import parks every imported agent as a safety default > - The only surface that offered to activate them was the post-import checklist, which is UI-only and gone after a reload or an expired import job > - A company whose agents are all paused looks broken: tasks sit still and the dashboard gives no explanation or fix > - This pull request adds a dashboard banner for import-paused agents with a one-click Resume all, and a generic banner when every agent is paused > - The benefit is a durable, reload-proof place to understand and fix the parked state ## Linked Issues or Issue Description **What existing behavior does this improve?** The company dashboard for a company whose agents are paused, in particular after a company import. **Subsystem affected** Web UI — dashboard (`ui/src/pages/Dashboard.tsx`). **Current behavior** Imported agents arrive paused. The activation checklist on the import page is the only activation surface and is lost on reload. The dashboard shows paused counts in a metric card but no explanation and no action. Tasks assigned to the paused agents never start. **Proposed behavior** When any agent carries the `import` pause reason, the dashboard shows a warning banner ("N imported agents are paused and will not run") with a **Resume all** action. It resumes each parked agent sequentially, tolerates per-agent failures, and refreshes so the banner reflects whatever remains paused. When no import pauses exist but every agent in the company is paused, a generic all-paused banner links to the agents page. **Breaking changes** None. Depends on the `import` pause reason introduced in #12140 (this branch is stacked on it). ## What Changed - New exported helper `derivePausedAgentBanner(agents)` deciding between the imported banner, the all-paused banner, or none. - Dashboard renders the banners via the shared `InlineBanner`, with a sequential `agentsApi.resume` mutation for Resume all and query invalidation for the agent list and dashboard stats. ## Verification - `cd ui && npx vitest run src/pages/Dashboard.test.ts` — 4 tests pass (no agents, imported preference, all-paused fallback, mixed-state null). - `cd ui && pnpm run typecheck` — clean. - Manual: import a company package with paused agents, open its dashboard, click Resume all, and watch the banner clear as agents go idle. ## Risks - Low risk. Resume all reuses `POST /agents/:id/resume` with its existing guards, sequentially, matching the import page's activation checklist pattern. At current import sizes (tens of agents) this is fast; a server-side bulk endpoint is the follow-up if imports grow to hundreds of agents. ## Model Used - Claude Fable 5 (`claude-fable-5`, Anthropic) with extended thinking and tool use, via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 14:09:54 -07:00
Devin Foley	243430f76e	feat: agents see the company skill library at runtime (#12147) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - An agent's runtime mounts only its own enabled skills; nothing tells the model what else the company skill library holds > - From inside a sandbox, "installed but not enabled for me" and "does not exist" look identical, so agents tell users freshly installed skills are not installed > - This pull request renders the library as a deterministic markdown section appended to claude-local agent instructions, and adds a paperclipListSkills MCP tool > - The benefit is that agents report the true state ("installed, not enabled for me — ask an operator to enable it") instead of a false negative ## Linked Issues or Issue Description **What existing behavior does this improve?** How agents reason about the company skill library at runtime. **Subsystem affected** `packages/adapter-utils` (new pure builder), `packages/adapters/claude-local` (instructions append), `packages/mcp-server` (new tool). **Current behavior** The runtime hands adapters the full library list, but only the agent's enabled skills are mounted, and no prompt content or MCP tool describes the rest. Agents inspect their sandbox, find nothing, and report installed skills as not installed. **Proposed behavior** A "Company skill library" markdown section lists every skill as `enabled`, `installed, not enabled for you`, or `enabled but unavailable: <cause>`, with instructions to report the not-enabled state accurately and ask an operator to enable it. claude-local appends it to the agent instructions text. A `paperclipListSkills` MCP tool exposes the same list on demand. **Breaking changes** None. Other adapters are untouched (they can adopt the builder later); the manifest is deterministic, so the claude-local prompt-bundle cache only busts when the library actually changes. ## What Changed - New `packages/adapter-utils/src/skill-library-manifest.ts` with `buildSkillLibraryManifestMarkdown` (pure, key-sorted, deterministic; renders the missing-cause detail from #12146). - `packages/adapters/claude-local/src/server/execute.ts` appends the manifest to `combinedInstructionsContents` (creating it when no instructions file is configured). - `packages/mcp-server/src/tools.ts` adds `paperclipListSkills` hitting `GET /companies/:companyId/skills`. ## Verification - `npx vitest run packages/adapter-utils/src/skill-library-manifest.test.ts` (from repo root) — 3 tests: byte-identical output for shuffled input, state rendering incl. the unavailable cause, change detection. - `cd packages/mcp-server && npx vitest run` — new tool routing test passes (13 passed; 1 pre-existing failure on my machine reproduces unchanged at the branch base). - `cd packages/adapters/claude-local && npx vitest run` — 244 passed, 1 skipped. - `pnpm run typecheck` clean in adapter-utils, mcp-server, claude-local. ## Risks - Prompt growth is one line per installed skill plus a five-line header — bounded and only present when the library is non-empty. Stacked on #12146 so the manifest's "enabled but unavailable" state reflects real materialization failures. ## Model Used - Claude Fable 5 (`claude-fable-5`, Anthropic) with extended thinking and tool use, via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 14:01:52 -07:00
Devin Foley	79b464bf9d	fix(server): surface skill materialization failures instead of dropping the skill (#12146) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Runtime skill listing materializes each company skill's files before handing them to the agent's adapter > - A materialization failure was swallowed with catch-to-null, and the skill silently vanished from the runtime while the library still showed it installed > - Operators saw "installed", agents saw nothing, and nobody saw the cause; on claude-local a missing desired skill could even crash the prompt-bundle hasher > - This pull request turns both failure paths into structured "missing" entries with the real error and makes every adapter skip unmountable entries explicitly > - The benefit is that a broken skill shows up as broken, with its cause, instead of not existing ## Linked Issues or Issue Description **What happened?** A company skill whose runtime files fail to materialize (deleted source, missing stored SKILL.md copy, failed version snapshot) disappears from `listRuntimeSkillEntries` with no trace. Agent skill snapshots report a generic "not available" with no cause. On claude-local, a desired skill whose source path does not exist reaches the prompt-bundle hasher, whose `fs.lstat` throws and can fail the whole run. **Expected behavior** The skill appears with `sourceStatus: "missing"` and a `missingDetail` carrying the underlying error, snapshots and the UI show it as broken, and adapters skip it at mount time with a logged warning instead of crashing or dangling-symlinking. **Steps to reproduce** Install a local-path skill referenced by an agent, delete its source directory contents so the stored SKILL.md copy cannot be recovered, and start a run: before this change the skill vanishes from the runtime set silently; on claude-local a pinned-but-unmaterializable version can fail bundle preparation. ## What Changed - `server/src/services/company-skills.ts` `resolveRuntimeSkillSource`: both `.catch(() => null)` sites (version snapshot, runtime materialization) now return the structured `{status: "missing", source, detail}` shape the deliberate missing branch already used, with the underlying error message in `detail`. - `packages/adapter-utils/src/server-utils.ts`: `isPaperclipSkillSourceMissing` is exported with a doc comment. - `packages/adapters/claude-local/src/server/execute.ts`: missing desired skills are filtered out of the prompt bundle and each one logs a `[paperclip] Warning` with its detail to the run output. - `cursor-local`, `gemini-local`, `kimi-local`, `opencode-local`, `pi-local` `execute.ts`: mount loops (and the cursor/gemini injection calls) skip missing entries instead of symlinking a nonexistent path. ## Verification - `cd server && npx vitest run src/__tests__/company-skills-service.test.ts` — new test pins the missing-with-cause entry for a failed materialization. Nine pre-existing project-workspace tests in this file fail on my machine at clean `master` too (environment-specific); their count is unchanged by this PR. - `cd server && npx vitest run src/__tests__/heartbeat-runtime-skills.test.ts src/__tests__/claude-local-skill-sync.test.ts src/__tests__/cursor-local-skill-sync.test.ts src/__tests__/cursor-local-skill-injection.test.ts src/__tests__/gemini-local-skill-sync.test.ts` — 12 tests pass. - `cd packages/adapters/claude-local && npx vitest run` — 244 passed, 1 skipped. - `pnpm run typecheck` clean in server, adapter-utils, and all six touched adapters. ## Risks - Runtime skill entry lists grow by the previously dropped entries (now flagged missing). All shipped consumers either intersect with desired sets, already handle `sourceStatus: "missing"`, or now skip missing entries at mount time. The snapshot layer already understood the missing shape via the `materializeMissing: false` path, so downstream contracts are unchanged. ## Model Used - Claude Fable 5 (`claude-fable-5`, Anthropic) with extended thinking and tool use, via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 13:51:57 -07:00
Devin Foley	18b6c788d5	feat(server): de-duplicate imported company names (#12145) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Importing a company package as a new company takes the company name from the package manifest > - Repeat imports of the same package therefore create several identically named companies, distinguishable only by issue prefix > - Users cannot tell which import they are looking at, which feeds the "my import disappeared" loop of importing again > - This pull request suffixes manifest-derived names with " (2)", " (3)", … on collision, while honoring explicitly typed names verbatim > - The benefit is that every imported company has a recognizable name ## Linked Issues or Issue Description **What existing behavior does this improve?** Naming of companies created by the company package import. **Subsystem affected** Server — company import (`server/src/services/company-portability.ts`). **Current behavior** The new-company branch uses `newCompanyName ?? manifest name ?? "Imported Company"` with no de-duplication. Only the issue prefix is unique. Three imports of the same package yield three companies with the same name. **Proposed behavior** When the name comes from the manifest (no explicit `newCompanyName`), the import checks existing company names case-insensitively and appends the first free " (N)" suffix. Explicit names remain honored verbatim. Name exhaustion (thousands of collisions) falls back to the base name rather than failing the import, since names carry no uniqueness invariant. **Breaking changes** None. Only the default name of newly imported companies changes, and only on collision. ## What Changed - New exported pure helper `dedupeImportedCompanyName(baseName, existingNames)`. - The new-company branch resolves the name through it when no explicit name was provided, reading existing names via `companyService.list()`. ## Verification - `cd server && npx vitest run src/__tests__/company-portability.test.ts` — 87 tests pass (new: pure helper cases and two `importBundle` tests for the suffixed manifest name and the honored explicit name). - `cd server && npx vitest run src/__tests__/company-portability-routes.test.ts src/__tests__/company-portability-import-batching.test.ts` — 44 passed, 1 skipped (pre-existing skip). - `cd server && pnpm run typecheck` — clean. ## Risks - Low risk. The check-then-create has a theoretical race with a concurrent import, but names have no unique constraint — the worst case is today's behavior (a duplicate name). Issue-prefix uniqueness is untouched. ## Model Used - Claude Fable 5 (`claude-fable-5`, Anthropic) with extended thinking and tool use, via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 13:51:54 -07:00
Devin Foley	fcb84d472d	feat: already-imported transfer error names the landed company (#12144) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Chunked company-import transfers are deduplicated by content: a byte-identical zip that already finished an apply is rejected > - The rejection said only "this exact package was already imported by a completed transfer" without saying where that import went > - Users who could not find the earlier import read the rejection as data loss and kept retrying, or exported again and created duplicate companies > - This pull request makes the declaration response carry the company the completed apply created, and both clients name it in the error > - The benefit is that the dedupe rejection now points at the existing import instead of implying it vanished ## Linked Issues or Issue Description **What existing behavior does this improve?** The `alreadyCompleted` rejection when re-declaring a chunked company-import transfer. **Subsystem affected** Shared transfer contract (`packages/shared/src/company-import-transfer.ts`), transfer declaration route (`server/src/routes/companies.ts`), web import page, CLI import command. **Current behavior** `POST /api/companies/import/transfers` returns `alreadyCompleted: true` with no pointer to the earlier import. Web and CLI raise "This exact package was already imported by a completed transfer. Re-export the package to import it again." **Proposed behavior** The response includes an optional `company` field (`{id, name, issuePrefix} | null`) resolved from the completed run's company link. Web and CLI raise a shared message: `… It created the company "Paperclip" (PAPA) — open it from the company switcher. Re-export the package to import it again.` A company that was deleted since (or a link that was never written) degrades to `null` and the original message. **Breaking changes** None. The new response field is optional; old clients ignore it. ## What Changed - `CompanyImportTransferCreated` gains optional `company`, plus a shared `buildAlreadyImportedMessage` used by both clients. - The declaration route's `alreadyCompleted` branch resolves the landed company null-safely via `companyService.getById`. - Web (`ui/src/pages/CompanyImport.tsx`) and CLI (`cli/src/commands/client/company.ts`) raise the shared message. ## Verification - `cd packages/shared && npx vitest run src/company-import-transfer.test.ts` — 3 tests (named company, id fallback, no-company original message). - `cd server && npx vitest run src/__tests__/company-import-transfer-routes.test.ts` — 24 tests; the re-declaration test now asserts the company payload and the deleted-company null path. - `cd cli && npx vitest run src/__tests__/company-import-transfer.test.ts` — 17 tests; new test pins the named-company message. - `cd ui && npx vitest run src/pages/CompanyImport.test.tsx` — 23 tests. - `pnpm run typecheck` clean in shared, server, ui, cli. ## Risks - Low risk. The lookup runs only on the `alreadyCompleted` branch and is null-safe; the transfer run is already scoped to the requesting actor (user + instance context in the actor key), so the response never names a company the caller did not import. ## Model Used - Claude Fable 5 (`claude-fable-5`, Anthropic) with extended thinking and tool use, via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 13:51:50 -07:00
Devin Foley	868e210a95	feat(ui): post-import landing CTAs on every outcome branch (#12143) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Company import ends on one of two success screens: the full outcome, or a soft-success panel when the job's in-memory result expired before it could be read > - The soft-success panel named no company and offered no way in, and the full outcome never said that paused agents stay resumable after leaving the page > - Users on the soft-success path concluded the import vanished and ran it again, producing duplicate companies > - This pull request gives every success branch a named landing with a direct CTA into the new company and a pointer to the paused-agents banner > - The benefit is that a finished import always lands the user somewhere actionable ## Linked Issues or Issue Description **What existing behavior does this improve?** The outcome screens of the company import page. **Subsystem affected** Web UI — company import (`ui/src/pages/CompanyImport.tsx`). **Current behavior** The expired-job branch renders two sentences ("the company has been added — open it to view it") with no company name and no link. The full-outcome screen shows the activation checklist but does not say the checklist's resume actions remain available on the dashboard, so users treat the page as their only chance. **Proposed behavior** The expired branch keeps the landed company's name and dashboard path when readable, renders an "Open company dashboard" button, and notes that imported agents arrive paused and can be resumed from the dashboard banner. When the company is unreadable it gives explicit switcher guidance instead. The full-outcome screen states that paused items stay resumable from the dashboard. **Breaking changes** None. Pure UI copy/state additions to an existing page. ## What Changed - The `expired` import outcome now carries `companyName` and `dashboardPath`, captured from the already-fetched company in `onSuccess`. - The expired panel renders the company name, a dashboard CTA (`data-testid="import-expired-open-company"`), the paused-agents pointer, and a switcher fallback. - The full-outcome screen adds a line noting the dashboard offers the same resume actions as the activation checklist. ## Verification - `cd ui && npx vitest run src/pages/CompanyImport.test.tsx` — 24 tests pass; the soft-success test now asserts the name, pointer, and CTA, and a new test covers the unreadable-company fallback. - `cd ui && pnpm run typecheck` — clean. ## Risks - Low risk. The dashboard pointer references the paused-agents banner shipping in #12142; until that merges the sentence still points at the dashboard, where paused agents are already visible in the metric card. ## Model Used - Claude Fable 5 (`claude-fable-5`, Anthropic) with extended thinking and tool use, via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 13:51:46 -07:00
Devin Foley	11f6c754c9	feat: dedicated import pause reason with visible paused-assignee notices (#12140) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Company import parks every imported agent as a safety default, and issue assignment wakes are dropped for paused agents > - The pause was recorded as the generic reason "system" and was almost invisible: the chat-style task thread showed nothing, the legacy notice had no action, and the new-task dialog gave no hint > - Users assigned tasks in an imported company, nothing ran, and there was no explanation — the imported company looked broken > - This pull request records a dedicated "import" pause reason and makes the paused state visible and fixable where the user is looking > - The benefit is that a silent no-op becomes an explained state with a one-click resume ## Linked Issues or Issue Description **What existing behavior does this improve?** Working with a company whose agents arrived paused from a company import. **Subsystem affected** Shared constants (`PAUSE_REASONS`), company import service (`server/src/services/company-portability.ts`), task thread and new-task dialog UI. **Current behavior** Imported agents get `pauseReason: "system"`, the same value plugin-managed and built-in agent pauses use. Assigning an issue to a paused agent silently drops the wake. The chat-style task thread renders no paused notice; the legacy thread's notice says "It was paused by the system." with no action and only renders when the composer is shown. **Proposed behavior** Import writes `pauseReason: "import"`. The paused-assignee notice explains the import pause, offers an inline "Resume agent" button (suppressed for budget pauses, which clear on their own), and renders for read-only viewers. The chat-style task thread shows the same notice above the composer. The new-task dialog warns when the selected assignee is paused. **Breaking changes** None. `PAUSE_REASONS` is widened, not changed; the column already stores free-text values in other paths, and every consumer is an equality check with a manual fallback, so an older client shows the generic fallback copy for the new value. ## What Changed - `packages/shared/src/constants.ts`: `"import"` added to `PAUSE_REASONS`. - `server/src/services/company-portability.ts`: the import pause patch writes `pauseReason: "import"`. - `ui/src/components/IssueChatThread.tsx`: `IssueAssigneePausedNotice` gains import copy, a Resume button, test ids, and is exported; it now renders even when the composer is hidden. New `onResumeAssignee` / `resumeAssigneePending` props. - `ui/src/components/TaskChatThread.tsx`: renders the paused-assignee notice above the composer dock (the chat-style thread previously had no paused surface at all). - `ui/src/pages/IssueDetail.tsx`: wires a resume mutation (`agentsApi.resume`) through both thread variants and invalidates the company agent list. - `ui/src/components/NewIssueDialog.tsx`: inline note when the chosen assignee is paused, with import-specific copy. ## Verification - `cd server && npx vitest run src/__tests__/company-portability.test.ts` — 82 tests pass (pause pin updated to `"import"`). - `cd ui && npx vitest run src/components/IssueChatThread.test.tsx src/components/NewIssueDialog.test.tsx src/components/TaskChatThread.test.tsx` — 120 tests pass (new: notice copy per reason, resume click, budget suppression, active-agent null render, dialog note). - `pnpm run typecheck` in `packages/shared`, `server`, and `ui` — clean. ## Risks - Low risk. The resume action calls the existing `POST /agents/:id/resume` route with its existing guards. Existing rows keep `"system"` and fall back to the current generic copy; only new imports write `"import"`. ## Model Used - Claude Fable 5 (`claude-fable-5`, Anthropic) with extended thinking and tool use, via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 13:51:42 -07:00
Devin Foley	5af49cb477	feat(server): CEO agents get the core paperclip skills by default (#12138) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Each agent's runtime only receives skills listed in its own desired-skill set; the company library alone does nothing for an agent > - Every CEO creation path (first-run wizard hire, New Agent first-agent flow, cloud onboarding seed) creates the CEO with an empty desired-skill set > - The default CEO instructions tell the agent to use the core paperclip skills, so a fresh CEO contradicts its own instructions and reports its toolkit as "not installed" > - This pull request unions the core skill keys into every skills-capable CEO hire/create and into the onboarding-seeded CEO's adapter config > - The benefit is that a new CEO can actually do what its instructions describe, and stops telling users that installed skills do not exist ## Linked Issues or Issue Description **What existing behavior does this improve?** Creating the first lead agent (role `ceo`) via hire, create, or the cloud onboarding seed. **Subsystem affected** Server — agent hire/create routes (`server/src/routes/agents.ts`), onboarding seed (`server/src/services/onboarding-seed.ts`), company skills service constant (`server/src/services/company-skills.ts`). **Current behavior** A CEO created by the wizard, the New Agent page, or the onboarding seed has no `paperclipSkillSync` block. Its runtime mounts zero skills. Its default instructions (`server/src/onboarding-assets/ceo/AGENTS.md`, `HEARTBEAT.md`) tell it to use `paperclip-create-agent`, `para-memory-files`, and the paperclip coordination skill. The agent then reports these skills as not installed. **Proposed behavior** When the new agent's role is `ceo` and its adapter supports skill sync, the hire and create routes union the five bundled `paperclipai/paperclip/*` skill keys into the requested desired-skill set. The onboarding seed writes the same preference into the seeded CEO's adapter config. Explicit requests win over defaults for the same key. Non-CEO agents are unchanged. Any default stays removable through `POST /agents/:id/skills/sync`. **Breaking changes** None. The default is additive, applies only to role `ceo` on skills-capable adapters, and the bundled skills are guaranteed present in every company library by `ensureSkillInventoryCurrent`. ## What Changed - New exported constant `PAPERCLIP_CORE_SKILL_KEYS` in `server/src/services/company-skills.ts` (the five bundled `paperclipai/paperclip/*` keys). - `defaultRoleSkillSelections` + `withDefaultRoleSkillSelections` helpers in `server/src/routes/agents.ts`, applied in both the hire and create routes before `resolveDesiredSkillAssignment(..., "add")`. - `server/src/services/onboarding-seed.ts` builds the seeded CEO's adapter config with `writePaperclipSkillSyncPreference` instead of `{}` when the seeded adapter supports skills. ## Verification - `cd server && npx vitest run src/__tests__/agent-skills-routes.test.ts` — 32 tests pass (three new: CEO default set, union with a requested skill, non-CEO untouched). - `cd server && npx vitest run src/__tests__/onboarding-seed-route.test.ts` — 14 tests pass (seeded CEO adapter config assertion added). - `cd server && npx vitest run src/__tests__/agent-permissions-routes.test.ts` — 54 tests pass. - `cd server && pnpm run typecheck` — clean. ## Risks - Existing CEOs are not modified; only newly created ones get the defaults. An operator who wants a minimal CEO can remove the skills after creation with the skills sync (mode `remove`), and that removal sticks. Adapters without skill support are skipped, so the change is inert there. ## Model Used - Claude Fable 5 (`claude-fable-5`, Anthropic) with extended thinking and tool use, via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 13:51:39 -07:00
Devin Foley	d2b9765cc8	feat(ui): offer enabling a skill for agents at install time (#12136) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The company skill library lets operators install skills, and each agent has its own enabled-skill set > - Installing a skill only writes the library row; no agent receives the skill, and the UI says "Skill installed" with no attach step > - Operators install a skill, ask an agent to use it, and the agent truthfully reports the skill as not available — the install felt broken > - This pull request adds an "Enable for agents" step to the install dialog and enables the skill for the selected agents right after install > - The benefit is that "install" defaults to a state where agents can actually use the skill, and the toast is honest when they cannot ## Linked Issues or Issue Description **What existing behavior does this improve?** Installing a skill from the catalog in the company Skills page. **Subsystem affected** Web UI — company skills catalog install flow (`ui/src/pages/CompanySkills.tsx`). **Current behavior** Install writes a `company_skills` row and shows a "Skill installed" toast. No agent is enabled for the skill. Agents resolve their skills from their own desired-skill set, so they report the skill as not installed. The operator has to find the separate "Add to agent" control to make the install effective. **Proposed behavior** The install dialog shows an "Enable for agents" section for fresh installs. It pre-selects every agent whose adapter supports skills. After install, the page enables the skill for each selected agent (skills sync with mode `add`). The success toast reports how many agents received the skill, and warns when the skill is in the library with no agents enabled. **Breaking changes** None. Updates and replacements of an existing skill do not show the new section and behave as before. ## What Changed - `InstallPreviewDialog` gains an "Enable for agents" section (fresh installs only) built on the existing `AgentMultiSelect`, with agents whose adapter lacks skills support disabled. - New exported helper `defaultInstallAgentSelection` pre-selects every skills-capable, non-required agent. - The install mutation enables the skill for each selected agent via `agentsApi.syncSkills(..., "add")` before invalidating queries, and reports per-agent failures in a warning toast without failing the install. - Toast copy now distinguishes "enabled for N agents" from "in the library but not enabled for any agent yet". ## Verification - `cd ui && npx vitest run src/pages/CompanySkills.test.tsx` — 23 tests pass, including three new ones: default-selection helper, confirm payload carries the pre-selected agents, update/replace path skips the section. - `cd ui && pnpm run typecheck` — clean. - Manual: install a catalog skill with two agents in the company; both are pre-selected; after install the skill page lists both under "Used by agents". ## Risks - Low risk. Enablement uses the existing per-agent skills sync route with mode `add`, so concurrent edits to an agent's desired set are not overwritten. A per-agent sync failure surfaces as a warning toast and never fails the install itself. ## Model Used - Claude Fable 5 (`claude-fable-5`, Anthropic) with extended thinking and tool use, via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 13:51:35 -07:00
Devin Foley	8d714c2d84	fix(cli): skip the foreground-start prompt after the service starts (#12153) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The CLI onboarding wizard can install Paperclip as a background service, and it offers a foreground start when nothing else will serve > - After #12148, an interactive onboard installs and starts the service, then still asks "Start Paperclip now?" > - Answering yes runs the foreground start into the already-running instance guard, so a fully successful onboard ends with an error message > - This pull request excludes the just-installed-service case from the foreground-start prompt > - The benefit is that an interactive onboard that installs the service ends cleanly instead of steering the user into a guard refusal ## Linked Issues or Issue Description Refs #12148 — found while verifying that fix interactively. The `shouldRunNow` flag already accounts for `serviceInstalled`, but the interactive TTY fallback prompt did not, so only real interactive runs hit it: `--yes` runs, CI, and container smokes all skip the prompt branch. **What happened?** Interactive `onboard`, accept the background-service prompt. Output ends with: service installed and started, then "Start Paperclip now?" → yes → "Paperclip instance 'default' is already running as ing.paperclip.paperclipai. Use 'paperclipai service status --instance default' or pass --force to bypass this safety check." **What did you expect to happen?** Onboarding ends cleanly after "Installed and started …" — there is nothing left to start, so no prompt. **Steps to reproduce** Run `npx paperclipai@2026.825.0-nightly.1 onboard --data-dir "$(mktemp -d)"` in a terminal, accept the service prompt, then accept "Start Paperclip now?". ## What Changed - New `shouldOfferForegroundStart` predicate in `cli/src/onboard-service.ts`: the foreground-start prompt is offered only when the start was not already decided by flags, the service was not just installed, onboarding was not invoked by `run`, and the terminal is interactive. - Both onboarding call sites in `cli/src/commands/onboard.ts` use the predicate instead of the inline condition that ignored `serviceInstalled`. - Unit tests cover the predicate matrix in `cli/src/__tests__/onboard-service.test.ts`. ## Verification - `npx vitest run src/__tests__/onboard-service.test.ts` in `cli/`: 12 passed (5 new). - `tsc --noEmit` reports no errors in the changed files (remaining errors are pre-existing in `server/`). - Manual reproduction of the defect on macOS with `2026.825.0-nightly.1` before the fix: service installed, started, and healthy, then the prompt steered into the guard refusal. ## Risks - Low risk. The prompt still appears in every case it did before except when the service was just installed and is already serving. - No behavior change for `--yes`, `--run`, `--install-service` in non-interactive runs: those paths never reached the prompt. ## Model Used - Claude Fable 5 (Anthropic, model ID `claude-fable-5`), extended thinking, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 01:06:20 -07:00
Devin Foley	0a01444514	test(release-smoke): cover the background-service leg of onboarding (#12151) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The release pipeline gates each nightly and beta on a smoke suite that onboards the published npm artifact and drives the golden path > - That smoke runs onboarding inside a Docker container, and containers have no service manager, so the background-service leg of onboarding has zero automated coverage > - v2026.824.0 shipped a service install that crash-looped on a missing shim, and every smoke check stayed green (#12148 fixed the defect itself) > - This pull request adds a `smoke_service` job that runs the same published artifact directly on the runner VM's systemd and requires the installed service to end up serving > - The benefit is that a release with a broken service install can no longer pass the release smoke suite ## Linked Issues or Issue Description Refs #12148 — the fix for the defect this coverage gap let through. The gap: the release smoke runs `onboard` with `--yes` inside Docker, which both skips the service prompt and lacks systemd, so no CI job ever executed `manager.install()` against a real service manager. ## What Changed - New `scripts/service-onboard-smoke.sh`: onboards the published artifact with `--yes --install-service` on a systemd host, then fails unless the managed shim exists and is executable, `paperclipai.service` is active, and `/api/health` answers. A health response while the unit is not active also fails, because that is the signature of something other than the service serving. The script refuses to run over an existing managed install unless `SMOKE_FORCE=true`, and cleans up after itself by default so it is safe to run locally. - New `smoke_service` job in `.github/workflows/release-smoke.yml`: starts a user systemd session on the hosted runner (`loginctl enable-linger` + exported `XDG_RUNTIME_DIR`/`DBUS_SESSION_BUS_ADDRESS`), runs the script against `inputs.paperclip_version`, and uploads `systemctl status` + journal output as diagnostics. - No `release.yml` changes needed: `smoke_nightly` and `smoke_beta` call this reusable workflow, and a `workflow_call` result aggregates all jobs, so the new job gates nightly promotion automatically. ## Verification - `bash -n scripts/service-onboard-smoke.sh` passes and the workflow YAML parses. - End-to-end: dispatched this branch's Release Smoke workflow against the published canary that contains #12148; the `smoke_service` job onboards, installs the service, and verifies the service serves health. (Run link in PR comments.) - Negative case: the same assertions fail against v2026.824.0 — reproduced in a systemd container during the #12148 investigation: shim missing, unit in a 203/EXEC restart loop. ## Risks - Low risk to the product: no application code changes. - Pipeline risk: a flaky user-session setup on the hosted runner would block nightly promotion. Mitigated by validating the job end-to-end from this branch before merge, a 30-minute job timeout, and diagnostics uploaded on every run. - The service leg only covers systemd. launchd (macOS) still has no CI coverage; a macOS runner job is a possible follow-up. ## Model Used - Claude Fable 5 (Anthropic, model ID `claude-fable-5`), extended thinking, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-25 01:05:27 -07:00
Devin Foley	faad235aa2	fix(cli): materialize the managed install before the onboarding service install (#12148) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Interactive onboarding offers to install Paperclip as a background service, defaulting to yes > - The service definition targets the managed command shim, but an ephemeral npx run never installs it, and the service step never checks > - The result is a crash-looping service, a doctor hint about a nonexistent port conflict, and a first run that ends with nothing serving > - This pull request materializes the managed install before registering the service, or declines with the repair path > - The benefit is that saying yes to the service prompt yields a working service — or an honest explanation ## Linked Issues or Issue Description **What happened?** On a machine with no managed install, `npx paperclipai@2026.824.0 onboard` (interactive), accepting the background-service prompt, produced: a LaunchAgent pointing at `~/.local/bin/paperclipai` (which does not exist), launchd exit code 78 in a KeepAlive crash loop, doctor reporting "inactive but the configured port is serving another Paperclip process — stop the conflicting foreground process" (no such process existed), and "Service health: fetch failed". Reproduced twice on a clean field. `latest` has carried this path since v2026.817.0 shipped; CI never sees it because `--yes` onboarding skips the service prompt. **Expected behavior** Accepting the service prompt installs a working service (materializing the managed payload and shim first when needed), and doctor diagnoses a missing service binary as exactly that. **Steps to reproduce** On macOS with no `~/.local/bin/paperclipai`: `npx paperclipai@latest onboard`, accept the service prompt, then `launchctl print gui/$UID/ing.paperclip.paperclipai` (exit code 78, spawn scheduled) and `paperclipai doctor`. **Paperclip version or commit** `2026.824.0` (path present since #10045). ## What Changed - `cli/src/onboard-service.ts`: after the user opts in, an `ensureServiceShim` step checks the service shim path. Missing + managed-store location → run `installCommand` pinned to the onboarding version (payload, shim, PATH block), then proceed. Missing + custom `PAPERCLIP_SHIM_PATH`, or install failure → decline with `paperclipai install` / `paperclipai service install` guidance and install nothing. - `cli/src/checks/service-health-check.ts`: the runtime check diagnoses a missing service binary with the install repair hint (instead of the port-conflict hint); an inactive service with a healthy responder gets a `warn` attributing the foreign process instead of a plain "Healthy" pass. - Tests: new cases for shim materialization ordering, decline-on-failure, missing-binary diagnosis, and foreign-responder attribution; existing fixtures updated to inject the new dependencies. ## Verification - `vitest run` on both touched suites: 15 pass. - `tsc --noEmit` error count identical to the master baseline (16 pre-existing, all in `server/`, none in changed files). - The live failure was reproduced on macOS before the fix (twice, clean field) and the mechanism confirmed in source: `install()` writes the definition and bootstraps launchd only; `install-store` was previously reachable solely from the `install`/`update` commands. ## Risks - Low: the new path runs only when the user opts into the service and the shim is absent. The managed install resolves the pinned onboarding version from the public registry; on failure the flow declines exactly as it does on unsupported platforms. `--yes` quickstarts, Docker, and managed installs are untouched. ## Model Used Claude Fable 5 (Claude Code) ## Pre-submission checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template	2026-08-24 23:30:54 -07:00
Devin Foleyandgithub-actions[bot]	fa40a1b8d5	docs(release): canonicalize stable notes for v2026.824.0 (#12139) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Stable notes are drafted beta-keyed during the soak and published verbatim as the GitHub Release > - After the stable ships, the canonicalize job moves the file to its durable home, releases/vYYYY.MDD.P.md > - v2026.824.0 just shipped from the master-side beta notes, and the job pushed this rename branch > - This pull request lands that rename, keeping the stable-notes record complete at the canonical path > - The benefit is one canonical notes location per stable, with the pinned shipped content ## Linked Issues or Issue Description **What existing behavior does this improve?** The `releases/` record on master after the v2026.824.0 promotion. **Current behavior** The shipped notes live at `releases/beta/v2026.818.0-beta.1.md`; `releases/v2026.824.0.md` does not exist. **Proposed behavior** The file moves to `releases/v2026.824.0.md`, content pinned to the revision the release read (machine-generated by the `canonicalize_stable_notes` job). **Reason and benefit** The durable stable-notes invariant holds: every shipped stable has its notes at `releases/vYYYY.MDD.P.md`. ## What Changed - `git mv`-equivalent rename of the beta-keyed notes to `releases/v2026.824.0.md`, exactly as the release published them. ## Verification - Branch pushed by the release run's `canonicalize_stable_notes` job (run 32806191945) from the preflight-pinned notes revision; the GitHub Release v2026.824.0 body matches this content. ## Risks - None; docs-only rename. ## Model Used Claude Fable 5 (Claude Code) — PR opened for the machine-pushed branch; a GITHUB_TOKEN-created PR would not run required checks. ## Pre-submission checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>	2026-08-24 21:37:17 -07:00
Devin Foley	14867bd186	test(release-smoke): follow the mission-less onboarding reorder (#12135) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The nightly release lane publishes only after the release smoke suite passes against the newest canary > - Onboarding was reordered: step 1 now creates the company and routes straight to the agent step, and the mission step is gone (collected later in the tenant app, deliberately writing no goal) > - The smoke spec still walked the removed mission step, so the scheduled nightly has been red since the reorder shipped > - This pull request updates the spec to the current flow and asserts the deliberate empty goal list > - The benefit is a green nightly lane and an unblocked beta promotion from current master ## Linked Issues or Issue Description **What happened?** The scheduled `Release` nightly run fails in `smoke_nightly / smoke` since 2026-08-23 (runs 32630184811, 32710905212): `docker-auth-onboarding.spec.ts` waits for the `Define your mission` heading after step 1, but the wizard now routes 1 → 3 with no mission step (the step buttons literally skip from 1 to 3). The retry then fails on step 1 because the first attempt's company persists. **Expected behavior** The smoke passes against canaries carrying the reordered wizard, and the nightly lane publishes again. **Steps to reproduce** Run `scripts/docker-onboard-smoke.sh` with `PAPERCLIPAI_VERSION=2026.824.0-canary.7` and `pnpm run test:release-smoke` against it. **Paperclip version or commit** `2026.824.0-canary.7` Related (not duplicates): #11565 updated this same spec for the chat-first rewrite; this is the follow-up for the mission-less reorder. ## What Changed - Remove the mission-step interaction; step 1's "Next" now creates the company and the spec goes straight to the agent step. - Replace the mission-goal API assertion with the truthful one: onboarding deliberately writes no goal, so a fresh company's goal list is empty. - Update step comments to match the shipped flow. ## Verification - Local run of the exact CI harness against `paperclipai@2026.824.0-canary.7`: 1 passed (6.8s), exit 0. - The suite's remaining API assertions (company, CEO agent, seeded task assignment, landed issue URL, assignment-sourced heartbeat run) pass unchanged. ## Risks - Low risk: test-only. The spec remains copy-coupled to the wizard — this is the third drift in two weeks; stable `data-testid` hooks in the wizard remain the durable fix and can follow separately. ## Model Used Claude Fable 5 (Claude Code) ## Pre-submission checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template	2026-08-24 21:08:22 -07:00
Devin Foley	890ab9acfe	feat(release): thorough notes skeletons — nest each PR's summary at creation (#12124) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The release workflow drafts the upcoming stable's notes skeleton the moment a beta publishes > - That skeleton was a bare list of commit subjects, so the notes only reached the shipped stable's depth after a later authoring pass during the soak > - Stable release notes are consistently verbose and thorough; the initial draft should start that way too > - This pull request nests each referenced PR's own summary under its subject line at creation time, and states the density bar in the authoring skill > - The benefit is a thorough raw document from day one of the soak, with no LLM tokens in Actions ## Linked Issues or Issue Description **What existing behavior does this improve?** The `draft_stable_notes` skeleton generated at beta publish (`scripts/draft-stable-notes.sh`). **Current behavior** The skeleton groups bare commit subjects by conventional-commit type. All substance arrives later, when a maintainer or agent rewrites it — reviewed maintainer feedback: stable notes are a lot more verbose, and the initial beta notes should be consistent with that. **Proposed behavior** Each subject that references a PR carries that PR's own summary nested beneath it — the PR template's "What Changed" bullets, else the first prose lines — fetched best-effort via `gh` and skipped silently when unavailable. The release-changelog skill now states the density bar explicitly: the beta-keyed draft ships verbatim as the stable's notes and is written at the previous stable's depth from the first pass. **Reason and benefit** The notes author starts from a thorough raw document instead of a commit list, and beta-time notes match the verbosity the stable will ship with. ## What Changed - `scripts/draft-stable-notes.sh`: `enrich_pr` nests PR summaries under subjects; best-effort (`gh` failure or `DRAFT_NOTES_SKIP_PR_ENRICHMENT=1` degrades to today's output); pipefail-safe when a "What Changed" section has no bullets. - `.github/workflows/release.yml`: the `draft_stable_notes` step gets `GH_TOKEN` so `gh` can read PR bodies. - `.agents/skills/release-changelog/SKILL.md`: "write at full stable depth from the first pass" guideline. - `scripts/draft-stable-notes.test.mjs`: three new tests — enrichment rendering via a fake `gh`, silent degradation without one, and the sparse-body case that previously killed the script under `set -o pipefail`. ## Verification - `node --test scripts/draft-stable-notes.test.mjs` — 11 pass. - Live run against the real repository for the current beta (`2026.818.0-beta.1`, 172 commits): exit 0, 439 nested summary lines; spot-checked entries carry the correct PRs' What Changed bullets. - `bash -n` on the script; `release.yml` re-parsed as YAML. ## Risks - Low: the publish path is untouched; enrichment is read-only `gh` calls in the post-publish draft job and degrades to the current skeleton on any failure. Roughly one API call per commit in the range (~170 today) — well inside the token's rate budget, adds a couple of minutes to a job with a 10-minute timeout. ## Model Used Claude Fable 5 (Claude Code) ## Pre-submission checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template	2026-08-24 20:51:33 -07:00
Devin Foley	ae9711da48	docs(release): re-date the 2026.818.0-beta.1 stable notes to v2026.824.0 (#12113) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Stable versions date the promotion, and the promotion reads its notes from master > - The merged notes for beta 2026.818.0-beta.1 assumed an Aug 21 promotion; the beta soaked longer > - This pull request re-dates the header to today's resolved version, v2026.824.0 > - The benefit is a GitHub Release whose title, date, and body agree ## Linked Issues or Issue Description **What existing behavior does this improve?** The stable notes header for the promotion happening today. **Current behavior** `releases/beta/v2026.818.0-beta.1.md` is titled `# Paperclip v2026.821.0`, `> Released: 2026-08-21`. **Proposed behavior** `# Paperclip v2026.824.0`, `> Released: 2026-08-24` — matching `./scripts/release.sh stable --date 2026-08-24 --print-version`. **Reason and benefit** The file publishes verbatim as the GitHub Release body; the header should match the version actually minted. ## What Changed - Three header/intro lines re-dated. Nothing else. ## Verification - `./scripts/release.sh stable --date 2026-08-24 --print-version` → `2026.824.0`. ## Risks - None; docs-only. ## Model Used Claude Fable 5 (Claude Code) ## Pre-submission checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template	2026-08-24 20:42:25 -07:00
Devin Foley	83fefaadd1	fix(grok_local): do not warn when the default model sentinel is unavailable (#12062) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Each agent runs under an adapter. The `grok_local` adapter runs the Grok Build CLI. > - The adapter has an environment test. It probes the CLI and reports checks to the operator. > - `DEFAULT_GROK_LOCAL_MODEL` is `"grok-build"`. This value is a sentinel. It means "use the Grok CLI's own default model". > - `execute.ts` only passes `--model` when the configured model differs from the sentinel. So the sentinel is never sent to grok. > - The environment test still compared the sentinel to the models that `grok models` lists. Real grok never lists `grok-build`. > - So every probe emitted a false "Configured model not found" warning, even on a correctly configured agent. > - This pull request stops the false warning and keeps the real check for user-set models. > - The benefit is an accurate environment test: operators see a warning only when it is real. ## Linked Issues or Issue Description No public issue exists. The problem, in bug-report form: **What happened?** The `grok_local` environment test always warns `Configured model "grok-build" not found in available models`, even when the agent works. `grok-build` is the default sentinel, not a real model id, and it is never sent to the CLI. **Expected behavior** When the model is left at the default, the test reports the CLI's own default model as info and does not warn. It warns only when a user sets a real model that `grok models` does not list. **Steps to reproduce** 1. Create a `grok_local` agent and leave the model at its default. 2. Run the adapter environment test. 3. See the `grok_model_not_found` warning, although `grok models` and the hello probe succeed. **Agent adapter(s) involved** grok_local (Grok Build CLI). ## What Changed - `packages/adapters/grok-local/src/server/test.ts`: the model check now treats the default sentinel as valid and reports it as info (`Using the Grok CLI's default model (<default>)`). It still warns when an explicitly configured, non-sentinel model is absent from the discovered list. This matches `execute.ts`, which never sends the sentinel to grok. - `packages/adapters/grok-local/src/server/test.test.ts`: adds a test that the default sentinel does not warn when it is absent from the real model list, and a test that a real, unavailable model still warns. ## Verification - `pnpm exec vitest run packages/adapters/grok-local/src/server/test.test.ts` — 5 passed. ## Risks Low risk. The change only affects one adapter's environment-test reporting. It does not change how runs pass `--model`. No schema, no runtime behavior change. ## Model Used Claude Fable 5 (`claude-fable-5`), extended thinking, with tool use and code execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links - [x] My branch name describes the change and contains no internal Paperclip ticket id - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes (n/a — no doc change) - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge	2026-08-24 09:38:34 -07:00
Devin FoleyandClaude	0dfa0fb988	ci: refresh general-server shard duration manifest (#12075) ... <!-- Write all pull request text in Simplified Technical English (ASD-STE100). --> ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The PR verify workflow gates every pull request; its slowest check sets the feedback time for all contributors > - The general-server test lane splits its vitest suites across five runners with a duration-weighted partition (`scripts/general-server-shard.mjs`) > - The partition reads a duration manifest that was sampled on 2026-08-04, when the lane had 279 suites and 946s of serial time > - The lane has since grown to 405 suites and 1274s; 126 suites had no recorded duration and one suite grew from 37s to 123s > - The stale weights made the partition uneven: in the fully green actions run 32708351172, "General tests (server (2/5))" ran 364s and was the slowest check in the whole run, while sibling shards ran 292-330s > - This pull request refreshes the manifest with per-suite durations measured from that same run > - The benefit is a level five-shard split (255s ±1s of predicted suite time per shard), which removes ~50s from the slowest PR check ## Linked Issues or Issue Description **Describe the current behavior** In the fully green PR actions run [32708351172](https://github.com/paperclipai/paperclip/actions/runs/32708351172) (2026-08-24), the check "General tests (server (2/5))" completed in 364s. Its test step ran 315s while sibling shards ran 241-276s. It was the slowest check in the run. **Describe the improvement** The duration manifest `scripts/general-server-shard-durations.json` is stale. It holds 279 suites sampled on 2026-08-04, but the lane now has 405 suites. The 126 unknown suites fall back to the median weight (~1.3s), and `server/src/__tests__/workspace-runtime.test.ts` grew from 37.4s to 123.3s. The partition therefore predicts a level split but produces an uneven one. Refreshing the manifest restores the level split without any code change. **Expected impact** All five server shards level at ~255s of predicted suite time (~310s job time). The slowest PR check drops from 364s to about 317s, so the PR critical path improves by roughly 50s. ## What Changed - Regenerated `scripts/general-server-shard-durations.json` from actions run 32708351172 (2026-08-24): 405 suites, 1274s total serial time (was 279 suites, 946s from 2026-08-04) - Updated the `$comment` field to name the new sample run and date - No code changes; the partition logic in `scripts/general-server-shard.mjs` is untouched ## Verification - Parsed all five "General tests (server (n/5))" job logs from run 32708351172 with the consecutive-completion-timestamp method described in the manifest `$comment`; asserted that the parsed suite set equals the exact file list that `run-vitest-stable.mjs` collects (405/405, no misses, no extras) - Ran `node scripts/run-vitest-stable.mjs --mode general --group general-server --shard-index N --shard-count 5 --dry-run` for N=0..4 with the new manifest: each shard predicts 255s (±1s) of suite time, and the five shards form a complete, non-overlapping cover of all 405 suites - Ran `node --test ./scripts/__tests__/run-vitest-stable-shard.test.mjs`: 13/13 pass ## Risks - Low risk. The change is data-only. Wrong weights cannot break correctness: the partition always covers every suite exactly once, so the worst case of a bad weight is an uneven shard, which is the current state. ## Model Used - Claude (Anthropic), model ID `claude-fable-5`, agentic coding session with tool use (Claude Code / Claude Agent SDK) ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable (no code change; existing partition tests pass) - [x] I have updated relevant documentation to reflect my changes (manifest `$comment` updated) - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge Related prior work: #11528 (balanced the serialized server shards by recorded duration), #10923 (split serialized tests into five shards), #11156 (split workspaces-a into two shards). Co-authored-by: Claude <noreply@paperclip.ing>	2026-08-24 08:54:52 -07:00
Devin Foley	87d68f476b	fix: harden the sandbox bridge gateway against crashes and queue wedge (#12060) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Agents on remote sandbox targets reach the Paperclip API through the sandbox callback bridge: a loopback HTTP gateway inside the sandbox queues request files for a host-side worker > - The gateway process has no supervisor: nothing inside the sandbox respawns it, so a crash leaves a dead loopback port for the rest of the run > - The gateway also never cleaned up request files whose responses never arrived, so a stalled host wedged the queue at its depth cap and every later request got an immediate 503 > - #12052 made the host-side worker survive transient faults; this pull request hardens the other half of the relay > - The benefit is that a gateway fault degrades one request instead of severing the agent from the control plane until run end ## Linked Issues or Issue Description Refs #12052 (host-side worker half of the same relay). Refs #9904 and #8977 (adjacent bridge behavior). No public issue exists for this defect. The description below follows the bug report template. **What happened?** During a staging run, an agent's API calls to the bridge's loopback port began failing at the connection level (curl reported HTTP 000) partway through the run. A dead gateway process is the only mechanism that produces connection-level failures on that port, and nothing restarts it. Separately, request files for timed-out requests stayed in the queue; after 64 accumulated, the gateway answered every request with `503 Bridge request queue is full.` until the run ended. **Expected behavior** An uncaught fault in the gateway must not kill the loopback listener. A request that times out must not leave its file counting toward the queue-depth cap. A queue full of orphaned files must recover instead of rejecting until run end. **Steps to reproduce** 1. Start a remote-sandbox run and stop the host-side bridge worker. 2. Send requests to the gateway until they time out; the request files stay in `requests/`. 3. After 64 such files, every request gets an immediate 503, even after the host recovers. 4. Independently, raise any uncaught exception in the gateway process; the loopback port dies for the rest of the run. ## What Changed - The generated gateway source installs global `uncaughtException` / `unhandledRejection` handlers that log to stderr (already redirected to `logs/bridge.log`) and keep serving. The relay holds no state a fault can corrupt beyond the one request it interrupted. - Survival is gated on readiness: before the gateway has written its readiness file (file mode) or sent its READY frame (duplex mode), the same handlers exit(1) instead. A startup fault (failed bind, failed readiness write) means the process can never serve, and surviving there would only leave an un-ready zombie while the host waits out its readiness poll. - The file gateway attaches an explicit `error` listener to its server and pins the event loop with a keepalive until the bind settles. Newer Node runtimes do not reliably surface a failed bind through `uncaughtException` in this shape: the process can drain and exit 0 before the error event is delivered (reproduced on Node 24/25; Node 22 delivered it). The duplex gateway already had an explicit listener. - A request that times out waiting for the host now deletes its own request file. The host's response write is guarded on that file, so the removal also signals that no caller waits anymore. - At the queue-depth cap, the gateway sweeps request files older than the response deadline (orphans from killed callers or a previous gateway process) before rejecting with 503. - Host-side, `processRequestFile` treats a request file that vanished before the read as the benign caller-gave-up race and skips it quietly instead of escalating into the recovery pass. ## Verification - `npx vitest run packages/adapter-utils/src/sandbox-callback-bridge.test.ts` — 43 passed, verified on both Node 22 and Node 25. - New end-to-end test: with no worker running, a request times out (502), its file is cleaned, and the same gateway then serves a 200 once a worker starts — no wedge, no dead port. - New end-to-end test: with `maxQueueDepth: 1` and a backdated orphan file at the cap, the gateway sweeps the orphan and admits the request instead of answering 503. - New worker test: a request file that vanishes before the read is skipped without a handler call, a response write, or a run-level error. - New generated-source test: spawned directly against an already-occupied port, the gateway exits 1 promptly with the `EADDRINUSE` fault on stderr instead of lingering un-ready (or exiting 0 silently, the pre-existing behavior on Node 24/25). - A pin keeps the crash handlers, the readiness gate, and the sweep in the generated source. - `pnpm --filter @paperclipai/adapter-utils typecheck`. ## Risks - Keeping a Node process alive after `uncaughtException` is normally suspect; here the alternative is a dead loopback port for the rest of the run, and the gateway is a stateless per-request relay. The fault is logged with its stack to `bridge.log`, and survival applies only after readiness — startup faults still fail fast. - Deleting a timed-out request file could race a host that is mid-processing. The host's response write is already guarded on request-file existence, and the new host-side skip treats the vanished file as a no-op, so no duplicate mutation path is introduced. - The stale sweep runs only at the depth cap and only removes files older than the response deadline plus a 2 s grace, so a live caller's file is never swept. - Orphaned response files (host responded after the caller gave up) still linger; that pre-existing minor leak is unchanged here. ## Model Used - Claude Fable 5 (Anthropic), model id `claude-fable-5`, extended thinking enabled, agentic tool use via Claude Code (CLI harness), 200k context window. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-24 08:52:05 -07:00
Devin Foley	fc9e9b704f	fix: stop teaching agents to curl literal {id} route templates (#12061) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Adapters inject prompt text that teaches agents how to call the Paperclip API, including copy-pasteable curl examples > - Some of those URLs contained brace placeholders like `/api/issues/{id}/checkout` > - Agents paste such lines verbatim; the placeholder reaches the server as `/api/issues/%7Bid%7D` and 404s, and request logs show agents doing exactly that > - The acpx engine's API note already avoids this by using `$PAPERCLIP_TASK_ID`, and its test pins `/api/issues/{id}` out of the prompt > - This pull request applies the same standard to the gemini adapter, the shared prompt template, and the openclaw gateway workflow > - The benefit is that agents stop burning turns on placeholder 404s and doc examples stay safe to execute as written ## Linked Issues or Issue Description No public issue exists for this defect. The description below follows the bug report template. **What happened?** Server request logs show agents issuing `GET /api/issues/%7Bid%7D` — the literal, percent-encoded text `{id}` — which 404s. The source is adapter prompt text: the gemini adapter's API note embeds a curl example with `/api/issues/{id}/checkout` in the URL, the shared agent prompt template mentions `/api/issues/{issueId}` endpoints, and the harness checkout notice names `/api/issues/{id}/checkout`. Models copy these strings into real requests. **Expected behavior** URL paths in prompt text must carry environment variables or real ids, never brace placeholders, in every string an agent might execute verbatim. Where a placeholder is unavoidable, the prompt must state explicitly that the literal text must never be sent. **Steps to reproduce** 1. Give an agent the gemini adapter's API access note. 2. Watch it call `curl ... "$PAPERCLIP_API_URL/api/issues/{id}/checkout"` as written. 3. The server logs `POST /api/issues/%7Bid%7D/checkout 404`. ## What Changed - gemini-local's API note curl example now uses `$PAPERCLIP_TASK_ID` and tells the agent to substitute a real issue id when that variable is absent — the same convention as the acpx engine's API note. - The shared agent prompt template (`server-utils.ts`) uses `$PAPERCLIP_TASK_ID` in its interaction-creation and resume-endpoint mentions, and the harness checkout notice names `POST /api/issues/$PAPERCLIP_TASK_ID/checkout`. - openclaw-gateway's endpoint workflow keeps its `{issueId}` placeholders — they are defined by its "determine issueId" step — but now states explicitly that the literal text must never be sent in a URL. - `server-utils.test.ts` pins the new form and adds negative pins that keep `/api/issues/{id}` and `/api/issues/{issueId}` out of the shared prompt template, mirroring the existing acpx-engine negative pin. - The `confirmation:{issueId}:plan:{revisionId}` idempotency-key template is untouched: it is a value-construction pattern, not a URL. ## Verification - `npx vitest run packages/adapter-utils/src/server-utils.test.ts packages/adapters/gemini-local packages/adapters/openclaw-gateway` — 152 passed. The single failure (`pre-selects gemini-api-key auth in the managed HOME for sandbox execution`) is a pre-existing environment-specific failure on the development machine, unrelated to prompt text; CI is authoritative for it. - `pnpm --filter @paperclipai/adapter-utils --filter @paperclipai/adapter-gemini-local --filter @paperclipai/adapter-openclaw-gateway typecheck`. ## Risks - Low risk: prompt-text and test changes only; no runtime logic changes. - Agents that memorized the old example strings keep working — the routes are unchanged, only the placeholder text in prompts is. ## Model Used - Claude Fable 5 (Anthropic), model id `claude-fable-5`, extended thinking enabled, agentic tool use via Claude Code (CLI harness), 200k context window. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-23 17:16:30 -07:00
Devin Foley	633e102971	fix: verify issue-update writes instead of inferring success (#12051) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Agents report task state to the control plane with `PATCH /api/issues/{id}` at the end of each heartbeat > - On remote sandbox targets those writes cross a relay that can fail at the connection level > - An agent that pipes its status curl through `head` cannot see that failure; the write is lost but the run reports success > - The issue then stays `in_progress` with no disposition, and the missing-disposition recovery must repair it > - This pull request makes the issue-update helper verify every write, and it teaches the shared skill to require verified writes > - The benefit is that a lost status write becomes a visible, retried failure instead of a silent success ## Linked Issues or Issue Description No public issue exists for this defect. The description below follows the bug report template. **What happened?** A sandboxed heartbeat run answered its issue in a comment. It then sent `PATCH /api/issues/{id}` with `status: done` through `curl -sf ... | head -c 400`. The relay dropped the connection. The `-f` flag suppressed the error output, and the pipe replaced curl's exit code with the exit code of `head`. The agent saw empty output and exit 0. It reported the write as an "empty 2xx" success and exited. The issue stayed `in_progress`, and the successful-run recovery had to close it in a corrective run. **Expected behavior** A status write that does not reach the server must surface as a failure. The helper script must retry transient failures. It must exit non-zero when the write is unconfirmed. Skill guidance must forbid write patterns that hide failures. **Steps to reproduce** 1. Point `PAPERCLIP_API_URL` at an endpoint that drops connections intermittently. 2. Finalize an issue with `curl -sf -X PATCH "$PAPERCLIP_API_URL/api/issues/$ID" -d '{"status":"done"}' | head -c 400`. 3. Observe exit code 0 with empty output while the server never received the PATCH. ## What Changed - `scripts/paperclip-issue-update.sh` now captures `%{http_code}`, retries a retryable failure (connection-level, 429, 5xx) once — two attempts total, which matches the shared bounded-write-retry rule — rejects an empty 2xx body, and confirms the response echoes the requested status before it exits 0. - Failure output states plainly that the write was NOT saved, so the calling agent reports it accurately. - `skills/paperclip/SKILL.md` Step 8 adds a required "Verify writes — never infer them" rule: a successful PATCH always returns the updated issue JSON, disposition writes must never run through `head`/`tail` pipelines, and an unconfirmed write must be reported as FAILED. - `server/src/__tests__/paperclip-skill-utils.test.ts` pins the new skill rule; a new `paperclip-issue-update-helper.test.ts` exercises the helper's behavior end-to-end. ## Verification - `bash -n scripts/paperclip-issue-update.sh` - `server/src/__tests__/paperclip-issue-update-helper.test.ts` runs the helper end-to-end against a local HTTP server: confirmed-echo success (exit 0), empty 2xx (exit 1), wrong echoed status (exit 1), 422 reject (exit 1, exactly one request), 503 then success (two requests), connection refused (two attempts, then exit 1 with a "NOT saved" report). - `npx vitest run server/src/__tests__/paperclip-issue-update-helper.test.ts server/src/__tests__/paperclip-skill-utils.test.ts server/src/__tests__/cli-invocation-safety.test.ts` — 50 passed. ## Risks - Low risk. The success-path output is unchanged (the updated issue JSON). - The helper now exits non-zero on unconfirmed writes. Callers that previously missed silent failures now see explicit errors. That is the intended behavior change. - The single retry re-sends the PATCH after a retryable failure. If the first request committed and only its response was lost, an attached comment can post twice. The duplicate is visible and benign; the prior behavior lost the write silently. ## Model Used - Claude Fable 5 (Anthropic), model id `claude-fable-5`, extended thinking enabled, agentic tool use via Claude Code (CLI harness), 200k context window. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-23 16:56:51 -07:00
Devin Foley	c7f4bc1300	fix: survive transient sandbox exec failures in the callback bridge worker (#12052) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Agents on remote sandbox targets reach the Paperclip API through the sandbox callback bridge: a loopback gateway inside the sandbox writes request files, and a host-side worker polls them over the provider's exec channel and forwards them to the server > - The worker's poll loop had one terminal catch: a single reset or slow exec ended the relay for the rest of the run > - The in-sandbox gateway kept queueing requests against the dead worker, so every later API call from the agent stranded, including its final status write > - A relay that dies on one transient fault turns a routine provider hiccup into a lost issue disposition > - This pull request restructures the loop so transient faults back off and retry, while the watchdog remains the escalation path for sustained outages > - The benefit is that one flaky exec no longer severs an agent from the control plane mid-run ## Linked Issues or Issue Description Refs #9904. Refs #8977. Both touch adjacent bridge behavior (curl shim, header forwarding); neither addresses worker-loop lifetime. No public issue exists for this defect. The description below follows the bug report template. **What happened?** During a staging run, the host-side bridge worker hit one failed sandbox exec while relaying requests. The poll loop's only catch is terminal: it failed the pending requests and set the worker to settled, with no restart. The agent's later API calls saw connection-level failures or bridge errors until the run ended. Its final `PATCH status: done` was lost, and the missing-disposition recovery had to repair the issue in a corrective run. **Expected behavior** One transient exec failure must not end the relay for the rest of the run. The worker must back off and retry. A sustained outage must still fail queued requests fast through the watchdog. In-flight request semantics (abort plus 504 backstop, retry-safe 503) must not change. **Steps to reproduce** 1. Start a remote-sandbox run and let the provider exec channel reject or stall one call while the bridge worker polls. 2. The worker hits one `listJsonFiles` failure or one request-attempt timeout, and the loop exits through its terminal catch. 3. Every later bridge request strands. The loopback gateway keeps accepting requests that never complete, and after 64 queued files it answers every request with 503 until run end. ## What Changed - `startSandboxCallbackBridgeWorker`'s poll loop now separates three failure domains: - A failed poll backs off exponentially (capped at 5 s) and retries instead of dying. The first failure of a streak still lands on the run trace through the workerFailed span; later repeats only warn. - A failed or hung request attempt runs the same recovery pass the loop previously died on — abort the in-flight handler (its 504 backstop keeps the caller from stranding) and 503 the unclaimed queued requests — and the loop then continues and serves the caller's retry. - A listing where every file already has an in-flight attempt sleeps one poll interval, like an empty listing. The previous immediate re-list was a hot spin: an exec storm against a real channel, and a pure-microtask loop that starved every timer in the process when the queue client resolves synchronously. - The watchdog, the claim/finalize fences, and the stop/drain semantics are unchanged. ## Verification - `npx vitest run packages/adapter-utils/src/sandbox-callback-bridge.test.ts` — 38 passed. - New regression test: a request queued behind three consecutive poll failures is still delivered. - Updated tests: the stalled-poll test now expects recovery (the handler's real 200) instead of a terminal 503; the sustained-outage 503 path remains proven by the dedicated watchdog test; the recovery-503-write-retry test triggers the recovery pass through a hung request read, because a hung poll no longer runs that pass. - `pnpm --filter @paperclipai/adapter-utils typecheck`. ## Risks - Behavior change: a transiently failing poll no longer mass-fails queued requests on the first error. Callers wait through the backoff window, bounded by the existing in-sandbox 30 s response deadline, or the watchdog fails them after 20 s of no successful iteration. This trades fast-but-terminal degradation for recovery. - A hard-down channel now retries every ≤5 s for the rest of the run instead of stopping. Each retry is one exec attempt against a channel that already fails. - In-flight mutation safety is unchanged: the guard map and the claim protocol still prevent a double-applied host mutation, and a guarded file is always finalized by its own attempt or by its 504 backstop. ## Model Used - Claude Fable 5 (Anthropic), model id `claude-fable-5`, extended thinking enabled, agentic tool use via Claude Code (CLI harness), 200k context window. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-23 16:55:23 -07:00
Devin Foley	c62bb4b16b	feat: environment delete with agent reassignment and consented sandbox destroy (#12053) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Environments define where agent runs execute: local, SSH, or provider sandboxes > - Operators can create and edit environments, but the UI has no way to delete one > - The server already exposes `DELETE /environments/:id` and a delete-blast-radius preflight, but no UI consumes them, and a delete blocked by reusable sandbox leases gives the operator no path forward > - This pull request adds the delete flow to the environment configuration page: a preflight-driven modal that reassigns dependent agents, names the workspaces that hold blocking sandbox leases, and can destroy those sandboxes with explicit consent > - The benefit is that operators can retire stale environments from the UI without database surgery, and dependent agents move to a chosen replacement instead of silently falling back ## Linked Issues or Issue Description Refs #8554 Refs #11124 **Subsystem affected** Environments (server routes, environment runtime service, and the environment settings UI). **Problem or motivation** The environment configuration page has no delete control. The server delete endpoint exists, but nothing in the UI calls it. When reusable sandbox leases block a delete, the 409 error names no owner, so the operator cannot find the blocking workspace. Agents that use the environment as their default lose it silently through the FK `on delete set null`. **Proposed solution** Add a delete button with a confirmation modal on the environment edit page. The modal reads the delete-blast-radius preflight. It offers a dropdown to reassign dependent agents to another environment before the delete. It lists each workspace that holds a blocking reusable sandbox lease, with a link. When those leases are the only blocker, the confirm button destroys the sandboxes inline (`?destroyReusableSandboxLeases=true`) and then deletes. A failed teardown falls back to `pending_cleanup` for the sweep, so no sandbox is orphaned. ## What Changed - `ui/src/pages/CompanyEnvironments.tsx`: delete button on the edit page header, confirmation modal with agent reassignment select, lease-holder list, impact notes, and a consent-labeled destroy-and-delete action - `ui/src/api/environments.ts`: `deleteBlastRadius` and `remove` client methods; `remove` takes an optional `destroyReusableSandboxLeases` flag - `server/src/routes/environments.ts`: `DELETE /environments/:id` accepts `?destroyReusableSandboxLeases=true`; it destroys the environment's reusable sandbox leases first, but only when those leases are the sole delete blocker, then re-checks the blast radius before it deletes - `server/src/services/environment-runtime.ts`: new `destroyReusableSandboxLeasesForEnvironment` — destroys every reusable sandbox lease an environment still owns while the environment config (provider credentials) is still available - `server/src/services/environments.ts`: the delete blast radius now returns `reusableSandboxLeaseHolders` (lease id, workspace, issue) so clients can name what blocks a delete - `packages/shared/src/types/environment.ts`: `EnvironmentDeleteReusableLeaseHolder` type on the blast radius - Tests: route gating for the consent flag (destroy runs, mixed-blocker rejection, surviving-lease rejection), runtime destroy scoped to an environment, blast-radius holder join, and UI tests for the reassignment flow, holder links, and the consent button ## Verification - `npx vitest run server/src/__tests__/environment-routes.test.ts server/src/__tests__/environment-service.test.ts server/src/__tests__/environment-runtime.test.ts ui/src/pages/CompanyEnvironments.test.tsx` - Manual: open Settings → Environments → edit an environment. The trash icon opens the modal. With agents on the environment, pick a reassignment target and confirm; agents move and the environment deletes. With reusable sandbox leases, the modal names the holding workspaces and the confirm button reads "Destroy N sandboxes and delete". ## Risks - The consented path destroys provider sandboxes. It runs only when reusable leases are the sole blocker, so a delete that would still be rejected never destroys anything. A failed teardown routes to `pending_cleanup` and the delete stays blocked until the sweep resolves it. - Agent reassignment issues one PATCH per agent from the client. A mid-sequence failure leaves some agents reassigned; the reassignments are valid on their own and the UI refreshes to the actual state. - Hard blockers (managed local, instance default, pending cleanup) keep the existing 409 behavior and disable the confirm button. ## Model Used - Claude (Anthropic) — Fable 5, model id `claude-fable-5`, extended thinking, agentic tool use via Claude Code CLI. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-23 16:53:17 -07:00
Devin Foley	627eef7cbd	fix(plugins): retry errored plugins at boot instead of leaving them dead (#12054) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Plugins extend the server with sandbox providers, tools, and jobs; a loader activates them at boot > - When activation fails, the loader marks the plugin `error` and skips it on every later boot > - Activation failures are often environmental — missing package dependencies, a stale build output, a module that moved under a pull — and the fix lands on disk without any write to the plugin row > - The plugin therefore stays dead forever, and every feature behind it (sandbox destroys, cleanup sweeps, probes) silently stops working until an operator flips the row by hand > - This pull request makes `loadAll` retry errored plugins once per boot: flip to `ready`, attempt activation, and re-record the error if the attempt fails > - The benefit is that a plugin recovers on the next boot after its environment is fixed, with no manual database or lifecycle intervention ## Linked Issues or Issue Description **What happened?** Several sandbox-provider plugins sat in `error` status for weeks after a transient activation failure (a module resolution error from an older checkout state). The boot loader only loads plugins in `ready` status, so it never retried them. Environments backed by those providers lost sandbox destroys, cleanup sweeps, and probes with no visible signal other than the stale `last_error`. **Expected behavior** A plugin whose activation failure has been fixed on disk recovers on the next server boot. A plugin that still fails stays in `error` with a fresh error message. **Steps to reproduce** 1. Install a plugin whose worker cannot start (for example, delete one of its dependencies), then boot the server. The plugin lands in `error` status. 2. Restore the dependency. 3. Restart the server. Before this change, the plugin stays in `error` forever. After this change, the boot retries it and the plugin activates. ## What Changed - `server/src/services/plugin-loader.ts`: `loadAll` also fetches plugins in `error` status, flips each to `ready`, and activates it with the normal batch. The flip runs before activation because the `error` status only legally transitions to `ready` or `uninstalled`; a retry that failed while still in `error` could not re-mark itself. A failed flip logs a warning and never aborts the boot load. The stale comment at the `markError` site now describes the retry. - `server/src/__tests__/plugin-loader-error-retry.test.ts`: covers the flip-then-retry flow, the failed-flip isolation, and the empty case. ## Verification - `npx vitest run server/src/__tests__/plugin-loader-error-retry.test.ts server/src/__tests__/bundled-plugins.test.ts server/src/__tests__/plugin-lifecycle-restart.test.ts server/src/__tests__/cloud-image-bundled-plugins.test.ts` - Manual: mark an installed plugin's status to `error`, restart the server, and observe the loader log line `retrying plugins that failed activation on a previous boot` followed by a successful activation (or a fresh `last_error` if the plugin is genuinely broken). ## Risks - A genuinely broken plugin now costs one bounded activation attempt per boot (the attempts run in parallel with the ready batch under `Promise.allSettled`). It cannot crash-loop within a running process, and it returns to `error` with a fresh message. - The flip clears `last_error` before the attempt. If the process dies between the flip and the activation, the row is `ready` with no error text; the next boot simply loads it as a ready plugin. - Operators who relied on `error` as a manual "keep this off" latch should use the `disabled` status, which this change does not touch. ## Model Used - Claude (Anthropic) — Fable 5, model id `claude-fable-5`, extended thinking, agentic tool use via Claude Code CLI. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-23 16:52:42 -07:00
Devin FoleyandPaperclip	fbd20b28d3	fix(grok-local): stop defaulting --permission-mode to dontAsk (#11898) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The `grok_local` adapter runs the native Grok Build CLI in headless mode for unattended agent heartbeats > - Grok CLI 1.0 started to enforce the `dontAsk` permission mode as deny-by-default, and it takes precedence over `--always-approve` > - The adapter passes both flags on every run, so each run dies on its first tool call and is still recorded as a success > - This pull request removes the `dontAsk` default so unattended runs rely on `--always-approve` alone > - The benefit is that `grok_local` agents can execute tools again on current Grok CLI releases ## Linked Issues or Issue Description No public issue exists. Description per the bug template: **What happened?** Every `grok_local` run on Grok CLI 1.0.x stops on its first tool call. The stream shows the tool call move from `pending` to `failed` with "User cancelled the execution for tool `run_terminal_command`", and the session ends with `stopReason: "cancelled"` after one turn. The CLI exits 0, so Paperclip records the run as succeeded with no work done, and the issue lands in missing-disposition recovery. **Expected behavior** Unattended runs must auto-approve tool executions. The adapter already passes `--always-approve` for this. **Steps to reproduce** In a clean Linux environment with Grok CLI 1.0.3 and `XAI_API_KEY` set, run the adapter's exact invocation shape: `grok --output-format streaming-json --permission-mode dontAsk --always-approve --disable-web-search --single "Run the shell command: echo ok"` The tool call is denied. Drop `--permission-mode dontAsk` (or use `--permission-mode bypassPermissions`) and the same command executes the tool. On Grok 0.2.x the original combination worked because the CLI accepted `dontAsk` without enforcing it; the 0.2.39 embedded docs state the flag takes effect only for `bypassPermissions` / always-approve. **Paperclip version or commit** master (917d2350f) ## What Changed - `packages/adapters/grok-local/src/server/execute.ts`: `permissionMode` no longer defaults to `dontAsk`. The adapter passes no `--permission-mode` flag unless one is explicitly configured. `--always-approve` (default on) remains the unattended policy. - `packages/adapters/grok-local/src/index.ts`: config doc updated to explain the new default and the Grok 1.0 semantics. - `packages/adapters/grok-local/src/server/execute.test.ts`: default-args assertion now requires the absence of `--permission-mode`; new test covers explicit `permissionMode` pass-through. ## Verification - `npx vitest run packages/adapters/grok-local` — 7 files, 29 tests, all pass. - `pnpm --filter @paperclipai/adapter-grok-local typecheck` — clean. - Live matrix against Grok CLI 1.0.3 in a clean sandbox: `dontAsk --always-approve` denies the first tool call; `--always-approve` alone executes it; `bypassPermissions --always-approve` executes it; `dontAsk` alone denies it. ## Risks - Low risk. Operators who explicitly set `permissionMode` keep their value verbatim. Only the implicit default changes, and the old default is what breaks every run on current Grok CLI releases. - On Grok 0.2.x the flag was unenforced, so omitting it does not change behavior there. ## Model Used Claude Fable 5 (`claude-fable-5`), extended thinking, tool use, via Claude Code CLI. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-21 14:50:43 -07:00
Devin Foley	adfbe2d4b9	feat(environments): refer to the managed default environment by name, not the sandbox driver key (#11838) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Managed deployments provision a platform-managed default environment for agent runs; the UI shows this environment in selectors, the agent form, run details, and the environments page > - Those surfaces append the raw driver key to the environment name, so users see labels like "Paperclip Computer (sandbox)", "Paperclip Computer · sandbox", and fallback copy such as "Managed sandbox" and "The sandbox has no ready authentication" > - "sandbox" is infrastructure vocabulary, not the product name of the environment; showing it next to the managed environment's name is confusing and off-brand > - This pull request renders platform-managed environments by name alone and rewords the sandbox-phrased copy, while user-created environments keep the driver suffix so mixed lists stay distinguishable > - The benefit is that the default environment reads as one clear product name everywhere, and self-hosted users lose nothing: their own environments still show the driver ## Linked Issues or Issue Description **What existing behavior does this improve?** Display of the platform-managed default environment across the UI. **Subsystem affected** UI (environment selectors, agent config form, environments page, agents page, run details) and the claude-local/codex-local adapter auth checks. **Current behavior** The agent form labels the inherited default environment as "Name (sandbox)". Environment selectors and the environments list render "Name · sandbox". The agents page describes the environment as "<provider> sandbox provider". The agent form's fallback label is "Managed sandbox". Adapter auth checks say "The sandbox has no ready authentication for this adapter." **Proposed behavior** Platform-managed environment rows (`metadata.managedByPaperclip`) render their name alone. The fallback label is "Paperclip Computer". The agents page describes managed environments as "Managed by Paperclip". Run details omit the driver suffix for sandbox-driver environments (the adjacent Provider entry already identifies the mechanism). Adapter auth checks say "This environment has no ready authentication for this adapter." **Reason and benefit** The managed environment carries a product name. Appending the raw driver key ("sandbox") to it is noise and contradicts the product naming. User-created environments keep the driver suffix, so mixed lists stay distinguishable. **Breaking changes** None. Message text of the auth check is not read programmatically; the UI keys off `ADAPTER_AUTH_MISSING_CHECK_CODE`. Rows without the managed marker render exactly as before. ## What Changed - New `environmentDisplayLabel` helper in `ui/src/lib/managed-sandbox-environment.ts`: managed rows → name alone; other rows → "Name · driver". - `AgentConfigForm`: inherited-default label uses the helper; fallback copy "Managed sandbox" → "Paperclip Computer"; environment options use the helper. - `ProjectProperties`, `CompanyEnvironments`: environment selector options use the helper; the environments-list row hides the driver suffix on managed rows; the managed detail page's fallback description no longer says "sandbox". - `Agents` page: managed environments are described as "Managed by Paperclip" instead of "<provider> sandbox provider". - `CommentThread` run details: the driver suffix is omitted for sandbox-driver environments. - claude-local and codex-local adapters: auth-missing check message/hint reworded from "sandbox" to "environment" (ACP and environment-test paths); claude-local probe/effort/login hints reworded the same way. - Run status lines: "Syncing workspace to sandbox", "Exporting git changes from sandbox", "Starting adapter in sandbox", and friends now say "environment"; "Finalizing sandbox workspace" → "Finalizing workspace". Templated transfer-progress lines map the `sandbox` transport key to "environment" for display (`runtime-progress.ts`). - Agent form sign-in panel: "Sign in to the sandbox" → "Sign in to the environment"; "Authenticated. The sandbox has credentials now." → "…The environment has credentials now." - Feature catalog + instance settings card: "Managed Sandbox Only" → "Managed Environment Only" (setting key unchanged; the card keeps its alphabetical slot). - Server agents routes: execution-target failure and test-identity copy no longer say "sandbox"; workspace-mode label "Cloud sandbox" → "Cloud environment". - Tests: new `environmentDisplayLabel` unit cases; new `AgentConfigForm` render case asserting the managed default renders without "(sandbox)" or "· sandbox"; status-line assertions updated across adapter-utils, server heartbeat/live-run, and UI chat suites. ## Verification - `pnpm --filter @paperclipai/ui typecheck` — clean. - `pnpm --filter @paperclipai/adapter-claude-local typecheck` and `--filter @paperclipai/adapter-codex-local typecheck` — clean. - `vitest run` for `managed-sandbox-environment.test.ts`, `AgentConfigForm.render.test.tsx`, `CompanyEnvironments.test.tsx`, `Agents.test.tsx`, `CommentThread.test.tsx`, `NewAgent.test.tsx` — all green (118 tests across the two runs). ## Risks Low risk. Cosmetic label changes only; no data or API changes. Rows without `metadata.managedByPaperclip` render exactly as before, so self-hosted deployments with their own environments see no change. The only self-hosted-visible wording changes are the adapter auth-check message and the driver suffix omission on sandbox-driver rows in run details. ## Model Used - Claude (Anthropic) — claude-fable-5 (Claude Fable 5), Claude Code CLI, extended thinking, tool use. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes (no docs reference these labels) - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-21 12:51:22 -07:00
Devin Foley	599ad7016c	ci(release): raise npm publish visibility budget to 10 minutes per package (#11835) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The release workflow publishes every public package to npm and polls each version's registry visibility before continuing > - #11834 raised the poll budget from 60 seconds to 5 minutes after npm CDN propagation lag failed four canary runs > - The very next canary run missed by ten seconds: `adapter-opencode-local@2026.821.0-canary.2` was accepted at 07:02:27 UTC and became visible at 07:07:40, just past the final poll > - This pull request doubles the per-package budget to 10 minutes > - The benefit is a release train that survives the one consistently slow package; the 90-minute publish job timeout from #11834 already absorbs it ## Linked Issues or Issue Description Follow-up to #11834. Evidence in the `Release` run for `16149a75f`: every package's publish became visible within seconds except `adapter-opencode-local`, which has lagged 3-5+ minutes on all of today's runs and exceeded the 5-minute budget by ten seconds on the latest. ## What Changed - `NPM_PUBLISH_VERIFY_ATTEMPTS` 30 → 60 (with `NPM_PUBLISH_VERIFY_DELAY_SECONDS: "10"`, a 10-minute per-package budget), plus the comment documenting the observed near-miss. ## Verification - Same env-override plumbing verified in #11834; only the numeric budget changes. The next master push (this merge) exercises the canary path. ## Risks - Low risk: a genuinely failed publish reports in up to 10 minutes; healthy publishes exit the poll on first visibility. ## Model Used Claude Fable 5 (Anthropic, `claude-fable-5`) with extended thinking and agentic tool use via the Claude Code CLI. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable (not applicable: numeric workflow env tuning) - [x] I have updated relevant documentation to reflect my changes (workflow comment updated) - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-21 00:18:46 -07:00
Devin Foley	16149a75fd	ci(release): give npm publish visibility polling a 10-minute budget (#11834) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The release workflow publishes every public package to npm per master push (canary) and per promotion channel > - `release.sh` polls the registry after each publish and aborts the whole release when a version is not visible within 60 seconds > - npm accepts publishes immediately, but its CDN can lag packument propagation by several minutes; on 2026-08-21 this failed four consecutive canary runs mid-loop even though every publish succeeded > - This pull request sets the script's existing visibility-budget env overrides at the workflow level to 10 minutes > - The benefit is a release train that tolerates registry propagation lag; a healthy publish still exits the poll on its first visible check ## Linked Issues or Issue Description Not applicable for a `ci:` workflow tuning change. Evidence: four consecutive `Release` runs on master failed in `publish_canary` with "npm did not publish and expose <package>@<version>", while the raw registry packument shows each of those versions present minutes later (`2026.821.0-canary.0` accepted 01:36 UTC, visible 01:40; `2026.821.0-canary.1` accepted 05:54, visible 05:57). ## What Changed - Set `NPM_PUBLISH_VERIFY_ATTEMPTS: "30"` and `NPM_PUBLISH_VERIFY_DELAY_SECONDS: "10"` in the `Release` workflow's top-level `env`, raising `release.sh`'s post-publish visibility poll from 60 seconds to 5 minutes per package for every channel. Both variables are existing overrides read by the script (`scripts/release.sh` lines 311-312); no script change. - Raised the four publish jobs' `timeout-minutes` from 45 to 90 so several laggard packages fit inside the job without exhausting it before the tag push / Docker / release steps. ## Verification - `release.sh` reads the two env overrides with defaults (`${NPM_PUBLISH_VERIFY_ATTEMPTS:-12}` / `${NPM_PUBLISH_VERIFY_DELAY_SECONDS:-5}`), so workflow-level env reaches `publish_package_to_npm_and_wait` unchanged. - Not run: a live release (needs the npm-canary environment). The next master push exercises the canary path with the new budget. ## Risks - Low risk: a genuinely failed publish now takes up to 5 minutes to report instead of 1, and a pathological batch where most packages lag the full budget still fails inside the 90-minute job — that pattern means a real registry incident. The poll exits early on success, so healthy releases are unaffected. ## Model Used Claude Fable 5 (Anthropic, `claude-fable-5`) with extended thinking and agentic tool use via the Claude Code CLI (release log forensics against raw registry packument timestamps). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable (not applicable: workflow env tuning) - [x] I have updated relevant documentation to reflect my changes (comment in the workflow documents the budget rationale) - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-20 23:21:43 -07:00
Devin Foley	db4defdfbf	feat: operator-configurable settings visibility via PAPERCLIP_HIDDEN_SETTINGS (#11823) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The instance settings surface (Access, Plugins, Adapters, General, Experimental) assumes the person at the keyboard operates the whole instance > - Operators who host Paperclip for others — a managed cloud or an internal shared server — expose settings pages and toggles that do not apply to their deployment, and the related mutation APIs stay open > - A hosted tenant can open Plugins or Adapters, try an action, and hit a confusing failure, because only a few hardcoded platform floors exist > - This pull request adds a generic, operator-configured visibility mechanism: one env var hides declared settings surfaces in the UI and floors their mutation routes with a stable 403 code > - The benefit is a clean hosted-tenant settings surface for any operator, with zero behavior change for normal self-hosted instances ## Linked Issues or Issue Description **Subsystem affected** Instance settings (server routes and UI), the shared settings registry in `packages/shared`, and the `/api/health` bootstrap payload. **Problem or motivation** An operator who hosts Paperclip for other people cannot hide settings surfaces that the platform manages. Tenants see Access, Plugins, and Adapters pages, backup retention, and host-level experimental toggles that do nothing useful for them. The mutation APIs behind these surfaces also stay open, so a tenant admin can attempt actions the platform must control. ROADMAP.md names a cleaner shared deployment story as a goal ("Teams should be able to run the same product in hosted or semi-hosted environments without changing the mental model"). **Proposed solution** Add a declarative registry of hideable settings surfaces and one env var, `PAPERCLIP_HIDDEN_SETTINGS`. The server parses the list at boot, reports it on `/api/health`, and rejects value-changing writes to hidden surfaces with a stable `settings_operator_managed` 403 code. The UI reads the list from the health payload and removes the hidden pages, sections, and toggles from navigation, routes, and page content. Unknown keys warn and are ignored, so one list can roll across a fleet with mixed app versions. With the variable unset, behavior is byte-identical to today. **Alternatives considered** - Hardcode the hidden set for cloud instances in this repo: rejected, because each hosting operator needs a different policy, and policy does not belong in shared code. - Deliver the hidden set through the managed-config document: rejected, because that channel is cloud-specific and fail-closed on unknown fields; a plain env var works for any operator, including self-hosted shared servers. - Lock the controls with a badge instead of hiding them: rejected for these surfaces, because they are meaningless to tenants, not merely platform-controlled; the existing managed-overlay lock stays the right tool for controlled flags. **Roadmap alignment** Supports the "shared deployment story" item in ROADMAP.md: hosted and semi-hosted deployments keep the same product with a settings surface that matches what the tenant can actually do. ## What Changed - New `packages/shared/src/settings-visibility.ts`: registry of hideable surfaces (every instance settings page — profile, environments, access, heartbeats, experimental, plugins, adapters; every Instance → General section; every experimental flag as `instance.experimental.<key>`), the `PAPERCLIP_HIDDEN_SETTINGS` parser, and the `settings_operator_managed` error code. The General page stays visible as the settings root and redirect target. - New `server/src/services/settings-visibility.ts`: parse-once accessor; unknown keys log one warning and are ignored. - `/api/health` reports `hiddenSettings` on every response shape; the field is omitted when nothing is hidden. - Server floors on hidden surfaces, with same-value echo tolerance (the `executionMode` precedent): field-backed general sections and experimental keys reject value-changing PATCHes, and hiding the whole Experimental page floors every toggle; plugin lifecycle and config writes, adapter management writes, and the Access admin routes (reads included) return 403 `settings_operator_managed`. Reads the app itself needs (plugin `ui-contributions`, adapter metadata, plugin job trigger) stay open. Pages without instance-scoped mutation routes are hidden in the UI only. - UI: new `useHiddenSettings` hook and `HiddenSettingsPageGate` route gate (hidden pages redirect to the settings root); the settings sidebar and tab bar drop hidden entries; remembered settings paths remap to the default page; `InstanceGeneralSettings` skips hidden sections; every `ExperimentalToggleCard` now carries its flag key and renders nothing when hidden. - Removed the dead `InstanceSidebar` component (referenced only by its own test). - Docs: `docs/deploy/environment-variables.md` documents the variable and the key registry. ## Verification - `pnpm vitest run` over the new and extended suites: shared registry and parser, representative floor tests per route class (changed-value 403, same-value echo 200, unset env 200, page-level Experimental hiding), the health field, the route gate, nav filtering, and section/card hiding with one hidden example per surface kind — 168 tests pass. - Full root `pnpm typecheck` passes. - Manual: booted a server with the variable set. `/api/health` lists the keys; an unknown key logs one warning and the server boots; hidden pages redirect; hidden sections and cards do not render; hidden-field PATCH returns 403 with `details.code = "settings_operator_managed"`; a same-value echo returns 200. Unset the variable: the full settings surface returns and responses are byte-identical to master. ## Risks - Low risk for self-hosted instances: with the variable unset, the hidden set is empty, the health field is omitted, and no floor activates. - Flooring plugin config writes assumes hosted deployments configure plugins through the platform. If a future bundled plugin needs tenant-entered config, the floor needs a narrow carve-out. - Hidden-key floors tolerate same-value echoes, so API clients that round-trip full GET responses keep working. - Hiding a toggle does not change its value; operators pair hiding with the desired default where the value matters. ## Model Used Claude Fable 5 (Anthropic, `claude-fable-5`) with extended thinking and agentic tool use, driven through the Claude Code CLI (file edits, test execution, and live-server verification loops). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-20 17:54:44 -07:00
Devin Foley	de9645ab73	fix(ui): surface live runtime status in the task-chat tail before the first transcript token (#11802) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Runs on sandbox execution targets spend their first minutes in preparation phases — config seed, workspace and skills sync into the sandbox — before the agent CLI produces its first transcript token > - The engine already reports these phases through the runtime-progress mechanism (`onRuntimeProgress` → `recordCurrentHeartbeatRunRuntimeProgress` → `currentStatusMessage` on the live run), and the pre-task-chat issue view surfaced them in its live status line > - The chat-style task view's live tail dropped that affordance: with zero renderable transcript entries it shows an opaque "Waiting for transcript..." for minutes, which reads as a hang (and prompted a real is-this-broken investigation on a healthy run) > - This pull request surfaces the live run's `currentStatusMessage` as the tail's empty-state message, with the generic wait text as fallback > - The benefit is that operators watching a sandbox run see "Syncing workspace to sandbox" instead of wondering whether the run is stuck — for every adapter, with no adapter identities involved ## Linked Issues or Issue Description **What existing behavior does this improve?** The chat-style task view's live transcript tail (`TaskChatThread` → `TaskChatLiveTail`), introduced with the experimental chat-style task view. **Current behavior** While a live run has no renderable transcript entries yet — the normal state for the multi-minute sandbox preparation window — the tail shows a static "Waiting for transcript...". The run's live `currentStatusMessage` (e.g. "Syncing workspace to sandbox", emitted by the sandbox-managed runtime's progress reporting) is available on the same live-run object but unused by this surface, although the earlier issue-chat view did display it. **Proposed behavior** When the tail is streaming a live run and no transcript rows exist yet, the empty-state message prefers the run's `currentStatusMessage`; the generic wait text remains the fallback when no runtime status has been reported (e.g. local runs that produce output immediately, or the brief pre-status window). **Reason and benefit** The preparation phases are real, reportable progress that the engine already emits. Showing them turns a minutes-long apparent hang into a legible status, for every adapter and execution target, using data the view already receives. ## What Changed - `ui/src/components/TaskChatThread.tsx`: the live tail's `emptyMessage` prefers `liveRun.currentStatusMessage` (guarded to the run the tail is actually streaming) over the static "Waiting for transcript..." fallback. Queued runs keep "Waiting to start...". - `ui/src/components/TaskChatThread.test.tsx`: a test covering both branches — a live run with a runtime status shows it (and not the wait text), and a run without one keeps the generic message. ## Verification - `vitest run ui/src/components/TaskChatThread.test.tsx ui/src/components/task-chat/TaskChatLiveTail.test.tsx`: 22/22 pass (including the new test) - `pnpm --filter @paperclipai/ui typecheck`: clean - Reproduced live: a `claude_local` run on a Daytona sandbox environment showed "Waiting for transcript..." for the full sync window; with this change the same window shows the streamed preparation statuses ## Risks - Low: a one-expression change to an empty-state string, active only while a live run has produced no renderable transcript rows. The fallback path is byte-identical to today. - `currentStatusMessage` is truncated/humanized upstream by the runtime-progress reporter; this surface renders it verbatim in the same muted style as the wait text. ## Model Used - Anthropic, **Claude Fable 5** (`claude-fable-5`) via Claude Code, with repository, shell, and Git tooling. It traced the runtime-progress mechanism end-to-end (engine emitter → heartbeat recorder → live-run API → both thread views), identified the dropped affordance in the chat-style view, and wrote the fix and test. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-20 12:47:20 -07:00
Devin Foley	933749e01f	test(server): deflake postgres teardown and pinned exposure port (#11667) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The server test suite gates every merge and every release cut. > - Three server tests each failed exactly once on markdown-only or unrelated diffs, then passed on rerun. > - One of the three (the git-operation-scheduler owner/joiner race) was fixed on master independently by [#11671](https://github.com/paperclipai/paperclip/pull/11671) while this PR was open, so after rebasing this pull request carries the remaining two. > - A flaky gate makes release operators rerun CI and stop trusting red results. > - Each remaining flake has a real nondeterminism: a teardown race and a hard-coded host port. > - This pull request removes the nondeterminism from the two tests without weakening what they prove. > - The benefit is a test gate that fails only when the product is broken. ## Linked Issues or Issue Description - [x] I searched open and closed issues and pull requests for these test files and for these failures. I found no duplicate report or fix. **What happened?** Three one-off CI failures occurred during release operations, each on a diff that could not have caused it, and each passed on rerun: 1. Run [32086355930](https://github.com/paperclipai/paperclip/actions/runs/32086355930): `server/src/__tests__/interaction-resolution-cross-issue-cap-postgres.test.ts` — all 7 tests passed, but vitest recorded an Unhandled Error and failed the run: `TypeError: Cannot read properties of null (reading 'write')` at `postgres@3.4.9/src/connection.js:255 Immediate.nextWrite`. 2. Run [32096743814](https://github.com/paperclipai/paperclip/actions/runs/32096743814): `server/src/services/workspace-git-operation-scheduler.test.ts` — the test "coalesces the same canonical key and cleans single-flight state after success and failure" failed with an AssertionError: the two concurrent calls came back with the `singleFlightJoined` values swapped. *(Fixed on master by [#11671](https://github.com/paperclipai/paperclip/pull/11671) with an equivalent single-flight barrier while this PR was open; the fix was dropped from this PR on rebase and the file is no longer touched here.)* 3. Run [32196201529](https://github.com/paperclipai/paperclip/actions/runs/32196201529): `server/src/services/workspace-runtime-exposure.test.ts` — the test "keeps an existing runtime port that is already inside the dedicated range" failed once out of 610 recorded runs because the runtime came back on a relocated port instead of the pinned 42500. **Expected behavior** The tests pass on every run when the code under test is correct. A red result means a product defect, not scheduling luck on the CI host. **Steps to reproduce** Each flake is a low-probability race, but both remaining mechanisms reproduce deterministically: 1. Postgres teardown: the suite never ends the postgres.js pool behind `createDb`; `afterAll` only stops the embedded server. postgres.js batches small writes and flushes them with `setImmediate` (`connection.js` `nextWrite`), and `close()` nulls the socket. Stop the server while the pool is open and a pending flush can run after the socket is gone. 2. Exposure pinned port: hold any loopback socket on 42500 or 52500 (both are inside the default Linux ephemeral port range, 32768–60999) and run the test. The allocator correctly relocates, and the assertion fails with `expected 42000 to be 42500`. The client side of any loopback connection on the CI host can land on those ports. **Paperclip version or commit** Branched from `master` at `4b968d8c0`; rebased onto `5a1ce7aed`. **Privacy checklist** I reviewed this description and removed private instance URLs, internal task identifiers, credentials, and user paths. ## What Changed Both fixes are test-side. I found no product race. - `interaction-resolution-cross-issue-cap-postgres.test.ts`: `afterAll` now ends the drizzle/postgres.js pool (`db.$client.end()`) before it stops the embedded Postgres server. `end()` waits for in-flight queries, including a fire-and-forget wake that lands just after a response, and closes the sockets from the client side first. Sibling suites (for example `heartbeat-plugin-environment.test.ts`) already use this order; this suite had skipped the pool shutdown. - `workspace-runtime-exposure.test.ts`: the pinned-port test no longer hard-codes 42500. It scans the dedicated range with the suite's real loopback probe, finds the lowest free app/HMR pair, then pins the next free pair strictly above it. If the keep-preferred-port path broke, the ascending fallback scan would return the lower pair, so the assertion keeps its discriminating power while no longer betting on one fixed host port staying free. - *(Dropped on rebase: the `workspace-git-operation-scheduler.test.ts` coalescing fix, superseded by the equivalent barrier merged in [#11671](https://github.com/paperclipai/paperclip/pull/11671).)* ## Verification - Reproduced the exposure flake exactly: with a listener held on `127.0.0.1:52500`, the pre-fix test fails with `expected 42000 to be 42500`; the fixed test passes with the port still held. - The postgres flake is a probabilistic teardown race and I could not trigger it on demand. The mechanism is established from `postgres@3.4.9` source (`setImmediate`-batched `nextWrite` versus `close()` nulling the socket) and the fix removes the whole class by closing the pool before the server. - Repeat runs after the fix: the pinned-port exposure test 20/20 green while the Postgres suite looped concurrently for loopback churn; `interaction-resolution-cross-issue-cap-postgres.test.ts` 15/15 green with no unhandled errors. - Re-verified after rebasing onto `5a1ce7aed`: both changed test files pass and `tsc --noEmit` passes in `server/`. - Environment note: three unrelated tests in `workspace-runtime-exposure.test.ts` (the wildcard-bind diagnosis tests) fail on macOS before and after this change because they read `/proc`; they are untouched and pass on Linux CI. ## Risks - Low risk: both changes are test-only; no product code changed. - The pinned-port test keeps a tiny time-of-check/time-of-use window between its own probe and the runtime's bind. The window shrinks from "one fixed port must stay free across the whole CI fleet" to milliseconds on a pair just verified free. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used Claude Fable 5 (Claude Code) — model ID `claude-fable-5`, with repository tools and local code execution for reproduction and repeat-run verification. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-20 11:27:39 -07:00
Devin FoleyandHawik	1d0e826767	feat(acpx/ui): adapter-declared capabilities for verbose streaming backends (no behavior change by default) (#11761) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Local agent adapters stream their work through the shared acpx engine, which every ACP adapter (`claude_local`, `codex_local`, `gemini_local`, custom ACP) runs on > - Verbose streaming backends break two shared-engine behaviors: the auto-posted run summary concatenates every text delta including the thought stream (a long multi-tool run once auto-posted a ~50k character monologue as an issue comment), and token-by-token tool-argument streaming floods the run log with tens of thousands of placeholder-titled in-progress events per run > - These fixes were developed inside the `kimi_local` adapter PR, where Kimi Code's streaming volume (~16,000 text deltas per run vs ~290 for a comparable Claude run) surfaced both problems > - Changing this behavior for all adapters at once is a fleet-wide risk, and hardcoding adapter identities in shared code does not scale to many adapters (or work at all for externally-shipped plugin adapters) — so the behaviors become invocation-config parameters that an adapter's own acpx config builder sets, with defaults preserving today's behavior byte-for-byte > - The benefit is that the machinery lands fully tested with zero behavior change for existing adapters — pin tests prove it — the engine carries no adapter identities, and any adapter (including `custom_acp` configs for external backends) opts in declaratively ## Linked Issues or Issue Description - Refs #9967 — extracted from the `kimi_local` adapter PR and restructured to be inert by default; the commit preserves the original author's (@hawikk) authorship. **Current behavior** When an acpx-engine run ends without the agent leaving a comment, the auto-posted summary is every streamed text delta concatenated, thought stream included. Backends that stream tool arguments emit tens of thousands of placeholder-titled `in_progress` tool events into the stored run log, pinning the live activity indicator to a generic "tool call". There is no mechanism for an adapter to vary either behavior, and shared code must never branch on adapter identities. **Proposed behavior** Two engine invocation-config parameters, read with behavior-preserving defaults: `summaryStrategy` (`"full"` = existing concatenation, the default; `"lastOutputSegment"` = segment output at tool starts, exclude thought stream, post the last non-empty segment) and `coalescePlaceholderToolUpdates` (`false` = never drop an event, the default; `true` = coalesce placeholder-titled in-progress updates). An adapter opts in from its own acpx config builder — the engine has no per-adapter knowledge, no adapter identity appears anywhere in shared code, and `custom_acp` agent configs can set the same knobs for external verbose backends. **Reason and benefit** Existing adapters are provably unaffected — new pin tests assert the default path's summary and tool-event output byte-for-byte, so any future change that alters behavior for claude/codex/gemini/custom fails the suite. The verbose-backend handling still lands fully tested, activated declaratively by the adapter that needs it (the `kimi_local` adapter PR sets both knobs in its config builder). ## What Changed - `packages/adapter-utils/src/acpx-engine/execute.ts`: the run preparation parses `summaryStrategy` and `coalescePlaceholderToolUpdates` from the invocation config (validated, defaulted); summary accumulation and `emitRuntimeEvent` branch on the prepared values. The default path is the pre-existing code (`textParts.join("")`, no event filtering). `buildAcpxRunSummary` is the exported last-segment strategy. - `packages/adapter-utils/src/acpx-engine/execute.test.ts`: a pin test asserting the default path's exact summary (thought stream included) and full tool-event stream (placeholder-titled in-progress updates present, names restored); opt-in tests for each knob; a `buildAcpxRunSummary` unit test. - `ui/src/adapters/types.ts`: `UIAdapterModule` gains an optional `transcriptPresentation` capability — `maxVisibleEntries` (issue-chat transcript window, default 30) and `liveReasoningView` (`"ticker"` default; `"scrollLog"` renders live reasoning in a scrollable auto-following box with one entry per tool call). - `ui/src/lib/issue-chat-messages.ts` and `ui/src/components/IssueChatThread.tsx`: shared code resolves the hints via `findUIAdapter(adapterType)` with today's defaults as fallback — no adapter identities anywhere. The `scrollLog` rendering component ships here but is unreachable until an adapter declares it. - `ui/src/lib/issue-chat-messages.test.ts`: a capability test registers a synthetic verbose adapter and asserts the wider window; the pre-existing test keeps pinning the default 30-entry window. No adapter declares any of this in this PR — every adapter renders and summarizes exactly as before, and there is no per-adapter data anywhere. The `kimi_local` adapter PR (#9967, stacked on this branch) is the first consumer: it declares `transcriptPresentation` in its own UI module and sets the engine knobs in its own acpx config builder. ## Verification - Engine suite: 130/130 pass (126 existing + 4 new); chat suites (`issue-chat-messages`, `IssueChatThread`, `RunChatSurface`): all pass including the new synthetic-adapter capability test — 237 tests across the touched surfaces - The pin tests are the regression guard: the engine test encodes today's summary text and tool-event sequence for a default-config run, and the existing 30-entry-window test pins the default transcript window, so "nothing changed for Claude/Codex users" is an executable assertion, not a review judgment - `pnpm --filter @paperclipai/adapter-utils --filter @paperclipai/ui typecheck`: clean ## Risks - Low: with no adapter setting the knobs, every code path taken in production is the existing one. The only behavioral surface is additive (an unused strategy and an unused filter), exercised by tests. - The knobs are ordinary invocation-config keys, so a `custom_acp` agent config can also set them — intended: an external verbose backend gets the same handling without code changes. Both knobs only affect that agent's own run summaries and run-log verbosity. ## Model Used - Original implementation authored in #9967 by @hawikk (models documented there: Moonshot AI Kimi K3 Coding via Kimi Code CLI 0.27.0, OpenAI GPT-5 Codex, Anthropic Claude Opus 4.8). The commit preserves that authorship. - Extraction, restructuring into config-declared parameters, pin tests, and verification: Anthropic, **Claude Fable 5** (`claude-fable-5`) via Claude Code, with repository, shell, and Git tooling. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Hawik <davapa@gmail.com>	2026-08-20 10:37:58 -07:00
Devin Foley	b5a3a863c3	feat(release): bootstrap new npm packages with a placeholder publish (#11757) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Its release pipeline publishes a set of npm packages from CI with npm trusted publishing (GitHub OIDC), gated by `scripts/release-package-manifest.json` > - A brand-new package name cannot be published by CI directly: the PR bootstrap gate requires the name to resolve on npm, and a trusted-publisher rule can only be configured after the package page exists > - The current bootstrap helper closes that gap by building the package locally and publishing its real output from a maintainer machine — before the PR that adds the package has passed CI or review > - This pull request replaces that flow: the helper now publishes a minimal deprecated placeholder at version `0.0.0` that only reserves the name, so every real version ships from CI > - The benefit is that unreviewed build output never reaches npm, and the bootstrap runs from any checkout (including `master`, before the new package's PR merges) with no local build ## Linked Issues or Issue Description **What existing behavior does this improve?** The one-time npm bootstrap for a brand-new release package (`pnpm run release:bootstrap-package`). **Current behavior** The helper builds the target package locally and publishes the real build output from a maintainer machine. That content has not passed repository CI or review at publish time. The helper also requires the new package to exist in the local workspace, so it must run from the (unmerged) PR branch that adds the package. **Proposed behavior** The helper publishes a three-file placeholder at version `0.0.0` (manifest, README, and an `index.js` that throws a descriptive error), waits for the registry to show the package, then deprecates it. The PR bootstrap gate (`scripts/check-release-package-bootstrap.mjs`) only requires the name to resolve on the registry, so the placeholder satisfies it. The first real calver release from CI supersedes the placeholder, and a stable release moves `latest` off it — the same `latest` window that existed under the old flow, but containing an explicit inert stub instead of unreviewed code. **Reason and benefit** Real package content only ever reaches npm from CI, after review and merge. The bootstrap becomes safer (scope guard refuses names outside `@paperclipai/`, already-published names are rejected) and simpler (no local build, no workspace state, runs from any checkout). **Breaking changes** None at runtime. The helper's CLI surface changes: it now takes a package name only (no directory selector) and drops `--skip-build`. `doc/PUBLISHING.md` is updated to match. ## What Changed - `scripts/bootstrap-npm-package.mjs`: replaced the build-and-publish flow with a placeholder publish — stages `package.json` + `README.md` + throwing `index.js` at version `0.0.0` in a temp directory, previews with `npm publish --dry-run`, and publishes only with `--publish`. One-time passwords are prompted interactively (never passed as arguments, since they are single-use and would land in shell history), with re-prompt on a rejected or expired code. After publishing, the helper polls the registry until the package is visible (a first publish can lag by minutes; verified live at ~5 minutes), requiring two consecutive sightings before prompting for a second code and deprecating the placeholder so accidental installs warn loudly; on timeout or failure it prints the exact manual `npm deprecate` command. Added an `@paperclipai/`-scope guard and a fail-fast error when `--publish` runs without an interactive terminal. Removed the workspace-plan dependency so it runs from any checkout. - `scripts/bootstrap-npm-package.test.mjs`: rewrote for the new interface — argument parsing, scope validation, the generated placeholder files (manifest shape, throwing entry point, README), the OTP re-prompt loop, and the registry poll (consecutive-sighting requirement, timeout, transient-error tolerance) via injected fakes. - `doc/PUBLISHING.md`: rewrote the "One-time bootstrap sequence for a new package" section for the placeholder flow, including the `latest` dist-tag window and the trusted-publishing setup ordering (placeholder publish → trusted publisher rule → `"publishFromCi": true`). - `.github/scripts/check-pr-release-bootstrap.mjs` (+ test, + wiring in `run-quality-gates.mjs`): new informational commitperclip notice on PRs that need this bootstrap. It fires when the PR newly release-enables a package that is missing from npm, or adds an unpublished `publishFromCi: false` package that published packages declare a `workspace:*` dependency on, and names the exact maintainer command — so contributors know the red `policy` check is not theirs to fix. It never fails the gate (the `policy` job remains the enforcer), only looks up scope-validated names on the registry, and stays quiet on registry errors. ## Verification - `node --test scripts/bootstrap-npm-package.test.mjs`: 13/13 pass - `node --test .github/scripts/tests/*.test.mjs`: 147/147 pass (10 new for the PR notice) - `pnpm run test:release-registry`: 82/82 pass - Replayed the new PR notice against a real historical PR's live API data (files, manifest at base and head refs): with the registry in its pre-bootstrap state it produces the exact maintainer instruction; with the package bootstrapped it stays silent - Full live end-to-end run: the flow bootstrapped `@paperclipai/adapter-kimi-local` for real — dry-run preview (634-byte, 3-file tarball), publish, registry visibility after ~5 minutes of propagation lag, deprecation confirmed via `npm view ... deprecated` - Guards verified live: an already-published name is rejected, an out-of-scope name (`left-pad`) is rejected, unknown options (including the removed `--otp`) are rejected, and `--publish` in a non-interactive shell fails fast before any network call ## Risks - The `latest` dist-tag points at the deprecated `0.0.0` placeholder until the first stable release supersedes it. This window also existed under the old flow (which parked `latest` at a locally built version); internal consumers are unaffected because release version rewrites pin exact calver versions. - The registry poll caps at ~10 minutes. If propagation is slower than that, the helper prints the exact `npm deprecate ... --otp <code>` command to run manually once `npm view` resolves. - The helper no longer validates the name against the workspace release plan, so a typo within the `@paperclipai/` scope would reserve a wrong name. The dry-run preview shows the exact name before any publish. ## Model Used - Anthropic, **Claude Fable 5** (`claude-fable-5`) via Claude Code, with repository, shell, and Git tooling. It analyzed the existing bootstrap flow and the release scripts (`release-package-map.mjs`, `check-release-package-bootstrap.mjs`, `release.sh` dist-tag handling), wrote the replacement script and tests, updated the documentation, and ran the verification above. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-19 19:38:17 -07:00
Devin Foley	927ef58d04	docs(skills): changelog entries describe deltas, not repeats (#11663) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Stable release notes are drafted per release from the commit range since the previous stable > - Features evolve across consecutive releases, so a correct range still produces entries that re-describe what the previous notes already introduced > - The first channel-train draft did exactly that for four themes, and review caught it against the published previous changelog > - This pull request adds the missing framing rule to the changelog skill and mirrors it in the Discord skill > - The benefit is that consecutive releases read as a progression instead of repeating themselves ## Linked Issues or Issue Description **What existing behavior does this improve?** The authoring guidance in `.agents/skills/release-changelog/SKILL.md` and `.agents/skills/release-changelog-discord-message/SKILL.md`. **Current behavior** The skills define the range and the sections but say nothing about features the previous stable's notes already introduced. A draft for a follow-up release naturally re-describes them as if they debuted (observed in the v2026.821.0 draft: the chat conversation view, sandbox output streaming, the raised import cap, and the channel system — all already announced in v2026.817.0's notes). **Proposed behavior** The changelog skill instructs the author to read the previous stable's notes first and phrase already-introduced features as deltas ("last release introduced X; this release makes it the default"), demoting follow-through themes out of Highlights. The Discord skill's highlight guidance mirrors the rule. **Reason and benefit** Consecutive changelogs read as a progression; readers of both releases never see the same debut twice. ## What Changed - `.agents/skills/release-changelog/SKILL.md`: a "describe deltas, not repeats" guideline in Step 4, with the read-the-previous-notes instruction and the headline-demotion rule. - `.agents/skills/release-changelog-discord-message/SKILL.md`: one mirrored bullet in the template notes. ## Verification - Docs-only; proofread. The rule matches the fix applied to the live v2026.821.0 draft (#11661), which is the worked example of what it prevents. ## Risks - None; docs-only. ## Model Used Claude Fable 5 (Claude Code) ## Pre-submission checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template	2026-08-18 16:41:00 -07:00
Devin Foleyandgithub-actions[bot]	ffaac1d7f9	docs(release): stable notes for the 2026.818.0-beta.1 soak (v2026.821.0) (#11661) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The release channels promote a soaked beta to stable, and the promotion reads the stable's release notes from `releases/beta/v<beta-version>.md` on master > - Beta `2026.818.0-beta.1` is soaking now, and the release workflow auto-drafted its notes skeleton on this branch at publish time > - This pull request rewrites that skeleton into the finished changelog for the upcoming stable > - The stable preflight fails without this file on master, so this PR must merge before promotion day > - The benefit is release notes reviewed during the soak instead of written at the gate ## Linked Issues or Issue Description **What existing behavior does this improve?** The release-notes flow for the upcoming stable (planned `v2026.821.0`, promoting beta `2026.818.0-beta.1`, source `664052f8e`). **Current behavior** The branch holds the machine-generated skeleton: grouped commit subjects for the 172-commit range from v2026.817.0's content baseline (`8f7b8b3fd`). **Proposed behavior** The finished changelog in the established release voice: verified Breaking Changes, Highlights, Improvements, Fixes, an Upgrade Guide covering migrations 0212–0222 and the new environment variables, and a verified community contributor list. **Reason and benefit** Notes get real review during the soak; the promotion just reads the merged file. ## What Changed - Rewrite `releases/beta/v2026.818.0-beta.1.md` from skeleton to finished notes. Headline themes: chat-style tasks as the default experience, Tailscale HTTPS managed runtime exposure, sandbox capability contract with live output streaming, in-product Claude/Codex sign-in, chunked resumable company imports, and the completed release-channel automation. - Five verified breaking/behavior changes, including the `enableTaskChatRedesign` → `enableClassicTaskInterface` toggle inversion and migration `0218`'s conservative resolver-policy remap. - Contributors: 172 commits from 32 non-bot authors; 22 verified community handles listed (founders/core excluded per the canonical list; 4 authors omitted as unverifiable rather than guessed). ## Verification - Every cited PR number resolves to a commit subject in the range. - No internal ticket identifiers. - Handles verified via noreply emails, co-author trailers, or `gh api users/<name>`. - The version/date header says the planned promotion (`v2026.821.0`, 2026-08-21); if promotion slips, only that header needs a touch-up — the beta-keyed filename is date-independent. ## Risks - Docs-only. If a newer beta supersedes `2026.818.0-beta.1` before promotion, this file stays as history and the new beta gets its own draft. ## Model Used Claude Fable 5 (Claude Code) ## Pre-submission checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>	2026-08-18 16:40:32 -07:00
Devin Foley	e434829889	fix(release): draft-notes baseline survives candidate-cut stables (#11647) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The release workflow drafts the upcoming stable's notes skeleton at beta publish, ranging from the last stable to the beta's source commit > - Stables cut from candidate branches leave their tag off master's lineage, so the ancestor-only baseline rule skips them and falls back a whole release too far > - The first live draft did exactly that: it ranged from v2026.722.0 instead of the just-shipped v2026.817.0 and re-included everything already released > - This pull request replaces the baseline rule with a merge-base walk over stable tags and adds a candidate-branch regression fixture > - The benefit is a correct draft range for every stable lineage: master-cut, candidate-cut, and promoted-older-source ## Linked Issues or Issue Description **What happened?** The first `draft_stable_notes` run (for beta `2026.818.0-beta.1`) generated `releases/beta/v2026.818.0-beta.1.md` with the range `v2026.722.0..664052f8e` — 311-commits-worth of already-shipped v2026.817.0 content re-included. **Expected behavior** The draft ranges from the point the shipped stable's content diverges from the beta source. For v2026.817.0 (cut from `candidate/release-2026.817.0`) that is the promoted source commit `8f7b8b3fd`, giving the 172 commits of genuinely-new work. **Steps to reproduce** Ship a stable from a candidate branch (tag lands off master's lineage), then publish a beta from master and read the generated skeleton's range line. **Paperclip version or commit** master at `664052f8e`. Related (not duplicates): #11567 introduced the generator; its ancestor-only rule was itself a review fix for the newest-by-version rule, and this PR is the second iteration with the lineage case the first fix missed. ## What Changed - `scripts/draft-stable-notes.sh`: the range start comes from walking stable tags newest-first and taking the first whose merge-base with the beta source is a proper ancestor of the source. Candidate-cut stables resolve to the promoted commit, master-lineage stables to the tag itself, and tags containing the source are skipped (an older-source promotion cannot produce an empty range). The skeleton header prints a runnable short-sha range with the stable tag as a labeled baseline. - `scripts/draft-stable-notes.test.mjs`: new regression fixture with the stable tag on an unmerged candidate branch; the existing older-source and fallback fixtures still pass unchanged. ## Verification - `node --test scripts/draft-stable-notes.test.mjs` — 8 pass, including the new fixture. - Regenerated the live `2026.818.0-beta.1` draft against the real repository: range start resolves to `v2026.817.0 (merge-base 8f7b8b3fd)`, 172 commits, shipped-in-stable subjects absent, post-beta subjects present. - `bash -n` on the script. ## Risks - Low risk: the script only produces a draft file; publishes are untouched. The live skeleton branch for `2026.818.0-beta.1` is regenerated with the corrected output (machine-owned branch, force-push by design). ## Model Used Claude Fable 5 (Claude Code) ## Pre-submission checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template	2026-08-18 14:51:58 -07:00
Devin Foley	393da0f67c	fix(adapter-utils): graft unrelated imported histories instead of failing the run (#11638) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - At run finalize, the host imports the sandbox git history and reconciles it with the local worktree in `integrateImportedGitHead` > - Transported workspaces are depth-1 shallow clones, so the boundary commit reads as parentless inside the sandbox > - A `git commit --amend` there rewrites the boundary commit into a root commit, and the re-imported history no longer connects to the host history > - `git merge-tree` has no common base to merge against, so the sync throws "Failed to merge concurrent remote git histories" and the run fails with its work stranded in the sandbox > - This pull request grafts the imported tree onto the current head as a single commit instead of failing > - The benefit is that a history rewrite inside the sandbox can no longer lose a run's work ## Linked Issues or Issue Description No existing issue found. I searched issues and PRs for "unrelated histories", "Failed to merge concurrent", and "shallow". Depends on #11637 (merged; the graft commit reuses its identity constant). This PR is now rebased onto `master`. **What happened?** An agent run amended a commit inside its sandbox workspace to address review feedback. The sandbox clone is depth-1 shallow, so git treated the boundary commit as parentless and the amend produced a root commit. At finalize, the host-side sync failed with `Failed to merge concurrent remote git histories for <sha>` and the run was marked failed. A follow-up run had to repair the branch by hand: fetch the true parent from origin and rebuild the commit with `git commit-tree`. **Expected behavior** The sync must never strand completed work. When the imported history shares no ancestor with the local one, the imported tree should still land on the current head, with the imported message preserved and the graft recorded. **Steps to reproduce** 1. Start a run whose workspace transport uses the shallow clone path (`withShallowGitWorkspaceClone`, depth 1). 2. Inside the sandbox workspace, run `git commit --amend` on the boundary commit. The result is a parentless root commit. 3. Finish the run. The host-side `integrateImportedGitHead` finds no merge base, `merge-tree` fails, and the run fails. ## What Changed - `git-workspace-sync.ts`: new exported `createUnrelatedHistoryGraftCommit` helper. It reads the imported head's tree and message, and creates one commit on top of the current head with the deterministic sync identity and a trailer that records the graft and both shas. - `integrateImportedGitHead` (both the remote-git-sync version and the SSH copy in `ssh.ts`): when `merge-base` reports no common ancestor, graft instead of throwing. The ref update keeps the same compare-and-swap and concurrent-retry semantics as the merge path. - The graft is gated on `git merge-base` exiting with status 1 — the no-ancestor signal. Operational failures (timeout, missing object, repository error) keep the loud merge failure instead of rewriting the tip. - New regression tests: one builds the exact shallow-amend shape (a root commit rebuilt from the base tree) and asserts the graft lands on the current head with the imported tree, subject, and graft trailer; one integrates a well-formed sha the repository does not hold and asserts the integration still throws with the branch tip unchanged. ## Verification - `pnpm vitest run packages/adapter-utils/src/git-workspace-sync.test.ts` — 19/19 pass (includes the new graft test and the merge-base failure-discrimination test). - `pnpm --filter @paperclipai/adapter-utils typecheck` — clean. - Full `pnpm vitest run packages/adapter-utils`: every file passes except `local-process-sandbox.test.ts`, which fails identically on an untouched `master` checkout on macOS (bubblewrap-dependent, pre-existing, unrelated). ## Risks - Behavioral shift: unrelated imported histories previously failed the integration; now they land as a squash-graft. In this degenerate case there is no base to merge against, so the imported tree is taken wholesale and concurrent local-only tree changes are superseded at the tip. The local commits keep their place in the graft's ancestry, and the trailer records both shas, so nothing is unrecoverable. The old behavior lost the imported work instead, which is the worse failure for an autonomous run. - The graft reuses the imported head's commit message, so branch history still reads naturally after a sandbox rewrite. ## Model Used - Claude Fable 5 (`claude-fable-5`), extended thinking, via Claude Code CLI (tool use for code exploration, test runs, and verification). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes (no doc surface describes this internal sync path) - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-18 11:14:39 -07:00
Devin Foley	9ea8143c87	fix(adapter-utils): give sync-created merge commits a deterministic git identity (#11637) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Runs execute in transported workspaces; at finalize, the host syncs the sandbox git history back into the local worktree > - When both sides advanced, `integrateImportedGitHead` reconciles them with `git merge-tree` plus `git commit-tree` on the host > - Execution hosts are often containers with no git config and no resolvable hostname, so `commit-tree` fails with "Author identity unknown" > - That one local command failure marks the whole run as failed, even though the run's work succeeded > - This pull request gives sync-created merge commits an explicit, deterministic identity at the call site > - The benefit is that workspace finalize no longer depends on ambient host git configuration ## Linked Issues or Issue Description No existing issue found. I searched issues and PRs for "Author identity unknown", "unrelated histories", and "commit-tree identity". **What happened?** A run finished its work, but workspace finalize failed. The host-side sync ran `git commit-tree <tree> -p <localHead> -p <importedHead> -m "Paperclip remote git sync merge <sha>"`. Git exited with `Author identity unknown ... fatal: unable to auto-detect email address (got 'node@<container-id>.(none)')`. The adapter recorded the whole run as failed, and the host worktree kept the stale head. Any container deployment without a global gitconfig reproduces this; I observed it on a Paperclip Cloud stack. **Expected behavior** Commits that the sync machinery itself creates must not depend on ambient host git configuration. The merge commit is machine-authored, so it should carry a deterministic Paperclip identity. **Steps to reproduce** 1. Run the Paperclip server in a container with no `user.name`/`user.email` git config and a hostname git cannot turn into an email. 2. Let a run's sandbox branch diverge from the host worktree, so both sides advance. 3. Workspace finalize calls `integrateImportedGitHead`. The `git commit-tree` step fails with "Author identity unknown" and the run fails. ## What Changed - `git-workspace-sync.ts`: new exported `GIT_SYNC_COMMIT_IDENTITY_ARGS` (`-c user.name=Paperclip -c user.email=noreply@paperclip.ing`), applied to the `commit-tree` call in `integrateImportedGitHead`. - `ssh.ts`: the SSH-sync copy of `integrateImportedGitHead` applies the same identity args to its `commit-tree` call. - New regression test: builds divergent histories in a repo with no configured identity and asserts the sync merge commit is created with the deterministic identity, correct parents, and merged tree. ## Verification - `pnpm vitest run packages/adapter-utils/src/git-workspace-sync.test.ts` — 18/18 pass. - `pnpm --filter @paperclipai/adapter-utils typecheck` — clean. - Negative proof: with the source fix stashed, the new test fails on the identity assertion. - Full `pnpm vitest run packages/adapter-utils`: every file passes except `local-process-sandbox.test.ts`, which fails identically on an untouched `master` checkout on macOS (bubblewrap-dependent, pre-existing, unrelated). ## Risks Low risk. The change only adds `-c` identity flags to two machine-generated commit invocations. `GIT_AUTHOR_*` / `GIT_COMMITTER_*` environment variables still take precedence over `-c` when an operator sets them, so existing deployments that configure an identity keep their behavior. ## Model Used - Claude Fable 5 (`claude-fable-5`), extended thinking, via Claude Code CLI (tool use for code exploration, test runs, and verification). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes (no doc surface describes this internal sync path) - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-18 11:00:54 -07:00
Devin Foley	664052f8ea	feat(release): draft stable notes at beta publish, read them from master at promotion (#11567) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The release channel system promotes builds canary → nightly → beta → stable, and stable releases publish a GitHub Release from `releases/vYYYY.MDD.P.md` > - The stable lane requires that notes file to exist inside the promoted source commit, but the file is named for the promotion date, which is unknown when the source commit is created > - A promoted beta can therefore never pass the notes check: every happy-path stable is forced through the candidate-branch fix path, with a soak-gate justification, for a notes-only change > - This pull request drafts the notes automatically when the beta is published and lets the stable promotion read them from `master` > - The benefit is a walkable stable happy path: the soak gate stays exact, notes get a real review window during the soak, and the justification path returns to its real purpose (cherry-picked fixes) ## Linked Issues or Issue Description **What existing behavior does this improve?** The stable promotion path in the release channel system (`release.yml`, `scripts/release.sh`). **Current behavior** `release.sh stable` requires `releases/vYYYY.MDD.P.md` in the checked-out source tree, and `publish_stable` checks out the exact promoted SHA. The soak gate requires a `beta/v*` tag to point at that same SHA. No commit can satisfy both for a promoted beta, so a stable promotion must cut a candidate branch with a notes-only commit and bypass the soak gate with a written justification. Release notes are also written at promotion time, under time pressure, with no review window. **Proposed behavior** When a beta publishes, a `draft_stable_notes` job generates a grouped notes skeleton at `releases/beta/v<beta-version>.md` and pushes it to a machine-owned branch; a human opens the PR and edits it during the 3-day soak. The stable preflight resolves notes before the `npm-stable` approval gate: source-tree notes first (the candidate fix path, unchanged), then the merged beta-keyed file on `master`; it fails early with the missing path named when neither exists. After the stable ships, a canonicalization job pushes a branch that moves the file to `releases/vYYYY.MDD.P.md`. Related (not duplicates): #11006 and #11008 introduced the nightly and beta lanes this builds on; older changelog PRs (for example #10669) authored notes manually at promotion time, which is the flow this replaces. **Reason and benefit** The happy path becomes: promote the exact soaked SHA, no justification, notes reviewed during the soak instead of written at the gate. The `releases/vYYYY.MDD.P.md` invariant still holds durably via the canonicalization PR. ## What Changed - `scripts/release.sh`: new `--notes-file PATH` (stable only) overrides where the pre-publish notes check looks, so notes can live outside the source checkout without dirtying the worktree. - `scripts/create-github-release.sh`: same `--notes-file` override for the GitHub Release body. - `scripts/draft-stable-notes.sh` (new): deterministic skeleton generator — commit subjects from the newest stable tag (falling back to the previous beta, then full history) to the beta's source commit, grouped into Features / Fixes / Other. - `.github/workflows/release.yml`: - `draft_stable_notes` job after `publish_beta`: runs the generator and force-pushes `release-notes/v<beta-version>`; the job summary links the compare page. It recreates the beta tag locally if the tag push was rejected (the known workflows-permission case), so drafting is not blocked on manual tag recovery. - `preflight_stable`: computes the target stable version (`release.sh stable --print-version`) and resolves the notes source (`source_tree` → `master_beta` → fail early / warn on dry run); new outputs. - `publish_stable`: materializes `master`-side notes into `RUNNER_TEMP` and passes `--notes-file` to both scripts; outputs the published stable version. - `canonicalize_stable_notes` job: pushes the `git mv` branch after a stable that used `master`-side notes. - `doc/RELEASING.md`, `doc/RELEASE-CHECKLIST.md`: document the drafted-notes flow, the preflight resolution order, and the canonicalization step; the LLM changelog flow now targets the draft branch during the soak. - `.agents/skills/release-changelog/SKILL.md`, `.agents/skills/release-changelog-discord-message/SKILL.md`: the notes-authoring skills now describe this flow — range ends at the beta source commit (not `HEAD`), the file is beta-keyed on the `release-notes/v<beta-version>` branch (seeded with `scripts/draft-stable-notes.sh` for betas that predate the automation), and the canonicalization link caveat is called out for announcements. ## Verification - `node --test scripts/draft-stable-notes.test.mjs` — 6 tests, temp git-repo fixtures: grouping, stable-tag range, previous-beta and full-history fallbacks, default output path, malformed version, missing tag. - `node --test scripts/release-lib.test.mjs` — unchanged suite still green. - `bash -n` on both changed shell scripts; `release.yml` re-parsed as YAML. - `./scripts/release.sh stable --print-version` unchanged (prints the next stable version); `--notes-file` on a non-stable channel fails with a clear error. - Not exercised end-to-end: the new workflow jobs need a real beta publish to run. The first beta after merge is the live test; the draft job is additive and cannot affect the publish result (it runs after `publish_beta` completes). ## Risks - Low risk to publishing itself: `--notes-file` defaults preserve today's behavior everywhere; the draft and canonicalization jobs are additive and run after the publishes succeed. - The preflight now fails a real stable run when no notes are found. That is the intended fail-early behavior (it previously failed later, inside `publish_stable`, after the `npm-stable` approval). - `draft_stable_notes` force-pushes only the machine-owned `release-notes/v<beta-version>` branch; a beta re-cut regenerates it cleanly. - The stable version computed at preflight could differ from the published one if a run crosses UTC midnight between the two jobs; the materialized notes are passed by path, so the publish still succeeds, and the canonicalization job uses the actually-published version. ## Model Used Claude Fable 5 (Claude Code) ## Pre-submission checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template	2026-08-17 20:47:23 -07:00
Devin Foley	6691c57e54	docs(release): reconcile v2026.817.0 release notes to master (#11590) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Stable release notes live at `releases/vYYYY.MDD.P.md` on master as the durable record > - v2026.817.0 shipped from a candidate branch, so its notes file exists on that branch and in the GitHub Release, but not yet on master > - This pull request lands the exact shipped notes at the canonical path > - The benefit is a complete stable-notes record on master, and the FULL RELEASE NOTES link in announcements resolves ## Linked Issues or Issue Description **What existing behavior does this improve?** The `releases/` record on master. **Current behavior** `releases/` on master ends at `v2026.722.0.md`. The v2026.817.0 notes exist only on `candidate/release-2026.817.0` and in the published GitHub Release. **Proposed behavior** `releases/v2026.817.0.md` exists on master, byte-identical to what the release published. **Reason and benefit** Complete history at the canonical path; the standard notes link (`releases/v2026.817.0.md` on master) resolves for the announcement. ## What Changed - Add `releases/v2026.817.0.md`, taken verbatim from the candidate branch the release was published from (tag `v2026.817.0`, commit `213dabab4`). ## Verification - `git diff v2026.817.0 -- releases/v2026.817.0.md` against this branch is empty (byte-identical to the shipped file). - Docs-only; no code surface. ## Risks - None; docs-only. The candidate branch is deleted after this merges (the `v2026.817.0` tag keeps its commits reachable). ## Model Used Claude Fable 5 (Claude Code) ## Pre-submission checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template	2026-08-17 20:33:45 -07:00
3 people	49217aadf0	refactor: balance serialized server shards by recorded suite duration (#11528) ... <!-- Write all pull request text in Simplified Technical English (ASD-STE100). --> ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The PR verify workflow gates every pull request; its wall-clock time sets the feedback loop for all contributors > - In a recent successful PR run (actions run 32012408876), the slowest check was "Verify serialized server suites (1/5)" at 337s, while its four sibling shards finished in 212-238s > - The serialized lane assigns suites to shards round-robin over an alphabetical list, so the heavy heartbeat and issues suites cluster on one runner > - The general-server lane already solves this with a duration-aware LPT partition backed by a recorded manifest > - This pull request reuses that partitioner for the serialized lane with a fresh per-suite duration manifest > - The benefit is a balanced serialized matrix: the measured 968s suite total levels to about 194s per shard, which removes about 80-100s from the run's slowest check ## Linked Issues or Issue Description **What existing behavior does this improve?** The `Verify serialized server suites` shard matrix in `.github/workflows/pr.yml` distributes route/authz test suites across five runners. **Subsystem affected** CI / test infrastructure (`scripts/run-vitest-stable.mjs`). **Current behavior** `selectSerializedSuites` assigns suites round-robin (`index % shardCount`) over the alphabetically sorted file list. The heavy suites cluster on shard 1/5. In actions run 32012408876, shard 1/5 spent 291s in its test step while the other shards spent 170-201s, which made that job (337s total) the slowest check of the whole PR run. **Proposed behavior** Partition the serialized suites with the same duration-aware LPT algorithm the general-server lane already uses (`scripts/general-server-shard.mjs`), backed by a new per-suite duration manifest. All five shards then carry about 194s of measured test time. **Reason and benefit** The slowest check bounds PR feedback time. Balancing the serialized matrix removes about 80-100s from that bound without adding runners. **Breaking changes** None. The partition remains deterministic, complete, and non-overlapping; suites missing from the manifest get the median weight. ## What Changed - Added `scripts/serialized-shard-durations.json`: per-suite wall-clock durations (ms) for all 134 serialized suites, sampled from actions run 32012408876 by diffing consecutive per-suite label timestamps in the shard logs (captures vitest spawn overhead, not just reported test time) - `scripts/run-vitest-stable.mjs`: `selectSerializedSuites` now uses the existing LPT partitioner (`selectGeneralServerShard`) with the new manifest instead of round-robin - `scripts/__tests__/run-vitest-stable-shard.test.mjs`: added a manifest-freshness test and a shard-balance test for the serialized lane, mirroring the general-server ones - `.github/workflows/pr.yml`: updated the serialized matrix comment with the new measurement and mechanism ## Verification - `node --test ./scripts/__tests__/run-vitest-stable-shard.test.mjs` passes (13 tests), including the existing test that the serialized shards form a complete, non-overlapping partition - Dry-run of all five shards shows estimated totals of 194/194/194/194/193s (round-robin was 276/175/160/172/187s): `node scripts/run-vitest-stable.mjs --mode serialized --shard-index N --shard-count 5 --dry-run` - The `Verify serialized server suites` jobs on this PR run the real partition end to end ## Risks - Low risk. Selection logic only; the vitest invocation per suite is unchanged - A stale manifest degrades gracefully: unknown suites get the median weight, and a dedicated test fails if fewer than half the current suites have recorded durations ## Model Used - Claude (Anthropic), model ID `claude-fable-5`, agentic coding session with tool use (Claude Code / Claude Agent SDK); no extended-thinking mode ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge Related prior work: #10923 (split serialized tests into five shards), #10925 (general-server duration manifest), #11156 (workspaces-a native shards). Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-17 20:30:44 -07:00
Devin Foley	48f4ae16ac	fix(codex-local): keep a promoted device-login credential when re-seeding the managed home (#11578) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The codex_local adapter supports a device login that runs in a trusted sandbox and promotes the credential into the per-company managed Codex home > - The managed-home re-seeding step treats every regular-file `auth.json` as apikey-mode residue and removes it so the shared-home symlink can be restored > - The promotion writes the company credential as a regular file, so the first environment Test or run after a successful login deletes it > - On a server with no shared Codex login — any containerized deployment — nothing replaces the file, and the UI reports that the sandbox has no ready authentication right after it reported a successful login > - This pull request makes the cleanup identity-anchored: a subscription credential whose identity the shared source does not hold survives re-seeding > - The benefit is that a device login stays usable after Test and runs, on hosts with and without a shared Codex login ## Linked Issues or Issue Description No public GitHub issue covers this. The problem is described in-PR following the bug template. Related public PRs: [#11237](https://github.com/paperclipai/paperclip/pull/11237) added the sandbox device login and the credential promotion, [#11097](https://github.com/paperclipai/paperclip/pull/11097) added its building blocks, and the `ensureSymlink` heal for stale copies came from the fix for #5028. [#9621](https://github.com/paperclipai/paperclip/pull/9621) touches the adjacent sandbox auth sync-back lane but not this defect. **Subsystem affected** packages/adapters/codex-local — managed `CODEX_HOME` seeding (`codex-home.ts`). **Current behavior** A successful device login promotes the subscription `auth.json` into the company Codex home as a regular file, and the UI reports the login as authenticated. The next `seedManagedCodexHome` call — the environment Test probe and every execute both run it — removes any regular-file `auth.json` when no API key is configured, because the cleanup assumes such a file is apikey-mode residue left by a previous run. It then symlinks `auth.json` from the shared source home. On a server whose shared home has no Codex login (a container image, for example), there is no source to symlink, so the home ends with no credential at all. The Test probe then reports "The sandbox has no ready authentication for this adapter" immediately after a successful login, and a fresh login repeats the same cycle. On a server whose shared home does hold a login, the symlink silently replaces the promoted account with the host account. **Expected behavior** The credential a device login promoted stays in the company home across Test probes and runs. The #5028 heal (a stale regular-file copy of the shared credential becomes a symlink to the live source) and the apikey-residue cleanup keep working. **Steps to reproduce** 1. Run the server in an environment whose shared Codex home (`$CODEX_HOME` or `~/.codex`) has no `auth.json`. 2. Complete a Codex device login for a company; the promotion writes the company home `auth.json` and the UI reports authenticated. 3. Click Test on a codex_local agent (or start a run). The probe reports no ready authentication, and the promoted `auth.json` is gone from the company home. **Proposed solution** Make the cleanup identity-anchored, the same rule the promotion and the cache vend already use. A regular-file `auth.json` survives re-seeding when it holds a usable subscription identity that the shared source does not also hold, and the shared symlink does not replace it. A same-identity regular file is still the #5028 stale copy and is still healed into the symlink, because the symlink serves the same account with live, rotating tokens. An apikey-mode or unreadable file is still removed. ## What Changed - `seedManagedCodexHome` reads the target `auth.json` before the cleanup and keeps it when `readSubscriptionAccountId` yields an identity the shared source `auth.json` does not hold. The kept file is excluded from the shared symlink pass, and the function logs a fixed line when it keeps the file. - The function doc comment states the kept-promoted-credential rule. - Four new `seedManagedCodexHome` test cases: a promoted credential with no shared auth, a promoted credential with a different shared identity, the same-identity #5028 heal, and apikey-mode residue removal. ## Verification ```sh cd packages/adapters/codex-local npx tsc --noEmit # clean npx vitest run # 28 files, 321 passed, 1 skipped ``` The four new cases fail on the previous code: the first two observed the promoted file deleted (and, with a shared login present, replaced by the shared symlink). ## Risks Low risk. The change narrows one deletion path. Deployments that never use the device login see no difference: without a promoted subscription file, the cleanup and the symlink behave exactly as before, and the #5028 heal is pinned by an existing test plus a new same-identity test. The one deliberate behavioral shift: after a device login, the promoted company credential now stays authoritative over the shared host login for that company — which is the promotion's documented contract ("the company credential slot"). ## Model Used Claude Fable 5 (`claude-fable-5`), extended thinking, with tool use and code execution — investigation, implementation, and tests. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-17 20:11:07 -07:00
Devin Foley	adfb357223	docs(skills): maintain the release-credits exclusion list (#11588) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Stable release notes end with a Contributors section that credits community contributors > - The release-changelog skill excluded founders from that list, but had no rule for non-founder core contributors > - A release-notes draft therefore credited two core contributors as community contributors > - This pull request makes the exclusion list canonical in the changelog skill and adds the core contributors > - The benefit is that release credits consistently mean "community", with one list to maintain ## Linked Issues or Issue Description **What existing behavior does this improve?** The Contributors rules in `.agents/skills/release-changelog/SKILL.md` and the Community-section rules in `.agents/skills/release-changelog-discord-message/SKILL.md`. **Current behavior** The changelog skill says to exclude "Paperclip founders (e.g. `cryppadotta`, `forgottendev`, `devinfoley`, `sockmonster`, `scotttong`)". Core contributors who are not founders are not covered, so drafts credit them in the community list. The Discord skill refers to "founders" in two places. **Proposed behavior** The changelog skill holds the canonical exclusion list of specific folks — now including `nguyenm7`, `nickyleach`, and `tonio-alucema` — and both Discord-skill references defer to that one list. **Reason and benefit** Release credits consistently mean community contributions, and there is exactly one place to update when the core team changes. ## What Changed - `.agents/skills/release-changelog/SKILL.md`: the exclusion rule names specific folks, is the canonical list, and adds `nguyenm7`, `nickyleach`, and `tonio-alucema`. - `.agents/skills/release-changelog-discord-message/SKILL.md`: both references ("Community" template note and the final checklist) defer to the changelog skill's canonical list. ## Verification - Docs-only change; rendered and proofread. No workflow, script, or test surface is touched. ## Risks - None beyond docs accuracy. If the canonical-list wording lands after #11567 (which touches other sections of the same files), Git merges them cleanly — the edited regions do not overlap. ## Model Used Claude Fable 5 (Claude Code) ## Pre-submission checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template	2026-08-17 19:51:13 -07:00
Devin Foley	962e98b1be	feat(server): operator declaration for platform edge TLS termination on the Claude login guard (#11579) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The Claude local adapter supports a setup-token subscription login, and its confidential routes pass a fail-closed transport guard > - The guard accepts direct socket TLS, a local_trusted loopback peer, or an allowlisted proxy peer that forwards https — and deliberately never reads the global `TRUST_PROXY` > - On a managed platform the edge terminates TLS, the app socket is always plain HTTP, and the edge-proxy peer addresses are not stable or documented, so none of the three cases can hold > - Every login on such a deployment shows the clear-text transport warning although the user's connection is HTTPS, and the agent-scoped confidential routes fail closed entirely > - This pull request adds a dedicated operator declaration that the platform edge terminates TLS, as a fourth guard case > - The benefit is a correct transport decision on managed platforms with the default posture unchanged everywhere else ## Linked Issues or Issue Description No public GitHub issue covers this. The problem is described in-PR following the enhancement template. Related public PRs: [#11347](https://github.com/paperclipai/paperclip/pull/11347) added the new-agent login flow and the non-blocking transport advisory, and [#11286](https://github.com/paperclipai/paperclip/pull/11286) added the setup-token login and the guard with its `CLAUDE_LOGIN_TRUSTED_PROXIES` allowlist. **Subsystem affected** server/ — the confidential transport guard for the Claude setup-token login (`services/setup-token-session.ts`, `routes/agents.ts`, `app.ts`). **Current behavior** The guard allows a confidential response on direct socket TLS, on a `local_trusted` loopback peer, or when the immediate peer is on the dedicated `CLAUDE_LOGIN_TRUSTED_PROXIES` allowlist and forwards `https`. Behind a managed platform's TLS-terminating edge (Railway, Render, Fly, and similar), the app socket is plain HTTP and the edge-proxy peer addresses are not operator-visible or stable, so the allowlist cannot express them — IPv6 entries match by exact string only. The result: the login panel shows "This connection is not encrypted" for a connection that is HTTPS to the user, and the agent-scoped confidential routes return the fixed no-secret error. **Proposed behavior** `CLAUDE_LOGIN_EDGE_TLS_TERMINATED=true` is an explicit, single-purpose operator declaration that every client request reaches the server through the platform's TLS-terminating edge. Under the declaration the guard treats a request as confidential unless the edge itself labels the client hop as plain `http` in `X-Forwarded-Proto`. The declaration is never derived from the global `TRUST_PROXY` setting, which the guard still never reads. Without the declaration, nothing changes. **Reason and benefit** The guard's spoofing concern does not apply to this deployment shape: a client cannot pick its transport, because the platform admits HTTPS only, and the header the guard consults is set by the platform edge, not the client. A blanket warning that is always wrong teaches users to ignore it. The declaration keeps the strict default for every deployment that does not opt in, and it keeps the allowlist as the precise tool for operators who do know their proxy addresses. ## What Changed - `ConfidentialTransportConfig` gains optional `edgeTlsTerminated` (default false), documented as the operator declaration for platform edge TLS termination. - `evaluateConfidentialTransport` adds the declaration as a guard case: allowed unless the forwarded protocol's first hop is explicitly `http` (reason `edge_labeled_plain_http` then; `operator_edge_tls_termination` when allowed). - `assessConfidentialStartup` reports `edge_tls_termination_declared`, so the startup log shows why forwarded requests pass. - `app.ts` parses `CLAUDE_LOGIN_EDGE_TLS_TERMINATED` (truthy: `1/true/yes/on`) and passes it to the agent routes; the routes build the guard config from it. - The SR-7 operator-requirement comment on the setup-token routes documents the new variable next to the allowlist. - Tests: five new guard unit cases and a route case asserting the prompt and code responses carry no `transportAdvisory` under the declaration. ## Verification ```sh cd server npx tsc --noEmit # clean npx vitest run src/services/setup-token-session.test.ts \ src/routes/setup-token-route.test.ts \ src/__tests__/openapi-routes.test.ts # 3 files, 89 passed ``` The new "keeps failing closed when the declaration is absent" case pins the unchanged default posture. ## Risks The declaration is an operator statement the server cannot verify; an operator who sets it on a deployment whose edge does not terminate TLS re-labels plain-HTTP requests as confidential. This is the same trust class as `CLAUDE_LOGIN_TRUSTED_PROXIES` (a wrong allowlist entry has the same effect) and is opt-in, off by default, and scoped to the login routes only. The guard still fails closed when the edge explicitly labels a request `http`. No schema change, no API shape change — `transportAdvisory` was already nullable. ## Model Used Claude Fable 5 (`claude-fable-5`), extended thinking, with tool use and code execution — investigation, implementation, and tests. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-17 17:46:45 -07:00
Devin Foley	2ec984502a	fix(release): stop smoke_beta silently skipping on promote-mode betas (#11582) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The release channel system re-smokes every published beta as post-publish verification (`smoke_beta`) > - The candidate-branch beta lane (#11209) added `verify_beta_candidate` to `publish_beta`'s needs; that job is skipped on every normal promote-mode beta > - `smoke_beta`'s condition has no status-check function, so GitHub attaches an implicit `success()` that evaluates the needs chain transitively — a skipped ancestor makes it false > - This pull request makes the condition explicit so promote-mode betas smoke again, and pins the shape in the workflow wiring test > - The benefit is that the post-publish beta gate actually runs instead of silently skipping ## Linked Issues or Issue Description **What happened?** Beta `2026.818.0-beta.0` (run 32082007439) published successfully, but its post-publish `smoke_beta` job was skipped. No configuration or input asked for that: the run was a plain `channel: beta` dispatch with `dry_run` at its default `false`, and the same expression `!inputs.dry_run` evaluated true inside `publish_beta`'s own steps (the Docker dispatch step ran). **Expected behavior** Every non-dry-run beta publish is followed by the release smoke suite against the exact published version, as documented in `doc/RELEASING.md` and `doc/RELEASE-CHECKLIST.md`. **Steps to reproduce** Dispatch `release.yml` with `channel: beta` promoting a nightly (promote mode). `verify_beta_candidate` is skipped by design; `publish_beta` runs through its explicit `!cancelled()` condition; `smoke_beta` then skips because its implicit `success()` sees the skipped ancestor in the transitive needs chain (actions/runner#2205 semantics). The beta published on 2026-08-11 predated #11209, so this never surfaced before. **Paperclip version or commit** master at `43ab441f0` (workflow file, current head). Related (not duplicates): #11209 introduced the candidate lane whose skipped job triggers this; #11208 covers the adjacent tag-push failure playbooks. ## What Changed - `smoke_beta`'s condition becomes `!cancelled() && needs.publish_beta.result == 'success' && !inputs.dry_run` — an explicit status-check function suppresses the implicit `success()`, and the result check keeps the dependency on a successful publish. - A comment above the job records why the explicit form is load-bearing. - `scripts/__tests__/release-verify-workflow.test.mjs` pins the new shape so the implicit form cannot silently return. ## Verification - `node --test scripts/__tests__/release-verify-workflow.test.mjs` — 8 pass, including the new assertion. - `release.yml` re-parsed as YAML. - The exact skip is visible on run 32082007439 (`smoke_beta: skipped` after `publish_beta: success`); the coverage gap for that beta was closed manually by dispatching `release-smoke.yml` with `paperclip_version: beta` (run 32084880767). - Not exercised end-to-end: the corrected condition needs the next real promote-mode beta to demonstrate; the expression change is minimal and the semantics are the documented actions/runner behavior. ## Risks - Low risk: condition-only change on one job plus a test. Dry runs still skip the smoke (`!inputs.dry_run` retained). Candidate-mode betas, where `verify_beta_candidate` actually runs, behave as before. ## Model Used Claude Fable 5 (Claude Code) ## Pre-submission checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template	2026-08-17 17:45:44 -07:00
Devin Foley	4af55ba6bd	test(release-smoke): follow the onboarding wizard's chat-first rewrite (#11565) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The release channel system publishes a nightly build only after the release smoke suite passes against the newest canary > - The scheduled nightly run has failed every night since August 12, so no nightly, and therefore no beta candidate, has shipped for six days > - The failures are stale test locators, not a product regression: the chat-first onboarding rewrite (#11101) changed wizard copy and the post-launch destination > - This pull request updates the smoke spec to match the current wizard > - The benefit is a green nightly lane and an unblocked beta promotion ## Linked Issues or Issue Description **What happened?** The scheduled `Release` nightly run fails in `smoke_nightly / smoke` every night since 2026-08-12. The failing spec is `tests/release-smoke/docker-auth-onboarding.spec.ts`. Four assertions no longer match the product after the chat-first onboarding rewrite (#11101): - The step-1 heading is now "Name your organization", not "Name your company". - The step-4 hire button is now "Connect", not "Give it a heartbeat". - The seeded first task is now titled "Paperclip onboarding". - A successful launch navigates to the seeded task's thread (`/issues/<ref>`), not `/dashboard`. **Expected behavior** The smoke suite passes against a canary that contains the current onboarding wizard, and the nightly lane publishes again. **Steps to reproduce** Run `.github/workflows/release-smoke.yml` against `paperclipai@canary` (any version at or after the rewrite), or dispatch `release.yml` with `channel: nightly`. Example red runs: 32014452506 (Aug 17), 31938284401 (Aug 16). **Paperclip version or commit** `2026.817.0-canary.12` Related (not duplicates): #11190 updated this same spec for the mission-first wizard; this PR is the follow-up for the chat-first rewrite that landed after it. ## What Changed - Update the step-1 wizard heading locator to "Name your organization". - Update the step-4 hire button locator to "Connect" and reword the step comment. - Update `FIRST_TASK_TITLE` to "Paperclip onboarding" (the wizard's current `DEFAULT_TASK_TITLE`). - Assert the post-launch URL is the seeded task's thread (`/issues/`), not `/dashboard`. ## Verification - Local run of the exact CI harness: `scripts/docker-onboard-smoke.sh` with `PAPERCLIPAI_VERSION=2026.817.0-canary.12`, then `pnpm run test:release-smoke` against the container — 1 passed. - The suite's later API assertions (company, CEO agent, mission goal, seeded issue assignment, assignment-sourced heartbeat run) all pass unchanged against the current canary. ## Risks - Low risk: test-only change; no product code is touched. - The spec remains copy-coupled to the wizard. If wizard copy churn continues, a follow-up could add stable `data-testid` hooks to the wizard so the smoke spec stops breaking on wording changes. ## Model Used Claude Fable 5 (Claude Code) ## Pre-submission checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template	2026-08-17 16:31:17 -07:00
Devin FoleyandClaude	9b1fd42ac1	test(grok-local): isolate billing env in usage cost test (#11285) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Local adapters report run output, token use, and cost data. > - The Grok local adapter now reports real token use and cost data. > - Its new billing test must prove the no-key path and the API-key path. > - The no-key assertion used the caller environment without isolation. > - This made the test fail when `XAI_API_KEY` was already set. > - This pull request isolates that environment state in the test. > - The benefit is stable coverage for the cost gate from #10433. ## Linked Issues or Issue Description Refs #10433 **What happened?** The Grok local usage and cost test asserted subscription billing while it still used the ambient process environment. If `XAI_API_KEY` was set before the test ran, the adapter selected API billing instead. The subscription assertion could then fail on a developer machine or a CI runner with provider credentials. **Expected behavior** The test should prove the subscription path with no `XAI_API_KEY`. It should also prove the API billing path with a test key. **Steps to reproduce** 1. Start from `master` after #10433. 2. Set `XAI_API_KEY` in the shell environment. 3. Run `vitest` for `packages/adapters/grok-local/src/server/execute.test.ts`. 4. Observe that the subscription half can take the API billing branch without test isolation. **Paperclip version or commit** `master` after #10433. **Deployment mode** Built from source. ## What Changed - Isolated `XAI_API_KEY` with save, delete, set, and restore logic around both billing assertions. - Gave the subscription and API billing checks separate run ids and temp roots. ## Verification - `XAI_API_KEY=ambient-test-key corepack pnpm exec vitest run packages/adapters/grok-local/src/server/execute.test.ts` - `corepack pnpm --filter @paperclipai/adapter-grok-local typecheck` ## Risks Low risk. This changes test setup only. It does not change Grok local adapter runtime behavior. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used OpenAI GPT-5 Codex local coding agent. The agent used shell tools, GitHub CLI, and local test execution. The context window size was not exposed in this run. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Claude <noreply@paperclip.ing>	2026-08-13 13:58:05 -07:00
Devin Foley	a09d7dcc06	feat(ui): bounce cold arrivals off archived company URLs, add Unarchive (#11302) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Archiving a company hides it from the sidebar switcher, but remembered last-visited paths, browser history, bookmarks, and restored tabs keep depositing users onto its URLs long after archiving > - Since the selection ping-pong fix (#11300) those arrivals render, but the user is stranded inside a workspace the sidebar refuses to show — and unarchiving had no UI anywhere, so the only way back was a hand-typed settings URL > - This pull request bounces cold arrivals at archived company URLs to an active company (with a toast naming why), lets deliberate visits stick, and adds an Unarchive action to the companies list > - The benefit is that stale URLs stop stranding users in retired workspaces, and archived companies become restorable from the one page that still lists them ## Linked Issues or Issue Description Follow-up to #11300. No existing issue for the remaining gap; description follows the enhancement template: **What happened?** After #11300, opening an archived company's URL (stale tab, history, bookmark, remembered path) renders that company's pages — but the sidebar switcher does not list it, so the user is stranded in a workspace they retired, and every stale URL pulls them back in. Separately, unarchiving a company has no UI: the archive button lives in company settings, which becomes unreachable through normal navigation once the company is archived. **Expected behavior** Arriving cold at an archived company's URL lands the user in an active workspace, with a toast explaining the redirect. Explicitly choosing the archived company (from the companies list) still works, so its pages remain reachable. Archived companies can be restored from the companies list. **Steps to reproduce** 1. Create two companies; archive one. 2. Open `/{archivedPrefix}/dashboard` directly — before: renders the archived workspace with no sidebar presence; after: bounces to the active company's dashboard with a toast. 3. On the companies list, open the archived company's row menu — before: no restore action anywhere; after: Unarchive. ## What Changed - `ui/src/lib/company-selection.ts`: `resolveArchivedCompanyBounce` — pure policy: bounce when the URL names an archived company that is not the current selection and an active company exists; prefer the currently selected active company as the destination. - `ui/src/components/Layout.tsx`: the route-sync effect applies the bounce (toast + selection + `replace` navigation) before syncing selection from the route. - `ui/src/pages/Companies.tsx`: Unarchive action (`PATCH status: "active"`) in the row menu for archived companies. - Tests: unit cases for the bounce policy; the e2e now drives all three behaviors (direct-load bounce with toast, re-arrival bounce, deliberate visit sticks) on top of the existing crash regression. ## Verification - `pnpm vitest run src/lib/company-selection.test.ts src/context/CompanyContext.test.tsx src/pages/Companies.test.tsx` in `ui/` — 20 tests pass. - `npx playwright test --config tests/e2e/playwright.config.ts archived-company-url` — passes, covering bounce, toast, and deliberate-visit paths. - `pnpm typecheck` in `ui/` — clean. ## Risks Low risk. The bounce only fires for archived-company URLs when the archived company is not already selected and an active company exists; all-archived instances render as before. Deliberate selection from the companies list is unaffected (selection equals the matched company, so no bounce). Unarchive reuses the existing `PATCH /api/companies/:id` status transition the server already supports. ## Model Used - Claude (Anthropic), Claude Fable 5 (`claude-fable-5`), via Claude Code CLI with extended thinking and tool use (code search, edit, test execution, Playwright e2e). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-12 21:02:12 -07:00
Devin Foley	d24a79f741	ci(dependabot): surface major npm updates as one grouped weekly PR (#11307) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Dependabot keeps the npm dependency tree and the GitHub Actions workflows current with weekly update PRs > - The npm config ignores every major version bump with a wildcard `ignore` rule, and no other process reports pending majors > - Major-version debt grows silently, and ignore rules also suppress Dependabot security updates when the fix ships only in a newer major > - Individual major PRs are not a good replacement: the board decided in #7560 to keep the PR list mergeable, and a flood of breaking bumps works against that > - This pull request removes the blanket ignore and groups all pending majors into one weekly PR, while minors and patches keep one PR per bump > - The benefit is a standing, visible signal of pending major updates, at a cost of at most one extra PR per week ## Linked Issues or Issue Description **What existing behavior does this improve?** The Dependabot npm update flow configured in `.github/dependabot.yml`. **Current behavior** Dependabot opens weekly PRs for minor and patch npm updates. A wildcard `ignore` rule suppresses every major version update. No report or reminder replaces the suppressed PRs — the comment says "review those manually", but nothing triggers that review. Ignore rules also apply to Dependabot security updates, so a security fix that ships only in a newer major is suppressed as well. **Proposed behavior** Dependabot opens one grouped weekly PR that contains every pending major npm update. Minor and patch updates keep their current one-PR-per-bump flow. A deliberate hold on a specific major can use a targeted per-dependency `ignore` entry instead of the wildcard. **Reason and benefit** Silent major-version drift compounds: each skipped major makes the eventual upgrade jump larger and riskier, especially across peer-dependency families. A single grouped PR makes the backlog visible in the PR list without flooding it. When the grouped PR is green, it merges cheaply. When it is red, it is a visible standing task instead of invisible debt. **Breaking changes** None. This changes repository automation only. Runtime behavior, response shapes, and outputs are unchanged. **Additional context** Related history: #7483 grouped patch/minor updates by dependency type, and #7560 reverted that grouping because the resulting 26-package PR was hard to merge. This PR does not touch the patch/minor flow. It only groups majors, which currently produce no PRs at all — it adds a signal that does not exist today rather than replacing individually mergeable PRs. ## What Changed - Removed the wildcard `ignore` rule for `version-update:semver-major` from the npm ecosystem in `.github/dependabot.yml`. - Added a `major-updates` group (`applies-to: version-updates`, `update-types: ["major"]`, `patterns: ["*"]`) so all pending majors land in one weekly grouped PR. - Left the schedule, labels, PR limits, and the github-actions ecosystem unchanged. ## Verification - `npx js-yaml .github/dependabot.yml` parses cleanly and the `groups` stanza follows the Dependabot v2 schema (`applies-to`, `update-types`, `patterns`). - After merge: check Insights → Dependency graph → Dependabot for config errors. The next weekly run (Monday 06:00) opens a single `major-updates` grouped PR that lists the pending majors. - No code changed, so the test suite is unaffected. ## Risks - Low risk. This is CI/automation configuration only. - The first grouped PR may be large, and red if several majors break the build. That is the intended visibility mechanism, and it does not block other work. A noisy or deliberately held-back dependency can be excluded from the group with `exclude-patterns` or a targeted per-dependency `ignore` entry. - This does not regroup minors or patches, so it does not reintroduce what #7560 reverted. ## Model Used - Claude Fable 5 (Anthropic), model ID `claude-fable-5`, via Claude Code CLI, extended thinking and tool use enabled. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [ ] I have run tests locally and they pass — N/A, YAML-only CI config change; validated with `js-yaml` - [ ] I have added or updated tests where applicable — N/A, no code changed - [x] I have updated relevant documentation to reflect my changes — none reference the Dependabot config - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green — one e2e shard flaked on an unrelated MCP UI spec and passed on re-run with identical code - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-12 21:00:41 -07:00
Devin Foley	61a5b7c6f9	fix(ui): stop the selection ping-pong on archived company URLs (#11300) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The UI keeps a selected company in `CompanyProvider` with two writers: a bootstrap effect that repairs invalid selections, and a Layout route-sync effect that selects the company the URL prefix names > - The route-sync matches the URL against the full company list (archived included), while the bootstrap resolver only accepted companies from the sidebar-filtered non-archived list > - On any archived company's URL the two effects overwrite each other's selection in a synchronous loop until React throws error #185 ("Maximum update depth exceeded") and unmounts the root to a blank page — armed by remembered last-visited paths, back/forward navigation, or bookmarks, on first load and client navigation alike > - This pull request makes an already-selected company only need to exist, keeping the sidebar filter for fresh-boot resolution where no explicit selection exists > - The benefit is that archived company URLs render instead of blanking the entire app ## Linked Issues or Issue Description No existing issue. Description follows the bug template: **What happened?** Opening (or back-navigating to) a URL whose company prefix belongs to an archived company blanked the whole app with `Minified React error #185`. Console in dev mode: "Maximum update depth exceeded. This can happen when a component calls setState inside useEffect…". A workspace whose first/seeded company was archived hit this on every load of its remembered URL. **Expected behavior** An archived company's URL renders its pages (the company still exists and its API routes serve data). The sidebar simply does not feature archived companies, and fresh boots still land on a non-archived company. **Steps to reproduce** 1. Create two companies; archive one (`PATCH /api/companies/:id` with `status: "archived"`). 2. Navigate to `/{archivedPrefix}/dashboard` — direct load or client-side back-navigation. 3. Before this fix: React #185 and an unmounted blank page (reproduced deterministically by the new e2e test). ## What Changed - `ui/src/context/CompanyContext.tsx`: `resolveBootstrapCompanySelection` keeps an explicitly selected company that exists in the full company list; stored-id and default resolution still prefer sidebar (non-archived) companies. - `ui/src/context/CompanyContext.test.tsx`: resolver keeps an archived-but-existing selection; a truly deleted selection is still replaced. - `tests/e2e/archived-company-url.spec.ts`: end-to-end regression driving both field shapes (direct load and back-navigation onto an archived company URL); it failed with the exact #185 console errors before the fix and passes after. ## Verification - `pnpm vitest run src/context …` in `ui/` — 122 tests pass (includes the new resolver cases). - `npx playwright test --config tests/e2e/playwright.config.ts archived-company-url` — fails before the fix (captured "Maximum update depth exceeded" console errors), passes after. - `pnpm typecheck` in `ui/` — clean. ## Risks Low risk. The only behavioral change is that a selection naming an archived-but-existing company survives the bootstrap repair — previously that state was unreachable without crashing. Boots with no valid selection behave exactly as before (non-archived preferred), covered by the existing and new resolver tests. ## Model Used - Claude (Anthropic), Claude Fable 5 (`claude-fable-5`), via Claude Code CLI with extended thinking and tool use (code search, edit, test execution, Playwright-driven crash reproduction). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-12 15:40:33 -07:00
Devin Foley	ff5fd62d07	Resolve the environment secret companyId context on first save (#11291) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Environments give agent runs an execution target, and their env vars can carry secrets, so writes need a company scope for secret bindings > - `PATCH /environments/:id` resolves that scope from a query param, existing bindings, or a single-membership actor — and fails closed otherwise > - A fresh environment has no bindings yet, so an admin whose memberships cannot pin one company gets a 422 on the very first env var save and can never create the first binding > - #11200 made this reachable from the UI: it opened the envVars-only edit on the managed sandbox row, but the UI never sends the company it already knows > - This pull request sends the page's selected company on environment updates and adds a server fallback to the instance's only company > - The benefit is that the first env var save works on fresh environments, while multi-company ambiguity still fails closed ## Linked Issues or Issue Description Refs #11200 **What happened?** On a fresh platform-managed sandbox environment, the first "Save environment variables" in the UI fails with HTTP 422: "Environment secret management requires a companyId context during the instance-scoped transition." The same failure hits any environment update that touches `envVars` or `config` when the environment has no secret bindings yet and the actor's memberships do not name exactly one company (for example an instance admin provisioned without a membership row, or a user in two companies). **Expected behavior** The save succeeds. The client tells the server which company scopes the secret bindings, and on a single-company instance the server can resolve the only possible scope by itself. **Steps to reproduce** 1. Provision a platform-managed sandbox environment (managed-config `environments` entry) so the row exists with no secret bindings. 2. Sign in as an instance admin whose memberships do not resolve to exactly one company. 3. Open Environments, edit the managed row, add an env var, and save. 4. The PATCH returns 422 with the companyId-context error. ## What Changed - `ui/src/api/environments.ts`: `environmentsApi.update` accepts an optional `companyId` and sends it as the `companyId` query param the server already reads. Renamed the `customImageCompanyQuery` helper to `companyIdQuery` since it now serves plain updates and probes too. - `ui/src/pages/CompanyEnvironments.tsx`: both the managed envVars-only save and the general environment save pass `selectedCompanyId`. - `server/src/routes/environments.ts`: `resolveEnvironmentSecretContextCompanyId` falls back to the instance's only company when exactly one exists, mirroring the existing fallback in `resolveCustomImageCompanyId`. Multi-company instances still fail closed. - Tests: three new route tests (explicit query context for a multi-company actor, single-company-instance fallback for a membership-less admin, fail-closed regression on a multi-company instance), and updated the SSH-probe and probe-ambiguity tests for the new fallback. ## Verification - `cd server && pnpm vitest run src/__tests__/environment-routes.test.ts` — 78 pass. - `cd ui && pnpm vitest run src/pages/CompanyEnvironments.test.tsx` — 22 pass. - Full `server` and `ui` vitest suites and `tsc --noEmit` on both packages pass locally. - Manual: on a managed instance, edit the managed sandbox environment, add an env var, save. Before: 422. After: the save persists and the PATCH carries `?companyId=`. ## Risks - Low risk. The explicit query param path already existed on the server; the UI now uses it. - Behavioral shift: on single-company instances, environment secret-context resolution (including `POST /environments/:id/probe`) now resolves the only company instead of returning no context. That lets probes resolve secret-backed config where they previously returned a 422 asking for an explicit companyId. Multi-company instances keep the fail-closed behavior, covered by a regression test. - Self-hosted single-company instances gain the same first-save fix; no schema or config changes. ## Model Used Claude Fable 5 (`claude-fable-5`, Anthropic) via Claude Code — extended thinking, agentic tool use. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-12 11:32:15 -07:00
Devin Foley	c57c0f7498	fix(sandbox-providers): accept bsdtar listings in the syncOut tarball confinement check (#11289) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Sandbox providers (Daytona, Kubernetes) sync run results back to the host with a sandbox-authored tarball > - Before extraction, a confinement check parses the host `tar -tvf` listing and fails closed on unparseable lines > - The parser only understands the GNU tar listing dialect; macOS ships bsdtar, whose ls-style listing never matches > - Every sandbox syncOut on a macOS host therefore aborts with "refusing tarball with an unparseable entry listing", and the run fails at copy-back > - This pull request teaches the parser both dialects while keeping the fail-closed and traversal guarantees > - The benefit is that Daytona and Kubernetes sandbox runs work on macOS hosts, with no behavior change on Linux ## Linked Issues or Issue Description No existing issue. Bug description: **What happened?** On a macOS host, every Daytona sandbox run fails at syncOut. The adapter reports: `Daytona syncOut refusing tarball with an unparseable entry listing: -rw-r--r-- 0 daytona daytona 7560 Aug 11 21:43 AGENTS.md`. The Kubernetes provider has the same parser and fails the same way. **Expected behavior** The confinement check accepts a well-formed listing from the host tar, whichever dialect the host tar emits. It still rejects members that escape the extraction directory, and it still fails closed on lines it cannot parse. **Steps to reproduce** 1. Run Paperclip on macOS (system tar is bsdtar). 2. Configure an agent with the Daytona sandbox provider. 3. Trigger any run that syncs files back from the sandbox. 4. The run fails at syncOut with the unparseable-entry-listing error, because bsdtar prints `<perms> <links> <user> <group> <size> <Mon> <day> <time|year> <name>` while the parser expects the GNU `<perms> <owner>/<group> <size> <date> <time> <name>` shape. **Operating system** macOS (bsdtar 3.5.3). Linux hosts with GNU tar are unaffected. ## What Changed - Extracted the listing-line parse in both providers' `file-sync.ts` into an exported `parseTarVerboseListingLine` that accepts the GNU/busybox dialect and the bsdtar (libarchive) dialect. - The GNU shape now requires the slash-joined `<owner>/<group>` field. This keeps the two shapes mutually exclusive. Without it, a bsdtar line with numeric uid/gid satisfies the loose GNU pattern shifted by one field, which would hide a leading `../` from the traversal check. - Unparseable lines still fail closed. This includes device-node entries, whose size column is `major,minor` in both dialects. - Made the path-traversal fixture in the Daytona suite portable: GNU spells member renaming `--transform`, bsdtar spells it `-s`. - Added a Daytona test that refuses a sandbox-authored tarball carrying a symlink whose target escapes the extraction dir. - Added parser unit tests for both dialects (file, dir, symlink, hardlink, numeric owner, year-form dates, fail-closed lines) to both providers' suites. ## Verification - `pnpm test` in `packages/plugins/sandbox-providers/daytona`: 136/136 pass on a macOS host. On unpatched `master` the round-trip test fails there with the unparseable-entry-listing error. - `pnpm test` in `packages/plugins/sandbox-providers/kubernetes`: the new parser tests pass; no new failures against the `master` baseline on the same host. - `pnpm typecheck` passes in both packages. - CI runs the same suites on Linux/GNU tar and proves the GNU path is unchanged. ## Risks - Low risk. The GNU pattern is one token stricter (`<owner>/<group>` must contain `/`). GNU and busybox tar always print the slash-joined owner field, so accepted GNU listings are unchanged. - The bsdtar branch only widens acceptance on hosts that were failing 100% of syncOuts before, so no working deployment changes behavior. - The check still fails closed on anything neither pattern matches. ## Model Used Claude Fable 5 (`claude-fable-5`, Claude Code CLI, extended thinking + tool use). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-12 11:24:11 -07:00
Devin Foley	01112c350c	fix(ui): always give respondWith a real Response in the sw fetch fallback (#11292) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The UI registers a service worker (`ui/public/sw.js`) with a network-first fetch handler whose cache is an offline fallback > - The fallback hands `event.respondWith` the result of `caches.match(...)`, which resolves `undefined` on a cache miss — and in the navigation branch, `caches.match("/") || offlineResponse` never uses the fallback because `caches.match` returns a promise, which is always truthy > - When the network fetch rejects (server restart, deploy, brief outage) and the cache misses, the browser fails the request with `Uncaught (in promise) TypeError: Failed to convert value to 'Response'`, so navigation breaks outright instead of degrading to the offline page > - This pull request awaits the cache lookups and guarantees a real `Response` on every path > - The benefit is that brief server unavailability degrades to the offline fallback instead of a dead navigation ## Linked Issues or Issue Description No existing issue. Description follows the bug template: **What happened?** Navigating while the server was briefly unavailable (mid-restart) produced `The FetchEvent for "…" resulted in a network error response: the promise was rejected.` and `sw.js:1 Uncaught (in promise) TypeError: Failed to convert value to 'Response'.` The navigation failed instead of showing the offline fallback. **Expected behavior** A failed navigation serves the cached app shell when present, otherwise the "Offline" 503 response. A failed asset fetch serves its cache entry when present, otherwise a proper network-error response. `respondWith` always receives a real `Response`. **Steps to reproduce** 1. Load the app so `sw.js` is active; ensure `/` is not in the service worker cache (fresh cache version). 2. Restart or stop the backend. 3. Navigate to any page: the fetch rejects, `caches.match` misses, and the browser logs the conversion TypeError with a failed navigation. ## What Changed - `ui/public/sw.js`: the fetch fallback awaits `caches.match(...)` and returns the "Offline" 503 for navigations and `Response.error()` for assets when the cache misses. - `ui/src/lib/sw-offline-fallback.test.ts`: evaluates the real `sw.js` in a sandboxed scope and covers the three fallback paths; the two miss-path tests fail against the previous code. ## Verification - `pnpm vitest run src/lib/sw-offline-fallback.test.ts` in `ui/` — 3 tests pass. - Verified both miss-path tests fail against the unmodified `sw.js`. ## Risks Low risk. The change only affects the fetch-rejection path; successful fetches and cache hits behave exactly as before. `Response.error()` mirrors what the browser would produce for an unhandled failed no-cors fetch. ## Model Used - Claude (Anthropic), Claude Fable 5 (`claude-fable-5`), via Claude Code CLI with tool use (code search, edit, test execution). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-12 11:23:18 -07:00
Devin Foley	2c53437fc9	fix(server): authenticate cloud-proxied browsers on the live-events websocket (#11290) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The UI receives live run/issue events over a websocket at `/api/companies/:id/events/ws`; the server authorizes upgrades with a bearer token or a Better Auth session > - On a cloud-managed deployment, browsers authenticate through trusted `x-paperclip-cloud-*` headers injected by the managing front door — they never hold a local Better Auth session, and the Express middleware lane that understands those headers is not consulted for websocket upgrades > - Every browser websocket upgrade behind the front door therefore resolves no identity and is rejected 403: the live-events socket has never connected on a managed instance, leaving permanent reconnect churn and console failure noise while the UI silently degrades to polling > - This pull request adds a cloud-actor lane to the upgrade authorization, reusing the same trusted-header resolver the HTTP middleware uses > - The benefit is working realtime updates on managed instances, an end to the reconnect churn, and unchanged self-hosted behavior ## Linked Issues or Issue Description No existing issue. Description follows the bug template: **What happened?** On a cloud-managed instance, the browser console shows `WebSocket connection to 'wss://…/api/companies/<id>/events/ws' failed:` repeating indefinitely for every company, on a healthy instance. The server rejects each upgrade with 403 because `authorizeUpgrade` in `server/src/realtime/live-events-ws.ts` only knows bearer tokens and Better Auth sessions, while cloud-proxied browsers authenticate via `x-paperclip-cloud-*` trusted headers (handled only by the Express `actorMiddleware` lane in `server/src/middleware/auth.ts`). **Expected behavior** A browser that authenticates through the trusted cloud headers can open the live-events websocket for any company in its membership scope, exactly as it can call the HTTP API for those companies. **Steps to reproduce** 1. Run Paperclip in `authenticated` mode behind a proxy that injects the `x-paperclip-cloud-*` headers with a valid `PAPERCLIP_CLOUD_TENANT_SERVER_TOKEN`. 2. Load any company page in a browser (no local Better Auth session). 3. HTTP API calls succeed; every `/events/ws` upgrade is rejected 403 and the UI retries forever. ## What Changed - `server/src/middleware/auth.ts`: `resolveCloudTenantActor` now accepts a minimal `CloudActorHeaderSource` (`header(name)`) instead of an Express `Request` — `Request` satisfies it unchanged — plus `cloudActorHeaderSourceFromHeaders` to adapt raw `IncomingMessage.headers`. - `server/src/realtime/live-events-ws.ts`: `authorizeUpgrade` gains an injected `resolveCloudActor` lane, tried before the Better Auth session fallback in `authenticated` mode. A resolved cloud actor is authoritative: the upgrade is authorized only for a company in the actor's membership scope (`companyIds`, the same scope the HTTP lane grants). Absent/unresolvable cloud headers fall through to the session path. - `server/src/index.ts`: wires `resolveCloudActor` through `resolveCloudTenantActor` + the header shim. The resolver self-gates: without `PAPERCLIP_CLOUD_TENANT_SERVER_TOKEN` and a matching trust token it returns null, so self-hosted deployments never take this path. - Tests: upgrade authorized for an in-scope company (session resolver not consulted), rejected for an out-of-scope company, fall-through to session auth when no cloud actor resolves; header-shim resolution from a raw lowercased header map including `string[]` values. ## Verification - `pnpm vitest run server/src/__tests__/live-events-ws.test.ts server/src/middleware/cloud-tenant-actor.test.ts` — 25 tests pass. - `pnpm typecheck` in `server/` — clean. - Not verified live end-to-end: that requires a managed instance running this build; the direct probe evidence (HTTP authenticated fine, every WS upgrade 403) matches the code path exactly. ## Risks Low risk. The new lane only activates when the deployment configures the cloud trust token and the request presents it; both checks already protect the HTTP lane. Authorization scope is the same `companyIds` set the HTTP middleware computes (primary stack company plus the user's real membership rows). The cloud resolver's user/company materialization writes are debounced (existing behavior shared with the HTTP lane), so websocket reconnect storms do not amplify database writes. Self-hosted instances see no behavioral change, covered by the fall-through test. ## Model Used - Claude (Anthropic), Claude Fable 5 (`claude-fable-5`), via Claude Code CLI with extended thinking and tool use (code search, edit, test execution; diagnosis included live websocket handshake probes against a managed instance). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-12 11:22:50 -07:00
Devin Foley	f16071a290	fix(ui): use a fictional tailnet hostname in the vite proxy test (#11248) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The UI dev server proxies `/api` to the backend and injects `x-forwarded-host`; a unit test asserts that injection with a sample Host header > - The sample Host header is a contributor's real machine and tailnet hostname, committed to the public repository > - Real personal hostnames do not belong in a public codebase, and this one also contains the contributor's OS username, so `scripts/check-forbidden-tokens.mjs` (which forbids the local username) blocks `npm` publishing from that contributor's machine > - This pull request replaces the fixture with a fictional tailnet-style hostname > - The benefit is no personal identifiers in the test fixtures and a passing forbidden-token check for every contributor ## Linked Issues or Issue Description No existing issue. Description follows the bug template: **What happened?** `ui/src/lib/vite-api-proxy.test.ts` uses a real contributor dev-machine hostname as its `Host` header fixture. `node scripts/check-forbidden-tokens.mjs` fails on that contributor's machine because the hostname contains their OS username, blocking the publish flow. Introduced in #10718. **Expected behavior** Test fixtures use fictional hostnames. The forbidden-token check passes on every contributor machine. **Steps to reproduce** 1. On a machine whose OS username appears in the fixture hostname, run `node scripts/check-forbidden-tokens.mjs`. 2. The check reports the two lines in `ui/src/lib/vite-api-proxy.test.ts` and blocks with exit code 1. ## What Changed - `ui/src/lib/vite-api-proxy.test.ts`: the `Host` fixture is now `dev-box.tail1234.ts.net:3101` (fictional). The test only asserts that whatever host arrives is injected as `x-forwarded-host`, so the value is arbitrary. ## Verification - `pnpm vitest run src/lib/vite-api-proxy.test.ts` in `ui/` — 5 tests pass. - `node scripts/check-forbidden-tokens.mjs` — "No forbidden tokens found" on the previously affected machine. - Note: git history retains the old value; this removes it from the current tree only. ## Risks None. A test fixture string with no behavioral coupling. ## Model Used - Claude (Anthropic), Claude Fable 5 (`claude-fable-5`), via Claude Code CLI with tool use. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-11 19:27:31 -07:00
Devin Foley	d90f4d488e	fix(ui): survive first load against a cold backend without a blank page (#11246) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The web UI holds live websocket connections for run events, coordinates cross-tab polling through a leader-election store, and renders app chrome (sidebar, providers) around a routed outlet > - When the backend is still cold-starting (managed hosting wake, server restart, reverse proxy up before the app), the event websockets refuse connections and the first SPA load mounts against a dead backend > - In that state the mount cascade can exceed React's nested update limit (minified error #185); the crash originates in shell hooks outside the routed error boundary, so React unmounts the entire root to a blank page, and the dead page keeps retrying the websocket on a flat 1.5s timer until the user hard-refreshes > - This pull request removes the wasted nested commits from the shared-polling subscription path, adds exponential backoff to the transcript websocket reconnect, and adds a last-resort app-shell error boundary > - The benefit is that a cold or briefly unreachable backend degrades to a recoverable state instead of a blank page that hammers the server ## Linked Issues or Issue Description No existing issue. Description follows the bug template: **What happened?** On the first load against a backend that was still starting, the app showed its loading animation and then a blank page. The console showed repeated `WebSocket connection to 'wss://…/api/companies/<id>/events/ws' failed` lines and `Uncaught Error: Minified React error #185` with a stack through the shared-polling coordinator's `subscribe`. The websocket retries continued indefinitely on the dead page. A manual refresh fixed it. **Expected behavior** A backend that is briefly unreachable degrades gracefully: websocket reconnects back off, the UI keeps rendering from cache, and even a worst-case crash shows a reload prompt instead of a blank page. **Steps to reproduce** 1. Serve the UI while the backend API is still starting (websocket upgrades and API calls refused). 2. Load any company page with several shared-polling consumers mounted (dashboard with sidebar). 3. Observe repeated websocket failures; on affected loads the page goes blank with React error #185. ## What Changed - `ui/src/hooks/useSharedPolling.ts`: coordinator snapshot notifications now keep the previous state object when leadership did not change, so React bails out instead of scheduling a nested re-render. `subscribe` invokes its listener synchronously from inside the mount effect with a fresh object each time; before this change every mount and notify burned nested-update budget even with no value change — the crash frame in the field report was exactly this `subscribe → setState` call. - `ui/src/components/transcript/useLiveRunTranscripts.ts`: the live event websocket reconnect backs off exponentially (1.5s → 15s cap, reset on successful open), mirroring `LiveUpdatesProvider`, instead of a flat 1.5s retry. - `ui/src/components/AppErrorBoundary.tsx` (+ wiring in `ui/src/main.tsx`): a dependency-free boundary above the router and providers. `RouteErrorBoundary` only guards the routed `<Outlet />`; a crash in the shell around it had no boundary, so React unmounted the root to a blank page. The boundary renders a reload prompt with the error message. - Tests: `useSharedPollingSnapshot.test.tsx` (mount costs no extra commit — fails against the previous code; a real leadership change re-renders exactly once and ticks stay quiet), a backoff test in `useLiveRunTranscripts.test.tsx` (delays grow 1.5s → 3s → 6s and reset after a successful open), and `AppErrorBoundary.test.tsx` (render throw, effect throw, healthy pass-through). ## Verification - `pnpm vitest run` in `ui/` over the touched suites (shared polling, cross-tab poll, transcripts, boundary): 34 tests pass. - `pnpm typecheck` in `ui/` — clean. - The snapshot regression test was verified to fail against the pre-change hook (extra commit per mount). - Not reproduced end-to-end: the exact 50-update cascade from the field crash needs a live cold backend; the change removes the identified per-mount/per-notify nested commits at the reported crash frame, bounds the reconnect load, and guarantees the shell can no longer blank the page. ## Risks Low risk. The snapshot change only suppresses re-renders whose state is value-identical; leadership changes propagate exactly as before. The backoff only lengthens retry delays after consecutive failures and resets on success. The new boundary renders children untouched unless an error reaches it; behavior on healthy loads is unchanged. Self-hosted deployments see the same code paths — the cold-backend window simply rarely occurs there. ## Model Used - Claude (Anthropic), Claude Fable 5 (`claude-fable-5`), via Claude Code CLI with extended thinking and tool use (code search, edit, test execution; diagnosis included mapping the production minified stack to source). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-11 19:16:19 -07:00
Devin Foley	9adeb4a9d0	fix(ui): fetch the web app manifest with credentials (#11245) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The web UI is a PWA-capable SPA; `ui/index.html` links `/site.webmanifest` so browsers can read app metadata > - Browsers fetch `<link rel="manifest">` in "omit credentials" mode unless the link opts in with `crossorigin="use-credentials"` > - Self-hosted this is harmless, but when Paperclip runs behind an authenticating reverse proxy (a managed hosting front door), the cookie-less manifest request is rejected with 401 on every page load and logs a console error pair on each navigation > - This pull request adds `crossorigin="use-credentials"` to the manifest link so the request carries the same session cookies as every other same-origin asset request > - The benefit is a clean console and a servable manifest in proxied deployments, with self-hosted behavior unchanged ## Linked Issues or Issue Description No existing issue. Description follows the bug template: **What happened?** On every page load behind an authenticating reverse proxy, the browser logs `Failed to load resource: the server responded with a status of 401` for `/site.webmanifest`, plus `Manifest fetch from … failed, code 401`. The proxy rejects the request because the browser sends the manifest fetch without cookies. **Expected behavior** The manifest request carries the same session credentials as every other same-origin asset request, so the proxy can authenticate and serve it. No console errors. **Steps to reproduce** 1. Serve Paperclip behind a reverse proxy that requires a session cookie for all app routes. 2. Sign in and load any page. 3. Open the browser console: the manifest fetch fails with 401 while all other assets load. ## What Changed - `ui/index.html`: the manifest link now carries `crossorigin="use-credentials"`. - `ui/src/lib/pwa-install-mode.test.ts`: a regression test asserts the attribute stays on the link. ## Verification - `pnpm vitest run src/lib/pwa-install-mode.test.ts` in `ui/` — 2 tests pass. - Manual check of the rendered link tag in `ui/index.html`. ## Risks Low risk. The manifest is same-origin, so `use-credentials` only switches the fetch from "omit" to the include behavior all other same-origin requests already have. Self-hosted deployments see no change. Cross-origin manifest hosting is not used in this project. ## Model Used - Claude (Anthropic), Claude Fable 5 (`claude-fable-5`), via Claude Code CLI with extended thinking and tool use (code search, edit, test execution). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-11 19:11:56 -07:00
Devin Foley	d5bb396518	fix: pass sandbox provider credential env vars to plugin workers; hide Local default under managed-sandbox-only (#11244) ... <!-- Write all pull request text in Simplified Technical English (ASD-STE100): short sentences, one instruction per sentence, simple approved vocabulary, and the active voice. --> ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Environments give each agent run an execution target, and sandbox providers (Daytona, E2B, Novita, exe.dev) run as plugin workers > - A managed deployment provisions one platform-managed sandbox row with no credential in config; the provider is documented to fall back to its process env var (for example `DAYTONA_API_KEY`) > - Plugin workers spawn with a scrubbed environment, so that fallback never sees the host env var — probe and lease acquisition fail with "require an API key in config or DAYTONA_API_KEY" even when the deployment sets the var > - Separately, the managed-sandbox-only mode hides local rows from every list, but the instance Default picker renders a hardcoded synthetic "Local" option that no filter touches > - This pull request forwards each bundled provider's documented credential env var to its own plugin worker, and gates the synthetic Local option on the flag > - The benefit is that the documented host-env credential fallback works for plugin-backed providers, and managed-sandbox-only instances no longer offer Local anywhere ## Linked Issues or Issue Description **Subsystem affected** Plugin worker environment construction (`server/src/services/plugin-loader.ts`) and the environments UI (instance Default picker, agent form inherited-environment label). **Problem or motivation** Two follow-ups to the managed-sandbox-only mode (#11200), both found on a live managed deployment: 1. The deployment sets `DAYTONA_API_KEY` as a server env var and the managed sandbox row omits `config.apiKey` by contract. "Test Connection" fails with `Sandbox environment probe failed for provider "daytona". Daytona sandbox environments require an API key in config or DAYTONA_API_KEY.` A real agent run fails the same way at lease acquisition. The cause: sandbox providers run as plugin workers, and `buildPluginWorkerEnv` passes only model-provider keys and in-cluster Kubernetes vars. The provider's own documented credential env var never reaches the worker, so the in-plugin `process.env` fallback reads nothing. The self-hosted path has the same gap: the Daytona plugin README documents `DAYTONA_API_KEY` as a host-level fallback, and it does not work today. 2. With `enableManagedSandboxOnly` on, the instance Default environment picker still shows "Local". The server filters local *rows* out of the list, and the client filter mirrors that for cached lists, but this option is a hardcoded `<option value="">Local</option>` — not a list row — so no filter removes it. Selecting it writes a null default, which run selection then rejects fail-closed. **Proposed solution** Forward each bundled sandbox provider's documented credential env var into its plugin worker, keyed by the manifest's declared `environmentDrivers[].driverKey` so a worker only receives its own provider's credential (daytona → `DAYTONA_API_KEY`, e2b → `E2B_API_KEY`, exe-dev → `EXE_API_KEY`, novita → `NOVITA_API_KEY`). Keep the existing gate: only plugins that declare `environment.drivers.register` receive any passthrough. In the UI, render the synthetic Local option only when managed-sandbox-only is off; under the flag show a disabled "Select environment" placeholder only while no default is stamped yet, and stop the agent form's inherited label from reading "Local". **Alternatives considered** Adding `DAYTONA_API_KEY` to the existing `ADAPTER_ENV_PASSTHROUGH` list was rejected: that list goes to every environment-driver plugin, so each provider would receive every other provider's credential. A manifest schema field for declared credential env vars was rejected as heavier than needed: the bundled providers are known, and the mapping lives next to the two existing passthrough lists. ## What Changed - `server/src/services/plugin-loader.ts`: new `SANDBOX_PROVIDER_CREDENTIAL_ENV_PASSTHROUGH` map (driverKey → documented credential env vars). `buildPluginWorkerEnv` reads the manifest's `environmentDrivers` and forwards only the matching vars, after the existing `environment.drivers.register` gate. Blank values stay excluded. - `server/src/__tests__/plugin-database.test.ts`: the daytona worker receives `DAYTONA_API_KEY` and not another provider's key; a plugin whose drivers have no mapping (kubernetes) receives no credential var. - `ui/src/pages/CompanyEnvironments.tsx`: the Default picker's synthetic Local option renders only when managed-sandbox-only is off. Under the flag, a disabled "Select environment" placeholder renders only while the default is unset. - `ui/src/pages/CompanyEnvironments.test.tsx`: the Local option is present by default and absent under the flag; saved non-local environments stay selectable. - `ui/src/components/AgentConfigForm.tsx`: the inherited-environment label falls back to "Managed sandbox" instead of "Local" under the flag. ## Verification - `server`: `npx vitest run src/__tests__/plugin-database.test.ts -t buildPluginWorkerEnv` — 5 passed (3 existing, 2 new). - `ui`: `npx vitest run src/pages/CompanyEnvironments.test.tsx` — 22 passed (2 new); `npx vitest run src/components/AgentConfigForm.render.test.tsx` — 10 passed. - `tsc --noEmit` clean in `server` and `ui`. - Live managed deployment: confirmed the tenant service env carries `DAYTONA_API_KEY` while the probe fails with the exact message above, which pins the root cause to the worker env, not delivery. ## Risks - The worker env grows by exactly one var per matching bundled provider, only when the deployment sets it and only for plugins that declare a matching environment driver. Plugins without a mapping see no change. - Self-hosted behavioral shift is the fix itself: a host-level `DAYTONA_API_KEY` (or E2B/EXE/NOVITA equivalent) now reaches the provider as its README documents. Deployments that set the var but expected it to stay inert had no working configuration to preserve — the provider errored on every keyless probe and run. - UI change is inert unless `enableManagedSandboxOnly` is on (default false everywhere). ## Model Used Claude Fable 5 (`claude-fable-5`) via Claude Code — extended thinking, tool use, parallel read-only subagents for the two root-cause traces. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-11 19:10:45 -07:00
Devin Foley	0aa743fc30	build(db): clean dist before drizzle generate (#11241) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Database migrations are generated by drizzle-kit, which reads the schema from the db package's built `dist/schema/*.js` > - `tsc` never deletes stale outputs, so a long-lived checkout keeps compiled schema files whose sources were deleted long ago > - A `generate` run in such a checkout sees those ghost tables and sweeps phantom `CREATE TABLE` statements into an unrelated migration > - This pull request makes `generate` clean `dist` before building, so drizzle always diffs against exactly the current schema sources > - The benefit is that no contributor can accidentally resurrect deleted tables inside a new migration ## Linked Issues or Issue Description **What happened?** Running `pnpm --filter @paperclipai/db generate` in a months-old checkout produced a migration re-creating `cloud_upstream_connections`, `cloud_upstream_runs`, and `company_secret_pools` — tables whose schema sources were deleted in #10507. The compiled copies were still in `dist/schema/`, and `drizzle.config.ts` reads the schema from `dist`, so drizzle treated them as new tables missing from the snapshot. **Expected behavior** `generate` diffs the current schema sources only; deleted tables can never reappear in a generated migration. **Steps to reproduce** 1. Build the db package, then delete a schema source file without cleaning `dist`. 2. Run `pnpm --filter @paperclipai/db generate`. 3. The generated migration re-creates the deleted table. ## What Changed - `packages/db/package.json`: the `generate` script runs `pnpm run clean` before `tsc`, so the drizzle-kit input is always a fresh build of the current sources. ## Verification - In a checkout carrying stale `dist/schema/cloud_upstreams.js` / `company_secret_pools.js` artifacts, `generate` produced a phantom migration before this change; after a clean build it reports "No schema changes, nothing to migrate". With this change the clean happens inside `generate` itself. ## Risks - Low risk: `generate` is a developer-only script; the change only adds the existing `clean` step ahead of the existing build, at the cost of a full rebuild per generate. ## Model Used - Claude Fable 5 (`claude-fable-5`) via Claude Code CLI, with extended thinking and tool use. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-11 18:06:04 -07:00
Devin Foley	0a95ada1be	feat(server): chunked import preview endpoint and resumable upload in the Import page and CLI (#11224) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The previous pull request added server-side chunked resumable import transfers; without clients, large imports still ride the single fragile upload > - The Import page and the CLI need to slice large packages, upload parts with retry and progress, resume after interruptions, and preview before applying > - Preview is the missing server piece: the browser flow is preview-then-import, so a completed spool must be previewable without re-uploading > - This pull request adds the transfer preview endpoint, switches the Import page to the chunked path for zips over 48 MB, and teaches the CLI the same for oversized local imports > - The benefit is that large imports get progress, per-part retry, and resume in both clients, while small imports keep the exact single-shot path they have today ## Linked Issues or Issue Description **What happened?** With only the server transfer routes in place, users still upload large company packages as one request from the Import page and the CLI: no progress indication, no retry below the whole file, and no resume after a dropped connection or refresh. The preview-then-import flow also cannot run against an uploaded transfer, forcing a second full upload. **Expected behavior** A large package uploads once as verified parts with visible progress; preview and import both run against the uploaded spool; an interrupted upload resumes with only the missing parts re-sent; packages at or below 48 MB behave exactly as before. **Steps to reproduce** 1. Select a 500 MB zip on the Import page over an unreliable connection. 2. Watch the single upload fail near the end and restart from zero, twice — once for preview, once for import. 3. Same story headless via the CLI. ## What Changed - Server: `POST /import/transfers/:id/preview` runs the existing preview logic against the completed spool (shared assembly + whole-file verification helper with apply); preview neither completes the run nor deletes the spool, so the subsequent apply reuses it. Missing parts respond with the missing list. - UI: zips over 48 MB take the chunked path in both preview and import — the file is sliced into 32 MB parts hashed with WebCrypto (single ArrayBuffer, no second copy), the transfer is created or resumed (the create response's missing-parts list drives what uploads), parts upload sequentially with three attempts each and visible progress, then transfer preview/apply replace the multipart calls. The existing preview pane, collision handling, adapter overrides, and async job polling are unchanged; ≤ 48 MB keeps the single-shot path. - CLI: oversized local `.zip` or folder imports zip/slice/hash with node crypto, upload with resume and per-part retry and progress lines, and use transfer preview/apply. Small packages keep the inline path byte-identical. - Failure honesty: adapters/API errors fail open to existing behavior; a part failing all attempts surfaces a durable error panel with resume intact. ## Verification - Server: preview-then-apply on one spool (run stays open, spool intact, then apply completes), preview with missing parts rejected — added to the transfer route suite (embedded Postgres). - UI suite: large file takes the chunked path (manifest shape, part uploads, progress, apply on a resumed transfer, single-shot endpoints never called), small file stays single-shot, part failure after three attempts surfaces the error panel without running preview, resume re-uploads only the missing part. - CLI: manifest slicing/hashing, threshold behavior for zip and folder sources, folder-zip round-trip through the real zip reader, upload resume/retry/exhaustion/already-completed, full-command chunked and small-zip inline flows. - Server, ui, cli typechecks clean. Exact counts in the PR checks. ## Risks - The 48 MB threshold only routes between two verified paths; behavior below it is untouched. - Chunked CLI imports use the board-scoped transfer routes, so oversized CLI imports need board credentials (agent tokens keep the agent-safe small-file path). No privilege change — board actors already had the generic routes — but the two size regimes differ semantically; called out for review. - A CLI dry-run over the threshold uploads parts before previewing; the spool persists (24 h sweep) and a later apply resumes without re-upload — inherent to preview-against-spool. Stacked on #11223 — merge that first; this PR then shows only the preview endpoint and client changes. ## Model Used - Claude Fable 5 (`claude-fable-5`) via Claude Code CLI, with extended thinking and tool use (multi-agent implementation with independent verification). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-11 16:06:37 -07:00
Devin Foley	23a1b025c2	feat(server): chunked resumable company import transfers (#11223) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Company import moves large packages into an instance, and since the upload cap rose to 1 GB, the transport is the weak point: one HTTP request, buffered fully in memory, with no resume > - A dropped connection at 90% of an 800 MB upload starts the whole transfer over, and a server restart loses all progress > - This pull request adds the server side of chunked resumable import transfers: a durable run ledger and routes that accept the same import zip as verified ~32 MB parts spooled to disk > - An interrupted transfer resumes from the parts already uploaded — across dropped connections, page refreshes, and server restarts — and peak upload memory drops from the whole package to one part > - The benefit is that large imports become reliable on real-world connections instead of all-or-nothing ## Linked Issues or Issue Description **What happened?** Large company imports travel as a single HTTP upload. On a slow or flaky connection, any interruption discards all progress and the upload restarts from zero. The server buffers the entire compressed package in memory during upload. A server restart mid-upload loses the transfer entirely. With the upload cap now at 1 GB, these failure modes govern exactly the imports the cap was raised for. **Expected behavior** A large import upload survives interruptions: already-transferred data is kept and verified, only the missing remainder is re-sent, and the server's memory use during upload is bounded by a part, not the package. **Steps to reproduce** 1. Import a multi-hundred-MB company package over a connection that drops mid-upload. 2. The upload fails; retrying starts from byte zero. 3. Repeat on an unstable connection and the import may never complete. ## What Changed - New `company_transfer_runs` table (drizzle schema + migration) and `companyTransferRunService`: one row per transfer with a content-derived idempotency key, per-part completion recorded atomically and idempotently, resume scoped to actor and direction, completed runs short-circuiting retries of identical content. - New transfer routes beside the existing import routes, same authorization: declare a sliced zip (`POST /import/transfers` — validates cap, 64 MB part ceiling, contiguity, size sums, sha256 format), upload parts (`PUT .../parts/:n` — raw body, hash-and-size verified before an atomic write to a disk spool under the instance root; re-uploads are no-op successes), poll resume state (`GET .../:id` — missing parts recomputed from disk), and apply (`POST .../:id/apply` — requires all parts, re-verifies the assembled zip against the whole-file hash fail-closed, then feeds the existing import pipeline through factored helpers rather than duplicated logic). - Hourly sweep fails and cleans spools idle for 24 h; a swept transfer honestly reports all parts missing on resume. - Strict UUID gating on run ids before any filesystem path construction. - The existing single-shot upload path is untouched; clients arrive in the follow-up PR. ## Verification - Transfer route suite (embedded Postgres): create/upload/status/apply round-trip with a real imported company, out-of-order parts, wrong-hash part rejected and unrecorded, re-upload no-op, apply-with-missing-parts rejection, resume after failure with prior progress intact, assembled-hash mismatch failing closed with spool deletion, actor scoping 404s, async-job apply, sweep followed by honest resume. - Ledger suite (embedded Postgres): part idempotency, actor/direction scoping, completed-run short-circuit, cancelled runs staying cancelled. - Existing portability route suite unchanged and green; server + db typechecks clean. Exact counts in the PR checks. ## Risks - New routes are additive; the existing import path is untouched. The transfer routes carry the same board authorization as the import routes they sit beside. - Disk spool: bounded by the existing upload cap per transfer, cleaned on success, failure, hash mismatch, and by the 24 h sweep. Spool paths are strict-UUID-gated. - The apply step still materializes the assembled zip in memory once (same profile as today's single-shot import at apply time); upload-time memory drops to one part. - Known limitation, deliberate: transfers are keyed on content alone, so identical package content cannot be imported twice without re-exporting (surfaced explicitly to the caller). Acceptable for v1; noted for review. ## Model Used - Claude Fable 5 (`claude-fable-5`) via Claude Code CLI, with extended thinking and tool use (multi-agent implementation with independent verification). ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-11 15:25:07 -07:00
Devin Foley	0044fa8904	Let tenants edit env vars on managed sandbox environments; add managed-sandbox-only mode (#11200) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Environments give each agent run an execution target: the local host, SSH, or a sandbox provider > - A managed deployment can provision one platform-managed sandbox environment through the `PAPERCLIP_MANAGED_CONFIG` `environments` section > - That row is fully locked today. A tenant cannot add environment variables for their agents. There is also no way to hide local execution — run selection falls back to the local row > - A platform that manages the sandbox for its tenants needs both: the tenant adds env vars (and nothing else), and local execution is neither visible nor reachable > - This pull request opens exactly one tenant edit (env vars) on the managed sandbox row, and adds an `enableManagedSandboxOnly` mode that hides local and makes run selection fail closed > - The benefit is a complete managed-sandbox experience with no change for self-hosted instances ## Linked Issues or Issue Description **Subsystem affected** Environments (managed sandbox provisioning, environment routes, run environment selection) and the environments UI. **Problem or motivation** Platform-provisioned sandbox environments (`metadata.managedByPaperclip`) reject every write on cloud-managed instances. Agents often need environment variables inside their sandbox. The tenant has no way to set them on the managed row. Separately, an operator cannot remove local execution: the environment list always shows the local row, and run selection falls back to it when no default is set. **Proposed solution** Allow an envVars-only PATCH on the managed sandbox row, and echo those env vars back for editing. Add a managed-tier feature (`enableManagedSandboxOnly`) that hides the local environment from all read surfaces and redirects local-landing run selection to the managed sandbox environment, failing closed when it is unavailable. **Alternatives considered** UI-only hiding of the local row. This was rejected: it does not stop a run from resolving to local, so it is presentation without enforcement. Full unlock of the managed row was also rejected: name, driver, and config stay platform-owned so boot reconciliation cannot fight tenant edits. ## What Changed - `server/src/routes/environments.ts`: the platform-provisioned write floor admits an envVars-only PATCH on the generalized managed sandbox row (sandbox driver, `managedByPaperclip`, not legacy kubernetes-marker rows). Name, driver, config, status, metadata, and DELETE stay rejected. The read floor stops blanking env vars on that row; credential-shaped config keys stay redacted for every actor. Legacy kubernetes-marker rows keep the full floor. - Same file: under `enableManagedSandboxOnly`, the environments list and the by-id read omit the local row for every actor, including instance admins. - `server/src/services/execution-workspace-policy.ts`: `resolveExecutionWorkspaceEnvironmentId` gains the managed-sandbox-only inputs. A selection that lands on the local environment is redirected to the managed sandbox environment. With no active managed row it throws `ManagedSandboxUnavailableError` — never local. Non-local selections (ssh, user-created sandboxes) are untouched. - `server/src/services/heartbeat.ts`: the run path reads the flag, looks up the managed row (`findManagedSandboxEnvironment`, new read-only finder in `environments.ts`), and passes both to the resolver. Mirrors the forced-kubernetes precedent, which keeps precedence when both regimes are on. - `server/src/services/managed-environments.ts`: after a successful reconcile, the instance default environment moves to the managed sandbox row when the current default is unset, local, or dangling. A tenant-chosen custom environment is never overridden. - `packages/shared`: new `enableManagedSandboxOnly` key (schema default false, catalog tier `managed`, cloudDefault false, selfHostedDefault false) and the matching interface field. - UI: managed rows show a "Managed by Paperclip" lock badge; editing one opens a dedicated env-vars-only editor that sends the one PATCH shape the server admits (the old full form failed with a 403 on save). New `ui/src/lib/managed-sandbox-environment.ts` mirrors the local filter for cached lists (applied in the project picker; the agent picker already excluded local). The experimental settings page gains the toggle at its alphabetical card position. `environmentsApi.update` now declares the `envVars` field it already sent. - Tests: environment route floor coverage (envVars-only accepted, mixed bodies rejected, legacy rows still blanked and locked, local hidden and 404 under the flag, self-hosted unchanged), an embedded-postgres service test pinning that boot reconciliation never touches tenant env vars, resolver redirect/fail-closed cases, managed-environments default-stamping cases, and UI lib/settings tests. ## Verification - `pnpm --filter @paperclipai/server exec vitest run src/__tests__/environment-routes.test.ts src/__tests__/environment-service.test.ts src/__tests__/execution-workspace-policy.test.ts src/services/managed-environments.test.ts` — all pass. - `pnpm --filter @paperclipai/shared exec vitest run` — 425 pass (catalog/schema default parity is pinned by an existing test). - `pnpm --filter @paperclipai/ui exec tsc --noEmit` and the affected UI suites (CompanyEnvironments, InstanceExperimentalSettings incl. card-order test, new lib test) — all pass. - Full workspace `pnpm test`: 3,414 passed. 17 files report failures on this machine; the identical 17 fail on a clean `origin/master` worktree in the same environment (git-worktree/skills/embedded-postgres environment dependencies and plugin-SDK zero-test collections). One additional file (`issue-monitor-scheduler.test.ts`) failed one timing-sensitive test in one of two full-suite runs and passes 7/7 in isolation on this branch — a flake in a domain this diff does not touch. The branch introduces no new failures. - Self-hosted zero-delta: every new behavior is gated on the cloud-managed instance check or the new flag, which defaults to false in schema and catalog; pinned by the "does not floor platform-marked rows on self-hosted instances" and flag-off tests. ## Risks - Behavior is opt-in twice over: the write-floor exception applies only to rows the managed-config provisioner stamps, and the hiding/forcing applies only when `enableManagedSandboxOnly` is on (default false everywhere). Self-hosted instances see no change. - The env-vars echo is scoped to the generalized managed sandbox row; legacy kubernetes-marker rows keep the blanket floor because pre-generalization builds may have written platform values there. - Fail-closed run selection means a managed instance with the flag on and an archived managed row (provider plugin down) refuses runs with a precise error instead of running locally. That is the intended posture. ## Model Used Claude Fable 5 (`claude-fable-5`), extended thinking, agentic tool use via Claude Code CLI. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-11 11:40:57 -07:00
Devin Foley	71e9d6bb0b	feat(release): candidate-branch beta builds and the release checklist (#11209) ... > Follow-up to #11208 (merged): rebased onto master and ready for review. ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The release channels promote artifacts along canary → nightly → beta → stable, with the happy path being promotion of an existing build > - When one or two targeted fixes are needed before a beta or stable, the only options today are waiting for the next nightly or absorbing a whole day of unrelated master changes > - The channel model was designed with an escape hatch for exactly this: short-lived candidate branches carrying only cherry-picked fixes > - This pull request implements candidate-branch beta builds with full verification, documents the stable fix path through the soak-justification gate, and adds the release captain's checklist > - The benefit is that a surgical fix can ship forward without either delay or blast radius, with its provenance recorded ## Linked Issues or Issue Description Refs #11008 — completes the fix-path half of the channel model introduced there. **Subsystem affected** Release automation: `scripts/release.sh`, `.github/workflows/release.yml`, `doc/RELEASING.md`, new `doc/RELEASE-CHECKLIST.md`, tests. **Problem or motivation** Beta promotion only accepts commits that already shipped as a nightly, and stable promotion expects a soaked beta. There is no supported way to ship one or two cherry-picked fixes between lanes: an urgent fix must wait for the nightly cycle or pull in every unrelated master change from the day. The original channel design called for candidate branches to cover this, and they were deferred from the initial implementation. **Proposed solution** Candidate-branch beta builds: cut `candidate/beta-<target>` from a nightly's source commit, cherry-pick the fixes, and dispatch `channel: beta` with the new `candidate_branch` input. Selection enforces the naming convention, rejects heads that already shipped as a beta or predate the candidate tooling, and records the cherry-picked commits in the job summary. Because candidate heads never went through a canary or nightly, publication is gated on a full `release-verify` run (promoted nightlies keep skipping re-verification). The stable fix path (`candidate/release-<target>` as `source_ref`) works through the existing soak gate: the justification requirement is the deliberate, recorded trade-off for shipping unsoaked bits, and is now documented as such. ## What Changed - `scripts/release.sh`: `--from-candidate` flag (beta only) waives the shipped-a-nightly requirement while keeping the duplicate-beta guard - `.github/workflows/release.yml`: `candidate_branch` dispatch input; candidate mode in `select_beta` (naming validation, duplicate and tooling-era rejection, cherry-pick recording); new `verify_beta_candidate` job gating candidate publishes on full verification - `doc/RELEASING.md`: beta fix-path and stable fix-path sections - `doc/RELEASE-CHECKLIST.md` (new): the release captain's checklist for all four lanes as built - Tests: dry-run fixture coverage for `--from-candidate` (waives the nightly guard, keeps the duplicate guard, rejected outside beta) and wiring tests for candidate validation plus the verification gate ## Verification - `node --test` on the four affected suites: 42 pass in total (17 + 25 across the two runs), including the 5 new tests - `bash -n` on `release.sh`; YAML parse of the workflow - After merge: exercise the path end to end the first time a real cherry-picked beta is needed — dispatch with a `candidate/beta-*` branch and confirm the summary records the picks and verification runs ## Risks - Candidate builds bypass the smoke-tested-nightly provenance by design; the compensating controls are full verification before publish, the post-publish beta smoke, the human `npm-beta` gate, and recorded cherry-picks - The stable fix path rides the existing justification mechanism rather than adding a second bypass — one recorded escape hatch, not two ## Model Used Claude Fable 5 (`claude-fable-5`, Anthropic) in Claude Code, with extended thinking and full tool use. All changes model-authored under human direction. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green (pending — will confirm before merge) - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups (pending — will confirm before merge) - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-11 10:05:13 -07:00
Devin Foley	2da6a248c3	fix(release): surface recovery commands when a lane tag push is rejected (#11208) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The release subsystem's promotion lanes publish to npm, then push a lane tag and dispatch the Docker image build at that tag > - The first nightly of the beta-tooling merge published to npm and then died at the tag push: GITHUB_TOKEN may not create refs pointing at workflow-modifying commits from dispatch or scheduled runs > - The failure was a bare `remote rejected` with no guidance, leaving the release half-finished (npm live, no tag, no images) until an operator reverse-engineered the recovery > - This pull request makes every lane's tag push degrade into exact recovery instructions in the job summary > - The benefit is that a rare platform-permission rejection becomes a two-minute runbook operation instead of a forensic exercise ## Linked Issues or Issue Description Refs #11008 — the incident occurred promoting that change's own merge commit, the first workflow-modifying commit to flow through the lanes it introduced. **Subsystem affected** Release automation: `.github/workflows/release.yml`, `doc/RELEASING.md`, workflow wiring tests. **Problem or motivation** Run 31445344811 published `2026.811.0-nightly.0` to npm, then failed pushing `nightly/v2026.811.0-nightly.0`: `refusing to allow a GitHub App to create or update workflow .github/workflows/release.yml without workflows permission`. The tagged commit modifies workflow files, and GITHUB_TOKEN may not create refs pointing at such commits from dispatch or scheduled runs (push-event runs are exempt, which is why the canary tag on the same commit succeeded). The job failed with no explanation and the Docker dispatch never ran. **Proposed solution** Wrap the nightly, beta, and stable tag pushes: on rejection, write the exact recovery commands into the job summary — create and push the tag with maintainer credentials, dispatch `docker.yml` at the tag, and for stable also run `create-github-release.sh` — then fail the job. Document the cause and recovery in the failure playbooks and pin the three recovery blocks with a wiring test. ## What Changed - `.github/workflows/release.yml`: recovery-summary wrappers on the nightly, beta, and stable tag-push steps - `doc/RELEASING.md`: failure-playbook entry for the workflows-permission rejection - `scripts/__tests__/release-verify-workflow.test.mjs`: wiring test asserting all three lanes carry the recovery summary ## Verification - Wiring tests: 6 pass; YAML parse of the workflow - The recovery commands are exactly the ones used to resolve the real incident (tag push + `docker.yml` dispatch for `nightly/v2026.811.0-nightly.0`) ## Risks - Low. The happy path is unchanged (a successful push skips the wrapper); the failure path trades a bare error for actionable output and still fails the job, since the release state is genuinely incomplete ## Model Used Claude Fable 5 (`claude-fable-5`, Anthropic) in Claude Code, with extended thinking and full tool use. All changes model-authored under human direction. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green (pending — will confirm before merge) - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups (pending — will confirm before merge) - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-11 08:48:13 -07:00