2284 Commits

Include renames

Author	SHA1	Message	Date
DottaandPaperclip	ea6c8eb5e1	fix: preserve fresh Kubernetes defaults and retire failed setup preparation ... Keep unresolved Kubernetes targets on legacy execution and remove only owned pre-handoff staging roots. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 17:19:19 -05:00
DottaandPaperclip	1173a859ba	Merge master and preserve the repository lockfile policy ... Retain both runner and incoming creator/render controls; preserve generated build-lock evidence separately. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 17:08:57 -05:00
4 people	ba4fac585d	feat(agents): show who created an agent in shared companies (#16055) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - A company in Paperclip can have more than one human member, and each member can create agents > - The app does not record which person created an agent > - When two or more people share a company, members cannot see who added an agent or who to ask about it > - This pull request records the creator of each agent and shows the creator on the agent Overview tab > - The benefit is clear ownership of agents in shared companies, with no change for single-user companies ## Linked Issues or Issue Description No public issue exists. This description follows `feature_request.yml`. **Subsystem affected** Agents: the agent data model, the agent create path on the server, and the agent Overview tab in the board UI. **Problem or motivation** Paperclip does not record which human user created an agent. When more than one human user works in a company, the agent page does not tell members who created the agent. **Proposed solution** Record the user ID of the creator when a human creates an agent. Show "Created by <name>" on the Identity card of the agent Overview tab. Show this row only when the company has two or more human members. Do not count the synthetic local Board principal as a human member. Do not show the local Board as a creator. **Alternatives considered** Count human users across the full instance. We did not do this. An instance-wide count tells a member of one company that other companies have users. The creator is always a member of the agent's company, so the company count is sufficient. **Roadmap alignment** `ROADMAP.md` has no item for agent ownership. This change is small and additive. ## What Changed - Add the nullable column `agents.created_by_user_id` (`packages/db/src/schema/agents.ts`, migration `0343_new_mentor.sql`). - Set the column in the single agent insert path (`server/src/modules/agent-lifecycle/adapters/records.ts`). The value comes from the authenticated user actor. The server ignores a creator value in the request body. Agents that agents or the system create keep `null`. - Backfill existing agents in the migration. The backfill uses the earliest `agent.created` or `agent.hire_created` activity row that a user actor wrote in the same company. - Add `createdByUserId` to the shared `Agent` type (`packages/shared/src/types/agent.ts`). - Add `ui/src/lib/agent-creator.ts`. It decides if the UI shows the creator row and it resolves the creator name. If the creator left the company, the row shows "Former member". - Add the "Created by" row to the Identity card in `ui/src/pages/AgentDetail.tsx`. If the company user directory request fails, the row shows "Could not load creator". The row does not disappear silently. - Add the Storybook story `Pages/Agent Detail → Shared Company Shows Creator`. - Document the column in `doc/SPEC-implementation.md` §7.2. ## Verification - `pnpm --filter @paperclipai/db typecheck` passes. This includes the migration numbering and migration safety checks. - `pnpm --filter @paperclipai/shared typecheck` passes. - `ui`: `tsc --noEmit` passes. - `server`: `vitest run src/modules/agent-lifecycle/__tests__/lifecycle.test.ts` passes (49/49). Two new tests: - The server records the creator from the actor and ignores a creator value in the request body. - The backfill takes the earliest user activity row. It skips agent actors and rows from other companies. - `server`: `vitest run src/__tests__/built-in-agents.test.ts` passes (40/40). A new test checks that a built-in agent enabled by a human records that human, and that automatic provisioning stays unattributed. The gated (pending-approval) provisioning test also asserts the creator. `src/__tests__/built-in-agent-routes.test.ts` also passes. - `ui`: `vitest run src/lib/agent-creator.test.ts src/pages/AgentOverview.test.tsx` passes (10/10). The tests cover these cases: the row shows with two or more humans, the row stays hidden with one human plus the Board, the UI never shows the Board as the creator, the row shows an error when the directory request fails, and the row stays hidden (no error) for agents with no creator or the Board as creator. The last case fails without the fix. - The current Storybook catalog uses source annotations and generated indexes. `node scripts/storybook-catalog.mjs --check` passes (264 story files, 2,514 stories). The merge keeps the authored catalog deletion from master. - `pnpm check:token-gates` is clean. - Screenshots from the Storybook story (fake data: two human members, Alice Admin and Bob Builder, plus the local Board). The red "Could not load public key" text is a Storybook artifact: the story has no fixture for the public key request. The existing `Dashboard` story shows the same text. **Two or more human members: the Identity card shows "Created by".**  **One human member plus the local Board: the row stays hidden.**  Full Overview tab: [overview-created-by.png](https://raw.githubusercontent.com/paperclipai/paperclip/9b62bd2ea6cf984ce6745f08cc45f44ddf00fb51/pr-16055/overview-created-by.png). The images are on the separate branch `pr-assets/agent-created-by`. They are not in this PR and do not go to `master`. - Manual check: open Storybook at `Pages/Agent Detail → Shared Company Shows Creator`. The Identity card shows "Created by Alice Admin". The `Dashboard` story has one human, so it does not show the row. - Final focused verification on `5a02350cf16050a3cf3cb3f8dc061fe61758c60d`: all 99 tests pass across the two UI suites, built-in-agent suite, and lifecycle suite. The backfill test applies the complete migration twice. The migration uses `ADD COLUMN IF NOT EXISTS` and preserves the company-scoped backfill. Migration numbering and token checks pass. - Full repository typecheck, build, and Storybook build pass. The generated creator story ID is present. A Chromium check renders the production agent page fixture and verifies the creator row and Alice Admin name. Map checks and their 21 tests pass. A fresh Apex review is 5/5 on the current head with no unresolved findings. All 54 successful CI checks pass on this head, with two intentional skips, including all general and serialized test shards, E2E, typecheck, and build. The workspaces-b job passed after rerunning a runner shutdown; no source change was needed. The separate, unsharded local `pnpm test:run` invocation has not completed; complete suite verification comes from CI. ## Risks - Migration: the migration adds one nullable column and runs one `UPDATE` on `agents` with a correlated subquery on `activity_log`. On an instance with a very large activity log, the backfill can take some time. The migration does not lock other tables and does not delete data. - Backfill accuracy: agents with no user-authored create activity row keep `null`. The UI then does not show a creator. This is the same as the current behavior. - Privacy: the row shows only names from the company user directory, and only to users who can already see that directory. - Low risk for single-user companies: the UI does not change for them. > 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 - Provider: Anthropic, Claude Opus 5.5 (model ID `claude-opus-5-5`), run as a coding agent through Claude Code with tool use (shell, file edit, and test execution), standard context window. OpenAI GPT-6 (`gpt-6`) through Codex assisted conflict resolution, regression tests, and repository verification. This session does not expose an exact 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 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Amy (Opus) <noreply@anthropic.com> Co-authored-by: Paperclip <noreply@paperclip.ing> Co-authored-by: devinfoley <139239+devinfoley@users.noreply.github.com>	2026-10-13 14:57:41 -07:00
DottaandPaperclip	2902b72c33	Merge current master into Codex runner defaults ... Preserve cancelled-lock semantics and complete the merged dependency lock. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 16:55:15 -05:00
4 people	a64969b288	fix(server): attribute legacy runs stopped by controller lease loss (#16084) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The heartbeat runner executes legacy agent runs. A controller lease watchdog keeps durable ownership of each legacy run. > - When the watchdog loses the lease, it aborts the adapter. The abort reason was a plain `Error`, and nothing recorded why the run stopped. > - Completion then saved the cancellation as source `unknown`. Sentry got an unexpected cancel that it could not tell apart from other unrecorded stops. > - We saw this on a sandboxed Grok run. The system cancelled it after about 22 minutes with `cancellationSource: unknown`. Workspace copy-back then failed. Every `cancelRun` path records a stop request, so an unrecorded stop this late points to the lease watchdog. > - This pull request records a lease loss as its own cancellation source, with a closed cause label. > - The benefit is that the next event shows whether the lease loss caused the stop, and which renewal failure caused it. That is the missing fact to fix the root cause. ## Linked Issues or Issue Description Refs #15790 Refs #15920 **What happened?** A legacy sandbox run was stopped by the system while it was working. The run record and the Sentry diagnostics show `cancellationSource: unknown`, with no initiator. The controller lease watchdog aborts the adapter with a plain `Error("Legacy controller lease lost")`. Completion does not read the abort reason, so it records the stop as `unknown`. **Expected behavior** When the host stops its own adapter because it lost the controller lease, the run records that cause. Diagnostics name the cause with a closed label. A stop that a user or the control plane requested earlier keeps its recorded source. **Steps to reproduce** 1. Start a legacy run that has a controller lease. 2. Make lease renewal fail: the renewal query errors, the update matches no row, or the lease deadline passes. 3. Let the adapter return its cancelled result. 4. Read `resultJson.cancellation` on the run. Before this change, `source` is `unknown`. **Agent adapter(s) involved** Not adapter-specific (core bug). We saw it with `grok_local` in a sandbox. **Additional context** This change adds diagnostics. It does not prevent the lease loss. #15920 retries a transient copy-back failure. It does not help here, because the stopped sandbox rejects every retry. ## What Changed - `legacy-controller-lease.ts`: The watchdog aborts with a new `LegacyControllerLeaseLostError`. The error carries a closed cause: `renewal_rejected`, `renewal_deadline`, or `renewal_error`. - `run-cancellation.ts`: Add the `controller_lease` cancellation source. Add `controllerLeaseLossCancellation()` and `readControllerLeaseLossCause()`. The reader accepts only the server-written reason text. - `heartbeat/run-completion.ts`: When the outcome is `cancelled` and the abort reason is a lease loss, record a `controller_lease` cancellation (`expected: false`). This covers both an adapter that returns a cancelled result (`completeRun`) and one that throws after the abort, for example through `signal.throwIfAborted()` (`failRun`). A stop request recorded earlier still takes precedence. - `run-failure-diagnostics.ts`: Add `controllerLeaseLossCause` to the execution diagnostics. Only the closed label goes to Sentry, never the reason text. - `heartbeat/run-state.ts`: preserve `controller_lease` in the bounded SQL projection when saved results exceed 64 KB. A database regression verifies the default run-detail read. - `canContinueCancelledRun` stays unchanged. It does not accept `controller_lease`, so a lease loss does not authorize automatic continuation. - `doc/run-log-events.md`: Document the new source and cause labels. - Tests: unit tests for the cause on each watchdog path, completion tests that record the source when the adapter returns and when it throws the abort reason (both fail without the change), tests that a recorded stop request takes precedence, and a test that the Sentry report contains the closed label and not the reason text. ## Verification - `cd server && npx vitest run src/services/run-cancellation.test.ts src/services/legacy-controller-lease.test.ts src/services/__tests__/run-failure-report.test.ts src/services/heartbeat/run-completion.test.ts`: 238 passed, including the embedded Postgres suites. - I reverted only `run-completion.ts` and ran the new completion test. It failed with `source: "unknown"`. With the change, it records `controller_lease`. - I removed only the `failRun` attribution and ran the new thrown-error test. It failed without the `controller_lease` record, and passes with it. - Final full repository `pnpm -r typecheck` and `pnpm build` pass. - Final local regression verification: all 247 tests pass across run-state, cancellation, watchdog, failure reporting, and completion suites. The large-result test fails before the SQL allowlist change. All latest-head CI checks pass (54 successes and two intentional skips). Fresh Apex is 5/5 on `708856c568d07d7b446a4a4af2edc6d9eec7d155` with no unresolved findings. ## Risks - Low risk. The change adds a new source value to server-owned JSON. Old rows keep their values. The readers accept the new value, and no UI code switches on this field. - A lease-loss cancel stays `expected: false`, so it is still reported as unexpected, as before. Now it has a more specific source. - The Sentry payload gets one new closed label (`controllerLeaseLossCause`). It does not include reason text or IDs. > 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 - Anthropic Claude Opus 5.5 (`claude-opus-5-5`) in Claude Code, with tool use (shell, file edits, test runs). OpenAI GPT-6 (`gpt-6`) through Codex added the large-result regression and SQL projection fix, with shell, file-edit, and test tools. The exact context-window size is not exposed in this session. ## 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 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: devinfoley <139239+devinfoley@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-10-13 14:50:40 -07:00
DottaandPaperclip	8d65fd7fc3	test: stabilize company seeds and diagnose durable progress failures ... Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 16:43:27 -05:00
Harjoth KharaandClaude Opus 5	be3e614d61	fix(workspace-runtime): keep the real readiness failure when the deadline-clamped probe aborts (#11575) ... ## Thinking Path > - Paperclip manages AI agents and the services they use for work. > - An agent can wait for a workspace service to become ready. > - Each readiness probe has a time limit. > - A final probe can expire and hide an earlier HTTP failure. > - This pull request keeps that observed failure in the reported error. > - Operators can then see why the service was not ready. ## Linked Issues or Issue Description Refs #11525. Related: #11494. **What happened?** A deadline-limited final readiness probe replaced an observed HTTP 503 with an abort message. **Expected behavior** Keep an earlier service failure when only the readiness deadline aborts the last probe. Report normal connection failures and probe timeouts as before. **Steps to reproduce** Return HTTP 503 from the first probe. Leave one millisecond in the readiness budget. Abort the last probe. The reported error must still contain HTTP 503. ## What Changed - Track whether a readiness probe observed a service failure. - Preserve that observation when the final probe expires at the readiness deadline. - Add a deterministic regression with an injected clock. - Keep probe scheduling, request count and timeout limits unchanged. ## Verification - Author verification: the readiness suite passed all nine tests; server typecheck passed. The regression failed before the fix and passed after it. - The later task review recorded 172 passing workspace tests and seven additional readiness checks. Historical author baseline failures are not claimed as passing local runs. - Latest head `936a374a08d0e74d87d588ba034f674388e8d508`: CI passed with 54 successful checks and two intentional skips. Fresh Apex review is 5/5 with no unresolved findings or recommendations. - A test merge with current master is clean. ## Risks - Error text changes when a service first fails and then hangs. The earlier observed failure is retained. - A hang without a prior service failure still reports the abort. - No data model, API or permission change. ## Model Used Anthropic Claude Opus 5 (`claude-opus-5`) authored the fix through Claude Code with reasoning, file editing and test tools. OpenAI GPT-5.6 assisted the original diagnosis. OpenAI GPT-6 (`gpt-6`) through Codex assisted this final review and PR preparation with repository and terminal tools. This session does not expose an exact 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: Claude Opus 5 <noreply@anthropic.com>	2026-10-13 14:25:09 -07:00
DottaandPaperclip	473c80d13f	Automatically import and update project repository skills (#16066) ... Automatically import skills from new GitHub project repositories and update enabled sources in the background. Preserve project-derived access, saved selections, immutable execution versions and explicit pins; add legacy adoption, refresh and connection repair in Sources. Include durable scheduling and bounded work credits, production Storybook journeys, real GitHub-to-routine acceptance receipts and final-head CI/security/Greptile qualification. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 16:11:43 -05:00
Devin FoleyandPaperclip	de335b42d4	Expose signed routine wake deadlines during idle sleep checks ... Expose signed routine wake deadlines during idle sleep checks Report the earliest eligible routine deadline to an authenticated host scheduler, while preserving local execution, owned sleep leases and conservative blocking for unsupported work. Verified with focused tests, typecheck, build, all required CI checks and Apex 5/5. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 14:09:16 -07:00
DottaandPaperclip	d68f1facf0	Merge master Storybook source annotations and preserve Codex qualification ... Retain all authored story identities and fixture boundaries under the generated-index contract. Record literal candidate checks, managed model failure and pending package/staging evidence. Native execution, selection, setup, onboarding, credentials, migrations and packaging retain their qualified source. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 16:02:15 -05:00
DottaandPaperclip	7eea9d8214	fix(github): use bot names in review summaries (#16212) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - A GitHub bot can send a pull request to an agent and publish its review. > - Each bot has its own GitHub App identity, but every summary currently starts with "Paperclip Review". > - A generic heading makes it harder to identify reviewers when several bots review the same pull request. > - This pull request uses the bot display name in review summary headings. > - Users can identify each reviewer while required checks keep their existing name. ## Linked Issues or Issue Description **What existing behavior does this improve?** The heading of a GitHub bot's published pull request review summary. **Current behavior** Every summary uses "Paperclip Review", regardless of the bot's name. The check also uses "Paperclip Review" and must keep that name for existing branch rules. **Proposed behavior** Complete and incomplete review summary headings use the GitHub bot display name. The heading falls back to the bot login, then the assigned agent name, when old connections have no display name. Separate GitHub Apps keep independent checks with the same name. **Reason and benefit** Readers can identify each bot's review. A regression test confirms that publishing a review does not update a check owned by another App or endpoint. **Breaking changes** The summary heading changes. Consumers that parse the old heading must accept bot names. No API, prompt configuration, database schema, or check name changes are included. No duplicate PR was found in the GitHub bot title search. ROADMAP.md does not contain a duplicate of this change. ## What Changed - Use the bot display name in complete and incomplete review headings. - Escape Markdown in names and fall back to the bot login or agent name. - Verify the heading through the publication workflow and keep check updates scoped to the App and endpoint. - Document bot-named summaries and independent checks. Update both access maps. ## Verification - Focused policy, heading, and existing UI tests: 67 passed. - Database-backed regression cases: 2 passed, including bot-name publication and independent checks. - Map checks, token gates, and git diff --check passed. - Typecheck and build passed on the final rebased branch. The final focused run passed 44 tests; the two database-backed regression cases also passed in a separate run. All final-head CI checks passed, including full test suites, build, typecheck, E2E, and security scans. Greptile reviewed the final commit at 5/5 with no actionable findings. No review threads remain unresolved. ## Risks - Consumers that parse the old summary heading must accept bot names. - The GitHub check remains Paperclip Review. Multiple-bot check isolation was tested with provider fixtures; a live two-bot GitHub test was not run for this change. ## Model Used OpenAI GPT-6 through Codex. The exact backend model ID and context window are not exposed in this session. Used reasoning, repository tools, 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 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-10-13 15:33:05 -05:00
DottaandPaperclip	57881c607f	Preserve selected Codex API-key precedence and login reload continuity ... Skip subscription source reads and refresh binding when CODEX_API_KEY is selected, matching the native task materializer. Retain managed subscription validation, no-follow staging and credential redaction. Update the existing mocked-login browser case to verify Connect restoration, the exact active session and saved selection through route reopening and real reload. Retain one login start, no pending hire and existing deadlines. Verification: 93 setup and 12 lower controls, server no-emit, independent source review, map and token gates pass. Preserve initial local import-deadline failures. The old browser expectation was reproduced; final local browser treatment stopped at PostgreSQL initialization and remains for hosted Linux CI. No paid or image qualification was dispatched. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 15:25:17 -05:00
Dotta	1d09569b05	Merge workspace isolation fix and reject unsupported linked Codex homes	2026-10-13 15:02:50 -05:00
Dotta	736d326822	Merge master while retaining Codex setup and onboarding fixes	2026-10-13 14:37:53 -05:00
Devin FoleyandPaperclip	c7f4b74111	fix: isolate fresh task sources from restricted project workspaces (#16095) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Each task must have an isolated workspace that its agent can read. > - Older project checkouts can contain worktrees for restricted tasks. > - The source access check correctly rejects these shared checkouts. > - A fresh task then fails even when its agent can clone the project remote. > - This pull request gives fresh default tasks a separate clone of the same remote. > - The task can start while the restricted task files remain protected. ## Linked Issues or Issue Description **What happened?** Fresh tasks fail with `Task workspace access is no longer available` when their default project checkout contains a restricted task worktree. The caller has access to the new task and its remote repository. The shared local Git source is unsafe to copy. **Expected behavior** Use a separate clone of the same authorized remote for a fresh default task. Keep source access checks and responsible-user Git credentials in force. **Steps to reproduce** 1. Put a restricted task worktree inside a project checkout. 2. Assign a new default task to an agent that cannot read the restricted task. 3. Start the new task. The current source check fails before workspace creation. 4. With this fix, the task uses a separate remote source. The restricted files are absent. Later runs reuse the same owned source. Related work: Refs #15749, Refs #15528. This change keeps their source retention and workspace ownership checks. ## What Changed - Add a remote source path scoped to the company and task. - Clone through the run’s Git connection after the shared source fails its access check. - Reject reused workspaces, explicit selections, pinned branches, local sources, credential-bearing URLs, and symlink paths. - Check source access again before publishing the workspace. - Resolve later runs from the verified recorded source. Ignore leftover clones that the saved workspace does not own. - Record provenance for new implicit Git defaults. Read the current task binding before fallback. Preserve explicit, inherited and ambiguous legacy checkout choices. - Keep the effective task strategy during startup validation of matching implicit defaults. Preserve the existing explicit-selection write check. - Add regression coverage and document the fallback. ## Verification - Merged master `c8efdbfba43` and resolved both rounds of catalog/index conflicts. All upstream suites, classifications, source references and story IDs are preserved. Both fix branches combine cleanly in either merge order, with no catalog fingerprint drift. - Passed locally: 313 focused source-isolation, preparation, task-creation, binding and trust tests before the final startup fix. The final fix passes all 100 source-trust, task-binding and environment-selection tests. Earlier workspace-resolution and persisted-source suites also passed. - Real-Git regressions cover all three review findings. Reconstruction ignores an unrecorded clone and preserves unpublished commits/files. Explicit and parent-inherited checkout IDs without typed selections retain their denial and branch tips without cloning or acquiring an environment. A protected-project heartbeat completes and resumes using the task’s Git strategy with read access. Explicit selection still requires writes, and a mismatched default is rejected. - Passed: the complete Storybook catalog check with no drift errors, feature and agent map structure checks, and all 17 catalog/index script tests. The generated index counts match the merged catalog. The current upstream verification-route inventory remains unchanged. The catalog contains all 262 authored suites and 2,481 story IDs. - Passed: full workspace typecheck and build after the final guard changes, on latest head `79d2adadcb6d3d7a04b9943a91bdb8b0b6abea6d`. - Latest head `79d2adadcb6d3d7a04b9943a91bdb8b0b6abea6d`: complete CI passed (54 successful checks, two intentional skips), including the full general/serialized suites and all eight browser shards. Fresh Greptile Apex review is 5/5 on this same commit, with no unresolved findings or recommendations. The full local test command was attempted earlier without a complete aggregate result; the complete suite result is from CI. - Manual check: configure a shared project checkout with a restricted task worktree. Admit a fresh default task using the authorized remote. Confirm separate Git storage and no restricted local branch or file. Reuse, close and reopen the task workspace. Confirm that explicit, literal branch and low-trust selections retain the denied source. ## Risks - A clean remote clone excludes unpublished local work. The fallback applies only to fresh default tasks and rejects existing workspace or branch selections. - A private remote can fail to clone when the responsible user lacks Git credentials. The run then reports the failure; access checks are not bypassed. - Older untyped checkout bindings cannot prove default provenance. They keep the source denial instead of silently dropping unpublished work. - New implicit Git defaults use the existing workspace-intent contract. The source directory uses existing instance storage. No schema migration is required. ## Model Used OpenAI GPT-6, model ID `gpt-6`, through Codex. Used reasoning, repository inspection, code editing, terminal tools, and test execution. The API session does not expose an exact 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-10-13 12:31:40 -07:00
Dotta	12046f522b	Fix saved Codex setup credentials and onboarding reload recovery	2026-10-13 14:28:40 -05:00
Nicky LeachandPaperclip	db65a0863e	Deliver durable resource lifecycle events to plugins without polling (#16203) ... ## Thinking Path > - Paperclip manages AI agents and their work. > - Plugins keep external resources aligned with Paperclip projects and agents. > - The durable resource journal stores changes, but its plugin interface requires polling. > - Project deletion has no journal entry, so consumers must scan for missing projects. > - This PR delivers committed journal events through a native plugin callback and records deletion. > - Plugins can recover unfinished work without periodic change scans. ## Linked Issues or Issue Description Related: #15343 introduced the durable inbox. #15631 added required agent lifecycle participation. This change keeps both contracts and adds automatic delivery for the resource inbox. **What happened?** Plugins must schedule reads of the durable inbox. A deleted project has no durable deletion event. Consumers must scan saved bindings to detect its removal. **Expected behavior** Core should deliver committed resource events and replay unfinished work. Empty queues should have no polling timer. Project removal should leave a durable event. **Steps to reproduce** 1. Install a plugin that consumes project lifecycle events. 2. Create or update a project. The plugin must call `listLifecycle` to discover it. 3. Delete the project. The journal has no deletion entry. ## What Changed - Add `resourceLifecycle` to the manifest and `onResourceLifecycle` to the SDK. Require `events.subscribe` and a configured, enabled company scope. - Reuse transaction-aware work signals and the delivery coordinator. Wake after commit, on startup and plugin activation, and after configuration changes. - Acknowledge only a matching successful result. Retry unfinished or interrupted work. Retain deferred events without an idle retry timer. - Wake again after successful worker configuration application, and retain failed scans through idle drain (both Apex findings fixed). - Keep ordering per resource and deliver past failed or deferred resources. Keep the manual inbox methods for existing consumers. - Record project deletion in the removal transaction. Extend the journal constraint with a generated migration. ## Verification - Apex follow-up: 129 focused worker, delivery, coordinator, and application tests passed; server typecheck passed. Regression coverage verifies configuration-application races and failed scans across idle drain. - Focused lifecycle, transaction coordinator, manifest, and SDK dispatch suites: 105 tests passed, including single-connection saves, redacted failure diagnostics, wakeups retained during idle drain, and per-event retry deadlines. - Complete SDK suite plus delivery database tests: 128 tests passed. - Shared, database, and SDK typechecks passed. Direct server `tsc --noEmit` passed against rebuilt SDK declarations. - Full local `pnpm test:run` finished with 19,491 passed, 148 skipped, and 6 failed tests across 5 files (plus two suite setup errors). This run overlapped branch updates and is not final-head evidence: failures included missing Cargo, local Git default-branch assumptions, and stale in-process lifecycle modules. Final Apex-fix commit `75d028788` passed all CI gates, including the full test shards, and received Apex 5/5 with no unresolved comments. - `pnpm -r typecheck` and `pnpm build` were attempted. Both stopped because Cargo is unavailable locally. CI supplies the Rust toolchain. - Local installation used the repository's documented lockfile fallback because master has dependencies missing from its lockfile. No dependency changes are included here. ## Risks - Delivery is at least once. Plugins must re-read current state and make external effects idempotent. - Signals are process-local, like the other delivery queues. Startup recovers committed rows. Independent database writers or multiple active server processes require an explicit ownership and wake protocol. - Apply migration `0340_open_warlock.sql` before running code that records project deletion. Earlier deletions cannot be reconstructed. - Automatic delivery selects plugins with company configuration rows. `deferred` waits for a later startup, configuration change, or other work notification. - This does not replace required agent lifecycle participation or establish that external mounts are unused. ## Model Used OpenAI Codex (GPT-6), with tool-assisted code editing, code inspection, 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 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 - [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-10-13 12:00:30 -07:00
Devin FoleyandPaperclip	5a6d0d08a7	fix: record verified workspace file recovery from tasks (#16104) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Recovery must preserve files and show the next operator action. > - A stopped run can leave a file repair hold after its recovery action is resolved. > - The task notice shows that hold but has no form to record verified file recovery. > - A chat connection can also replace the file repair instruction with a chat retry instruction. > - This pull request adds a file recovery form and preserves the file repair instruction. > - The form records evidence for the original run and keeps the current task status. ## Linked Issues or Issue Description **What happened?** A retained workspace file hold can block a task after its recovery action is resolved. The task page offers no file recovery form. A chat binding can hide the required file repair instruction. **Expected behavior** An authorized board member can record verified recovery of the original files. The server checks the original stop proof. The task keeps its current status and does not start another run. Chat instructions must not replace file repair instructions. **Steps to reproduce** 1. Create a stopped legacy run with a retained workspace recovery marker and a resolved recovery action. 2. Open its task page, including a task with a chat connection. 3. Observe that the file hold has no supported form to record verified recovery. Refs: #15857, #15824, #16095. Those PRs address shutdown export, native finalization and workspace source isolation. This PR uses the existing file repair API. ## What Changed - Add a board-only file recovery form with evidence and an explicit file verification confirmation. - Preserve the current task status when recording file recovery. - Project whether the original recovery marker supports file recording. - Keep file repair instructions when a task has a chat binding. - Add UI, route and Storybook examples for success, denial and chat-connected file holds. - Document the recovery flow and update the affected Storybook catalog entries. ## Verification - Merged master `c8efdbfba43` and resolved both rounds of catalog/index conflicts. Upstream review notes and classifications are preserved, together with all four retained-file recovery examples and their stable story IDs. Both fix branches also combine without merge conflicts or catalog fingerprint drift. - Passed locally after conflict resolution: 47 tests covering the file recovery UI, execution blocker notice and retained workspace repair route. The earlier ownership-route pass also covered 196 tests. - Passed: UI token gates, the complete Storybook catalog check with no drift errors, feature and agent map structure checks, and all 17 catalog/index script tests. Verification inventory counts match all 262 authored suites and 2,485 story IDs. The upstream production verification obligations remain intact. - Passed: full workspace typecheck, build and Storybook build on latest head `10ac22b35d0a4fe469cf620914845c509046da48`. The built index retains all four file-recovery story IDs. - Latest head `10ac22b35d0a4fe469cf620914845c509046da48` has 54 successful checks and two intentionally skipped Storybook checks. Apex is 5/5 on that exact commit, with no unresolved findings. The full general/serialized suites and all eight browser shards passed in CI. Local tests use the focused suites above. Storybook browser interactions have not been executed locally. - Manual check: open a task with a retained file hold. Verify that evidence and confirmation are required. Record verified file recovery. Confirm that its status stays unchanged and no run starts. Repeat without board runtime access and with an unverified stop receipt. ## Risks - The form records an operator attestation. It does not recover files itself or prove external action outcomes. - A stale source or missing stop proof must remain rejected by the existing server route. - No database migration or automatic task retry is added. ## Model Used OpenAI GPT-6 (`gpt-6`), used through Codex with reasoning, repository tools, code editing and test execution. The exact context window size is not exposed by this environment. ## 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-10-13 13:47:10 -05:00
DottaandPaperclip	6c0eca8716	Merge current master and preserve qualification failure diagnostics ... Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 13:14:03 -05:00
DottaandPaperclip	ccdc6754b2	fix: retain background preparation traces from unsampled requests (#16205) ... Start preparation phase root traces independently of request sampling and link each phase to its trigger. Preserve operator root sampling, concurrent child context, and silent unconfigured behavior. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 12:23:48 -05:00
Nicky LeachandPaperclip	da9af67415	Persist agent-owned instance secrets through lifecycle results (#16191) ... ## Thinking Path > - Paperclip coordinates agents and controls when they can run. > - Lifecycle plugins prepare and remove resources for each agent. > - Those resources can require private connection credentials. > - The current SDK can resolve configured secrets but cannot save these credentials securely. > - Ordinary company secrets can be bound to agents and do not provide the required server-only boundary. > - This change saves agent-owned instance secrets through the existing local lifecycle result and native secret service. > - The tenant can retain runtime credentials through restarts without a separate encryption system or remote API. ## Linked Issues or Issue Description **Subsystem affected** Agent lifecycle, plugin contract, and native secret storage. **Problem or motivation** Lifecycle plugins need to save private runtime connection details for the owning agent. Worker memory loses these details on restart. Plugin state and company secrets do not provide a private runtime-only boundary. **Proposed solution** Add optional instance-secret changes to lifecycle results. Save them through the existing secret service and local encrypted provider before accepting the result. Require company, agent, plugin, phase, operation, revision, and current unexpired attempt ownership. Supply saved values through the existing local preparation/resume request. **Alternatives considered** A separate encrypted store duplicates the native secret system. Generic plugin company-secret writes proposed by #5007 do not supply agent ownership or a server-only secret scope. This change does not add that general write API. **Roadmap alignment** Extends the existing lifecycle contract from #15631. It does not add a resource provider or select an execution backend. ## What Changed - Add an instance scope to native secrets with mandatory agent/plugin ownership, a company-qualified agent foreign key, and key uniqueness per owner. Existing company and user scopes retain their constraints. - Reuse native creation, rotation, deletion, secret versions, access audit, and the local encrypted provider. Keep values out of company catalogs, normal bindings, agent access, and public agent records. - Accept local secret patches only after locking and checking the current lifecycle operation and required plugin selection. Storage failure or a stale reply cannot complete setup. Expired or replaced attempt owners cannot overwrite a successor's credentials. - Keep vault-import conflicts company-scoped. Protect instance-owned account-home paths during failed device-login cleanup with a private, fail-closed scan. - Skip decryption on stop and cleanup so a lost key cannot block removal. Cascade secret records when their agent or plugin is deleted. - Log fixed provider diagnostics without raw errors that can contain credentials. Document the local contract, runtime resolver, and access-map exclusions. Retain the five latest migration snapshots through the normal generator pruning. ## Verification - 239 focused tests passed across agent-instance-secrets, lifecycle, secrets-service, secrets-routes, plugin-secrets-handler, and agent-device-login-routes. Used disposable PostgreSQL 18 clusters through the existing test constructor seam because the bundled binary cannot start on this macOS host. The temporary harness is outside git. - Regression tests reproduced the vault-import conflict and missed cleanup claimant before the fixes; both pass after the fixes. - New coverage includes encrypted native versions, rotation, restart recovery, company/agent/plugin isolation, ordinary-read and binding denial, stale replies, storage failure, safe logging, cleanup without the master key, and same-name secret isolation, native account-home mutation guards, lease takeover/expiry, and live agent/plugin deletion cascades. - Direct server TypeScript check, DB/shared typechecks, migration numbering/safety checks, module boundaries, and git diff check passed. - Full workspace typecheck and build were attempted; both stop at the missing local cargo toolchain. The full test command was started and stopped after failures in unchanged native-runtime/workspace suites plus bundled-PostgreSQL skips; it did not complete. CI must verify the full toolchain paths. - Current head `c0f8bfd12477ad509252ecd40e168a6c84dbeb36`: all 55 CI checks passed, including the previously canceled e2e shard. Greptile Apex reviewed this exact head at 5/5 with no unresolved threads. GitHub reports the branch mergeable and clean. - No live provider probe, production data access, or deployment. Reviewed the diff for credentials, private references, and run artifacts. ## Risks Apply migration 0339_luxuriant_iron_monger.sql before deploying tenant code. It adds nullable ownership columns, a partial unique index, foreign keys, and a stricter scope constraint. Existing rows remain valid. Keep the schema on application rollback. Preserve the existing secrets master key through deployments and backup restoration. The lifecycle request/result now has a sensitive, server-only field. Plugins must never log it or return it to an agent or browser. Values stay in the tenant database through the existing encryption provider. Trusted runtime consumers must apply normal execution admission before resolving them. Older hosts omit instanceSecrets; plugins that require durable storage must reject those hosts. ## Model Used OpenAI GPT-6 via Codex, with reasoning, repository inspection, code editing, and local test execution. The exact serving model identifier and context window are not exposed in this session. ## 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-10-13 10:13:42 -07:00
DottaandPaperclip	e43af9770a	refactor(server): isolate publication recovery and Board sends (#16192) ... ## Thinking Path > - Paperclip publishes task messages through several chat providers. > - Operator recovery must keep durable receipts and task authority consistent. > - The service combines shared publication transactions with provider recovery details. > - Provider-specific recovery belongs beside its transport implementation. > - This pull request extracts publication requests and resolution workflows. > - Shared workflows keep transaction ownership and delegate provider operations. ## Linked Issues or Issue Description Depends on #16187. Refs #16185, #16183, and #16180. Review against the parent branch. **What existing behavior does this improve?** The structure of publication requests, Board sends, and operator recovery. **Current behavior** Six public publication methods live in the main service and include provider-specific transfer and receipt operations. **Proposed behavior** Move shared requests and resolution to publications modules. Move Teams file resolution and Board preparation, Slack file receipts and Board staging, and Photon retry records to their provider folders. **Reason and benefit** Provider recovery is easier to locate without moving transaction and idempotency ownership into providers. ## What Changed - Extract six public publication methods into two shared workflow factories (629 and 467 lines). - Reduce chat-channels.ts from 5,337 to 4,078 lines. The full stack reduces it from 7,919 lines. - Extract Teams transfer resolution and cold-runtime Board preparation. - Extract Slack upload receipt resolution and Board send staging. - Extract Photon operator retry records. - Preserve the same public service API and keep provider operations in the original transactions. ## Verification - Merge preparation: replayed this stack onto current master after #16180 landed. Preserve master's new Telegram scheduling methods and connection-scoped Photon notifications. Server typecheck, callback syntax audit, and module-boundary check passed. Fresh local integration and wiring checks passed (1,318 tests). The dedicated Photon suite passed 18 before and 18 after the conflict resolution. This final slice was replayed onto merged #16187 with all chat-channel source unchanged. Current-head CI and review are running. Earlier verification below describes previous stack commits. - Publication, attachment, Board send, and operator recovery baseline: 261 passed before and 261 passed after; 1,034 other cases excluded. - Server typecheck, module-boundary check, and git diff --check passed. - Syntax audit reconstructs all six public method bodies from the provider helpers and matches the original AST. Unrelated service functions and the public API match too. - Final repository typecheck passed. Build passed. The broad local test run encountered heartbeat fixture setup failures under the macOS PostgreSQL shared-memory limit and was interrupted after 868 seconds (exit 130). Four confirmed abandoned guard slots were reclaimed without stopping active databases. The complete chat integration suite and source-wiring checks passed separately (1,309 tests). - Greptile rates current head 55417debfe 5/5 with zero inline findings. All 55 CI checks pass on that head. Tests use local PostgreSQL and fixture transports, not live provider execution. - Previous stack validation on #16192 (55417debfe): repository typecheck and build passed; all 1,295 chat integration cases plus 14 source-wiring checks passed locally (1,309 total). All five PRs have current-head 5/5 reviews and 55 passing CI checks. The broad local pnpm test:run hit PostgreSQL shared-memory fixture failures and was interrupted after 868 seconds (exit 130); it is not a local full-suite pass. ## Risks Operator recovery can duplicate a send if receipt updates move out of their transaction. The extracted helpers use the caller transaction. Teams preparation remains outside Board locks, and repeated send identities retain their existing receipt. Public method names and return values stay the same. ## Model Used OpenAI GPT-6 via Codex, with code execution and repository tools. The precise serving variant and context-window size are not exposed in this session. ## 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 - [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-10-13 11:48:07 -05:00
DottaandPaperclip	f18247b7e7	refactor(server): isolate durable chat wakeup workflows (#16187) ... ## Thinking Path > - Paperclip accepts chat messages as durable task input. > - Wakeups must preserve current company, identity, and task permissions. > - The main service mixes those shared checks with provider message rules. > - Shared wakeup workflows should own persistence and queue ordering. > - This pull request extracts wakeup authorization, processing, and notices. > - Slack and GitHub rules move into their provider folders. ## Linked Issues or Issue Description Depends on #16185. Refs #16183 and #16180. Review against the parent branch. Related open #13620 covers durable chat wakeup feature work; this PR only moves existing behavior. **What existing behavior does this improve?** The structure of durable inbound wakeup processing. **Current behavior** The service contains authorization, durable wake receipts, queue notices, and provider authority details. **Proposed behavior** Use three cohesive inbound modules and provider-owned authority functions. **Reason and benefit** The shared transaction and company checks stay together while provider rules have a clear home. ## What Changed - Move wakeup authorization, processing, and notices into inbound modules (245, 418, and 377 lines). - Move Slack mention checks and GitHub automatic-event admission and acknowledgements into provider folders. - Preserve lock order, durable receipt ordering, notice cursor lifetime, and the live heartbeat dependency. - Reduce chat-channels.ts from 6,340 to 5,337 lines, including blank-gap cleanup. ## Verification - Merge preparation: replayed this stack onto current master after #16180 landed. Preserve master's new Telegram scheduling methods and connection-scoped Photon notifications. Server typecheck, callback syntax audit, and module-boundary check passed. Fresh local integration and wiring checks passed (1,318 tests). The dedicated Photon suite passed 18 before and 18 after the conflict resolution. This slice was replayed onto merged #16185 with its chat-channel source unchanged. Current-head CI and review are running. Earlier verification below describes previous stack commits. - Existing wakeup, queue, retry, and authorization integration cases: 212 passed before and 212 passed after; 1,083 other cases excluded. - Server typecheck, module-boundary check, and git diff --check passed. - Syntax-tree audit compares all 12 moved functions, cursor state, retained service functions, and public API after explicit provider delegations. - The first three stack PRs have 55 passing CI checks and current-head 5/5 reviews. - Final stack checks are recorded below. The first broad local run encountered a PostgreSQL shared-memory fixture limit and was interrupted after that failure. - Greptile rates current head 1462819f53 5/5 with zero inline findings. All 55 CI checks now pass. Initial CI failures: the first workspace job hit EADDRINUSE in sandbox-callback-bridge.test.ts, and cloud-auth.spec.ts hit a disposed Playwright response. Both jobs passed on retry without source changes. Integration uses local PostgreSQL and fixture provider transports, not live providers. - Previous stack validation on #16192 (55417debfe): repository typecheck and build passed; all 1,295 chat integration cases plus 14 source-wiring checks passed locally (1,309 total). All five PRs have current-head 5/5 reviews and 55 passing CI checks. The broad local pnpm test:run hit PostgreSQL shared-memory fixture failures and was interrupted after 868 seconds (exit 130); it is not a local full-suite pass. ## Risks Authorization and wakeups must retain the same locks and transaction scope. Factories receive narrow dependencies and initialize before their consumers. The notice cursor stays per service. Shutdown and heartbeat reads remain live. Provider helpers do not own transactions. ## Model Used OpenAI GPT-6 via Codex, with code execution and repository tools. The precise serving variant and context-window size are not exposed in this session. ## 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 - [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-10-13 11:36:35 -05:00
DottaandPaperclip	721e87ac02	refactor(server): separate receiver ownership and provider callbacks (#16185) ... ## Thinking Path > - Paperclip accepts provider callbacks as durable task input. > - Runtime ownership prevents two servers from accepting the same receiver stream. > - Discord and Photon share the lease machinery but have different callback details. > - Moving that shared machinery into Discord would create the wrong platform dependency. > - This pull request extracts common receiver ownership and puts provider callbacks in their own folders. > - The service keeps startup and shutdown coordination. ## Linked Issues or Issue Description Depends on #16183; review against the parent branch. Refs #16180 and #16080. Related open work: #15532 changes Discord command reconciliation scheduling. This extraction preserves existing scheduling. **What existing behavior does this improve?** The structure of shared receiver ownership and Discord/Photon runtime callbacks. **Current behavior** The shared entry point mixes lease acquisition, renewal, provider capability checks, and Photon checkpoint transactions. **Proposed behavior** Put the common lease operations in runtime/ownership.ts and the protocol details in the provider folders. **Reason and benefit** The ownership lifetime stays explicit without making Photon depend on Discord implementation code. ## What Changed - Extract 11 receiver-ownership helpers into runtime/ownership.ts (397 lines). Expose only the operations used by the service. - Extract Photon ownership checks and checkpoint callbacks (44 lines). Retain the same runtime context object. - Extract Discord command and capability reconciliation (112 lines). - Keep the original service-owned lease map, runtime versions, stop tasks, and shutdown sequence. Read shutdown and test overrides through live accessors. - Reduce chat-channels.ts from 6,880 to 6,340 lines, including removal of blank gaps left by extractions. ## Verification - Merge preparation: replayed this stack onto current master after #16180 landed. Preserve master's new Telegram scheduling methods and connection-scoped Photon notifications. Server typecheck, callback syntax audit, and module-boundary check passed. Fresh local integration and wiring checks passed (1,318 tests). The dedicated Photon suite passed 18 before and 18 after the conflict resolution. Current head is 6d52aba35f; CI and review are running. Earlier verification below describes the previous stack commits. - Existing Discord, Photon, and runtime integration cases: 110 passed before and 110 passed after; 1,185 other cases excluded. - Server typecheck, module-boundary check, and git diff --check passed. - Syntax-tree comparison: 11 ownership helpers, two Photon callback bodies, Discord reconciliation, unrelated service functions, and the full public API/shutdown return expression preserve structure. Intentional binding changes are audited. - Both preceding PRs have 55 passing CI checks and current-head 5/5 reviews. - Repository typecheck and build passed earlier in this stack. Final stack checks are recorded below. The first broad local run hit a macOS PostgreSQL shared-memory fixture limit and was interrupted after that failure. - All 55 CI checks pass on df15f9dd9c. Greptile rates that head 5/5 with no inline findings. Tests use real local persistence with fixture runtimes; they do not prove live Discord or Photon execution. - Previous stack validation on #16192 (55417debfe): repository typecheck and build passed; all 1,295 chat integration cases plus 14 source-wiring checks passed locally (1,309 total). All five PRs have current-head 5/5 reviews and 55 passing CI checks. The broad local pnpm test:run hit PostgreSQL shared-memory fixture failures and was interrupted after 868 seconds (exit 130); it is not a local full-suite pass. ## Risks Lease loss and partial startup can create overlapping receivers if cleanup order changes. The service retains the same map objects and shutdown ordering. The ownership module reads current shutdown state, and Photon callbacks retain the exact mutable runtime context reference. No new worker or timer starts during module initialization. ## Model Used OpenAI GPT-6 via Codex, with code execution and repository tools. The precise serving variant and context-window size are not exposed in this session. ## 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 - [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-10-13 11:17:21 -05:00
DottaandPaperclip	ba00e9ef1a	refactor(server): isolate provider webhook handling (#16183) ... ## Thinking Path > - Paperclip connects provider messages to governed agent work. > - Webhooks must authenticate and persist messages before acknowledging them. > - The shared service still contains GitHub and Slack protocol details. > - The platform-boundary rule places those details in provider folders. > - This pull request extracts provider webhook handling behind typed methods. > - The service retains dispatch, runtime selection, and durable lifecycle recording. ## Linked Issues or Issue Description Depends on #16180; review this PR against its parent branch. Refs #16080. Related open work: #16163 changes GitHub automatic-author policy. This extraction preserves that policy implementation. **What existing behavior does this improve?** The ownership and readability of GitHub and Slack webhook handling. **Current behavior** The shared service implements GitHub signatures, replay fences, automatic event messages, and Slack callback verification. **Proposed behavior** Place those details in the respective provider folders and keep the common dispatcher small. **Reason and benefit** Provider code can be reviewed without reading the shared task service. ## What Changed - Extract GitHub request-local deadline and replay scope (60 lines). - Extract GitHub authentication and durable-ingress coordination (280 lines). - Extract GitHub event admission, message construction, and policy-skip receipts (140 lines). - Extract Slack workspace validation and authenticated callback observation (131 lines). - Keep the same service-owned background task set and GitHub provenance maps. Forward late-initialized callbacks without reading them during construction. - Reduce chat-channels.ts from 7,383 to 6,880 lines: 503 net lines removed. ## Verification - Merge preparation: replayed this stack onto current master after #16180 landed. Preserve master's new Telegram scheduling methods and connection-scoped Photon notifications. Server typecheck, callback syntax audit, and module-boundary check passed. Fresh integration, CI, and current-head review are running. Earlier verification below describes the previous stack commits. - Parent baseline: 544 selected GitHub, Slack, and webhook integration cases passed; 751 other cases excluded. - Initial extracted run: 543 passed and one idle-queue scan assertion failed. The idle-queue case passed separately on both the parent and extracted code. Its publication implementation is unchanged. The full selected-suite retry passed all 544 cases; the initial failure remains documented and its cause is not established. - Server typecheck, module-boundary check, and git diff --check passed. - Syntax-tree comparison verifies unchanged request-scope logic, durable ingress, leased authentication, event handling, workspace validation, and callback recording. All unrelated service functions remain unchanged. - Repository typecheck and production build passed for the parent extraction. Full-stack verification will run at the final handoff. The first broad local run hit a macOS PostgreSQL shared-memory fixture limit and was interrupted after that failure. - All 55 current-head CI checks passed. Greptile: 5/5 on f74ecb5094, with zero inline findings. No live third-party execution is claimed. - Previous stack validation on #16192 (55417debfe): repository typecheck and build passed; all 1,295 chat integration cases plus 14 source-wiring checks passed locally (1,309 total). All five PRs have current-head 5/5 reviews and 55 passing CI checks. The broad local pnpm test:run hit PostgreSQL shared-memory fixture failures and was interrupted after 868 seconds (exit 130); it is not a local full-suite pass. ## Risks Moving callback code can change initialization timing or lose request-scoped state. The new factories retain live option getters, the exact runtime context and provenance maps, and typed forwarding for late initialization. Authentication stays inside the existing credential lease. The common lifecycle write still completes before returning provider success. ## Model Used OpenAI GPT-6 via Codex, with code execution and repository tools. The precise serving variant and context-window size are not exposed in this session. ## 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 - [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-10-13 11:02:19 -05:00
DottaandPaperclip	30bc9e40ce	Align native setup isolation and finish shared runtime pickers ... Use the server-resolved sandbox transport for native setup, retaining local and SSH isolation and stripping injected flags. Preserve the complete local and managed E2E roster and existing graders. Replace the remaining scoped native dropdowns with the shared picker without changing saved runner or account choices. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 10:59:57 -05:00
DottaandPaperclip	1e64c875b2	refactor(server): move Slack recovery into channel modules (#16180) ... ## Thinking Path > - Paperclip manages AI agents and their work. > - Chat channels connect provider messages to governed tasks. > - Slack task recovery still lives in the shared channel service. > - Its provider sends and recovery state belong in the Slack folder. > - This pull request moves Slack task-start resolution and Board-message recovery into two modules. > - The service keeps the public dispatcher and the existing shared authorization owners. ## Linked Issues or Issue Description Refs #16080. Related open work: #15421 changes linked-user task trust; #15532 changes Discord reconciliation. This extraction changes neither behavior. **What existing behavior does this improve?** The ownership and readability of Slack task-start and Board-message recovery. **Current behavior** The 7,919-line shared service implements Slack retry and cancellation details. **Proposed behavior** Keep those implementations in the Slack folder. Preserve public methods and all state transitions. **Reason and benefit** The channel boundary follows rules/chat-channel-platform-boundaries.mdc and makes Slack recovery easier to review. ## What Changed - Move Slack task-start operator resolution into slack/task-start-resolution.ts (488 lines). - Move the durable Slack Board-message worker into slack/board-messages.ts (104 lines). - Keep initial endpoint/action lookup and provider-effect dispatch in the service. Pass the original endpoint record to avoid a new read or race. - Preserve live reads of heartbeat and deferred-processing options. - Reduce chat-channels.ts from 7,919 to 7,383 lines: 536 net lines removed. ## Verification - Existing Slack integration cases: 282 passed before and 282 passed after; 1,013 non-Slack cases excluded by the filter. - pnpm -r typecheck: passed. The first sandboxed attempt could not create a local tsx IPC socket; the permitted rerun passed. - pnpm build: passed. - Module-boundary check and git diff --check: passed. - Normalized TypeScript AST comparison: moved Board worker and Slack resolution tail unchanged; all other service function declarations unchanged. - All 55 current-head CI checks passed; two optional Storybook checks skipped. Greptile: 5/5 on 1c1bf5d019, with zero inline findings. - The broad local pnpm test:run encountered PostgreSQL fixture startup failure because the macOS shared-memory ID limit was exhausted (the chat integration file did not execute in that run). The focused 282-case before/after runs passed. Two verified abandoned, unattached 56-byte guard segments were reclaimed; no active database was stopped. The broad run remains unverified and its output is retained. - Existing public-service integration tests use real local database fixtures and injected provider transports; no live Slack execution is claimed. - Final stack validation on #16192 (55417debfe): repository typecheck and build passed; all 1,295 chat integration cases plus 14 source-wiring checks passed locally (1,309 total). All five PRs have current-head 5/5 reviews and 55 passing CI checks. The broad local pnpm test:run hit PostgreSQL shared-memory fixture failures and was interrupted after 868 seconds (exit 130); it is not a local full-suite pass. ## Risks Credential lease loss, ambiguous sends, and scheduler failure can cause duplicate work if ordering changes. The extraction keeps the lease, transaction, provider-confirmed receipt, and resume marker sequence intact. No schema, API, dependency, or workflow change. ## Model Used OpenAI GPT-6 via Codex, with code execution and repository tools. The precise serving variant and context-window size are not exposed in this session. ## 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-10-13 10:50:23 -05:00
DottaandPaperclip	448db859e3	Merge master recovery updates into Codex defaults ... Preserve current recovery and controller preparation behavior, both Storybook histories, and the reviewed Codex onboarding source. Targeted controls and direct TypeScript checks pass; exact-head hosted and live qualification remain required. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 10:33:51 -05:00
DottaandPaperclip	7956056b2f	Merge current master and qualify managed Codex onboarding ... Reconcile actual master 833769ab with preserved Codex 1a0ca662 and reviewed private onboarding preparation a758b226. Preserve the merged prerequisite and current native/security changes, saved runner choices, managed-image qualification and current Storybook identities. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 10:21:06 -05:00
DottaandPaperclip	e3029c632b	feat: trace controller preparation before agent dispatch (#16178) ... Trace eleven controller preparation operations with the existing hashed run correlation and preserve errors without exporting exception text. Verify asynchronous child-span parenting with a real OpenTelemetry SDK and context manager. Full exact-head CI and E2E passed after one documented fixture-startup retry; Greptile Apex 5/5. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 10:16:10 -05:00
4 people	0b0e53029f	fix: recover saved workspace results automatically (#15824) ... ## Thinking Path - Paperclip preserves accepted agent results before workspace copyback and result commitment. - A replaced controller can leave a physical copyback owner receipt behind. A lost database lock or expired lease cannot prove that its tar/Git children stopped. - Infrastructure recovery should belong to the runtime and deployment harness; task users should not investigate processes or attest shutdown. - New receipts record the exact deployment. The harness independently verifies that deployment fully stopped and signs a short-lived proof bound to the stack, run, owner and deployment. - The existing guarded reconciler then finishes the same accepted result without a new agent turn. Legacy receipts retain the documented administrator API after independent platform verification. ## Linked Issues or Issue Description **What happened?** An accepted native result can remain at `workspace_finalizing` with an abandoned physical copyback owner. Repeated recovery sweeps could replace specific instructions with advice to start new agent work. The first version of this PR exposed a shutdown-evidence form in the task; that asks end users to resolve infrastructure details. **Expected behavior** Automatically verify and recover the exact stopped deployment, preserve the original accepted result and existing approval/monitor waits, and show only a quiet task status. Unknown or live workers must remain fenced. Older receipts without platform identity need independently verified operator assistance through the administrator API. **Steps to reproduce** 1. Persist an accepted native result and a copyback receipt from a prior controller. 2. Replace that deployment before workspace finalization commits. 3. Let the normal finalization reconciler revisit the saved result. 4. With a platform-bound receipt and a fully stopped deployment, recovery should finish automatically. With missing, live, unverifiable or changed ownership, it must not write files or create another provider turn. Related public work: #14402 introduced copyback ownership; #9687 handles dead-run finalize barriers; #15795 handles terminal stale-run cleanup. This change addresses an accepted result whose physical copyback owner prevents commitment. ## What Changed - Record Railway project, environment, service and deployment identity on new physical copyback owners. - Request read-only platform verification from the managed cloud harness. Require an Ed25519 stop receipt with a disjoint purpose, configured signing key, exact stack/run/owner/deployment binding and valid expiry. - Keep live, unknown, malformed, unavailable and legacy owners fenced. Compare the whole prior receipt during ownership takeover, under the existing dedicated advisory lock. - Persist platform proof and audit automatic takeover. Resume normal finalization of the same saved result, preserving task ownership, approved boundaries, monitors and pending confirmations. - Remove process metadata, shutdown evidence, confirmation checkboxes and infrastructure-repair forms from task views. Suppress the duplicate technical owner-recovery card. Show “Restoring saved work…” only from server-confirmed recovery or queued operator recovery; platform identity alone shows the operator-assistance fallback. Remove the status when recovery resolves. - Share current-task, current-running-execution, accepted-result, authoritative-reviewer and newer-execution checks between automatic and operator recovery. Validate after the provider lookup, atomically with the owner claim, and again before file publication; closed or superseded tasks cannot start copyback. - Keep the separately authorized exact-owner API for operator recovery of legacy receipts, with active-lock, live-controller, stale-result and newer-execution rejection. Generic dismissal cannot bypass the copyback fence. - Replace obsolete form stories with production-backed automatic, queued, legacy, completed and mobile examples; retain stable suite IDs. Update the operator runbook and scoped Storybook catalog. ## Verification - Red/green: new platform-proof tests failed before implementation; the database takeover regression failed against the original ownership guard; reduced-UI assertions failed against the original form. All pass after the changes. - Passed: 59 physical-owner/finalization database tests using isolated PostgreSQL, including real reconciler commitment from all three saved-result phases through both automatic and operator recovery. They preserve result identity, exact saved file bytes, pending approval and overdue monitor waits, and create no new run or wake request. Unknown evidence and changed ownership remain fenced. - Passed: 162 focused proof, cloud identity, recovery route, recovery-card and reduced-UI tests. - Passed: full workspace typecheck and build, final server/UI typechecks, token gates, and Storybook build. - Browser inspection: desktop task composition shows only the quiet status; completed example removes it and retains the approval-wait message. Mobile shows the existing bottom navigation with no horizontal overflow. These are fixture UI observations, not live provider acceptance. - A companion harness change implements the actual provider check, signed receipts, server-token authentication and bounded/coalesced provider reads. Its full typecheck and test suite passed: 3,240 passed, 92 skipped, zero failures. This application alone cannot enable platform verification. - The updated full application `pnpm test:run` was stopped after repeated local embedded-Postgres startup failures; it is not claimed green. The same affected recovery suites pass against isolated PostgreSQL. CI passed on final head `9ad5c3529e`: 54 successful checks, two intentional skips, and successful legacy Snyk status. Greptile is 5/5 with no unresolved findings. - Global Storybook catalog validation is green: 225 files, 2,224 stories. Its 17 catalog/index tests pass. Master was merged and the inherited index metadata was reconciled after source review. - Review correction red/green: two UI and two database assertions reproduced misleading progress / missing server recovery state; all pass after server-confirmed state was added. All 153 focused server tests and 68 UI tests pass on the final recovery code, including repeated-sweep idempotence. Full workspace typecheck/build, token gates and Storybook build also pass. - Safety regression red/green: stale-task copyback and publication tests failed against the previous guard. The final suite covers changes during proof lookup, closed/cancelled tasks, replaced execution/checkout, newer and queued legacy runs, reassignment and rejected/unbound results, plus the real reconciler selecting closed or superseded tasks. Files remain untouched and no workspace operation starts. - No staging mutations, deployment, live provider probes or live production recovery were performed. The three historical receipts lack deployment identity and still require independent operator proof. ## Risks Automatic takeover requires the companion harness release and configured runtime-identity keys. Deploying only this application leaves unavailable evidence fenced. Legacy receipts are not retrospectively assigned a deployment identity. An authorized operator can still make an incorrect attestation through the fallback API; its administrator gate and exact-owner safeguards remain. Provider history that is missing or deeper than the bounded lookup defers automatic recovery. Copyback can still fail under its existing retained-workspace policy. No migration, telemetry change or cloud provider credential delivery is required. The companion harness PR also has passing CI and a 5/5 review; neither branch is deployed. ## Model Used OpenAI Codex, GPT-6, with repository inspection, browser verification, tool use and code execution. The exact serving model ID and context-window size were not exposed in this session. ## 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 and contains no internal Paperclip ticket id or instance-derived details - [x] I have run the relevant 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> Co-authored-by: Paperclip <paperclip@paperclip.ing> Co-authored-by: Devin Foley <devin@paperclip.ing>	2026-10-13 10:14:45 -05:00
Devin FoleyandPaperclip	833769ab55	perf(chat): schedule Telegram maintenance from commits and deadlines (#16094) ... Replace periodic Telegram discovery and maintenance scans with bounded startup recovery, connection-specific commit notifications, and durable action deadlines. Preserve ownership, inactive subscription parking, retry and cleanup recovery, and atomic credential binding updates. Verified full typecheck/build, 30 focused scheduler tests, 12 database-backed recovery cases, all current-head CI checks, and Greptile 5/5 with no unresolved threads. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 07:55:27 -07:00
Devin FoleyandPaperclip	a0651c96f8	Add database-free process liveness probes (#16101) ... Expose process liveness without database or credential queries while preserving hostname and runtime identity guards. Deep health and sleep/wake readiness checks retain their existing behavior. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 07:43:46 -07:00
DottaandPaperclip	be380ba155	fix(ui): hide agent-created tasks by default (#16157) ... Hide agent-created, system-created, and chat-channel tasks from independent collections by default. Preserve task hierarchy context and existing inbox participation. Add a saved opt-in checkbox without helper text. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 09:26:37 -05:00
DottaandPaperclip	3f7b00a8d0	fix: preserve public identifiers in feedback redaction (#16168) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - People rate agent comments and documents to capture feedback. > - Feedback bundles remove credentials and personal information before export. > - The feedback scanner treats ordinary dotted text as JWTs and authentication terms as bearer tokens. > - This pull request checks encoded JWT headers and preserves known authentication terms. > - The benefit is readable feedback context with credential masking kept in place. ## Linked Issues or Issue Description Refs #12309 for the related dotted-identifier false-positive report. This PR fixes the separate feedback scanner. It does not close every case in that report. Related PR: #14318 adds fine-grained GitHub token coverage. It addresses a separate credential form and is not duplicated here. **What happened?** Feedback exports replace `api.openai.com`, dotted filenames, and public schema IDs with a JWT placeholder. They also replace the words after `bearer` in phrases such as “bearer tokens.” Five-part encrypted JWTs are only partly masked. **Expected behavior** Keep public identifiers and authentication terms readable. Mask complete credential tokens. Count only text replacements in the redaction summary. **Steps to reproduce** 1. Pass `api.openai.com` or `Use bearer tokens.` to `sanitizeFeedbackText`. 2. Check that the original text is returned and the redaction counts stay empty. 3. Pass a signed JWT or an encrypted JWT to the same function. 4. Check that the full token is replaced and one JWT replacement is counted. **Paperclip version or commit** Reproduced in the feedback scanner on master at `5e8e992df2b3d71f82091b7bbf29fd482854d9f5`. **Deployment mode** Built from source. The defect is in the shared feedback export service and does not depend on deployment mode. ## What Changed - Use the existing JWT header predicate in the feedback scanner. - Match complete three-part and five-part tokens, including direct-encryption tokens with an empty key segment. Accept short token segments in the predicate. - Preserve the closed set of authentication terms already used by the general scanner, including terms inside closing prose delimiters. - Count only replacements that change the text. - Add tests for readable context, credential masking, nested values, and redaction counts. - Document feedback text redaction. ## Verification - Focused redaction and feedback service tests: 89 tests pass across five suites. - `pnpm --filter @paperclipai/adapter-utils typecheck` passes. Full local typecheck, tests, and build were attempted. The kernel killed compiler and test processes at the sandbox memory limit of 4 GB. Serial retries and a capped Node heap still could not complete the server compiler. CI runs the full repository checks. - `git diff --check` passes. - Latest commit `0eb8d3fb4257bb79e67fab615a8299ef69230ad8`: **55 checks passed**, including full typecheck, tests, build, and E2E; two optional Storybook checks were skipped. [CI evidence](https://github.com/paperclipai/paperclip/actions/runs/38407932875). Both Greptile findings have regression tests and fixes. [Greptile gives this commit 5/5](https://github.com/paperclipai/paperclip/pull/16168#issuecomment-6146917423), with both review threads resolved. ## Risks - This changes the feedback export matching rules. Public dotted text no longer triggers credential masking by shape alone. - Explicit credential assignments, provider keys, structured secret fields, email addresses, and phone numbers remain masked. Tests cover these cases. - Existing feedback snapshots are not rewritten. No schema change or migration is needed. - The encoded-header check remains a heuristic. It is not a full JWT validator. ## Model Used OpenAI Codex, GPT-6, with reasoning, tool use, and code execution. The runtime identifies the model as GPT-6. It does not expose the exact provider deployment ID or context window size. The earlier patch and this PR preparation were AI-assisted. ## 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-10-13 09:10:37 -05:00
DottaandPaperclip	aded4197e5	fix: make multiplayer task toasts personal (#16153) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - A company can have several human users and shared agents. > - Live task events currently produce toasts for any user who can read the task. > - This makes unrelated work interrupt other users. > - This pull request checks each user's task participation before it permits a toast. > - Users receive relevant task notifications while company views continue to refresh. ## Linked Issues or Issue Description **What happened?** Company task activity and agent failures produce noisy toasts for users who have no involvement in the task. **Expected behavior** A task qualifies when the viewer created it, commented on it, is its assigned user, deliberately acted on it under the Mine rules, or has an explicit user mention in its description or a non-deleted comment. Viewing, agent ownership, responsible-user attribution, and parent participation alone do not qualify. **Steps to reproduce** 1. Sign in as two users in the same company. 2. Have the second user create and update a task that does not involve the first user. 3. Observe a task toast in the first user's company view before this fix. The duplicate PR search found no existing change for personal task-toast eligibility. ## What Changed - Extract the existing Mine participation predicate without changing Mine behavior. - Compute task eligibility from stored tasks, comments, and run associations after WebSocket access checks. Use an exact indexed comment-mention lookup with `LIMIT 1`. - Add optional `toastEligible` metadata to each viewer's event copy. Keep it off the shared event bus. - Require eligibility for live task activity and task-linked run errors. Suppress generic agent errors. - Continue cache updates for quiet events. Refetch visible comments when authenticated events omit hydration details. Ignore stale socket callbacks after account or company changes. - Document toast semantics and add feature-map and agent-access-map coverage. - Add persisted-data, socket, UI, and authenticated browser regression coverage. ## Verification - Final commit: `1dc4f9402c5883744738cfe236ad00fa0bb5ca4c`. - All 55 current-head checks passed. Two Storybook checks were skipped because this change does not affect that coverage. - Greptile approved this exact commit with 5/5. The security scan passed. Both review threads are resolved. - Local `pnpm build`, `pnpm -r typecheck`, `pnpm check:token-gates`, and `node scripts/check-maps.mjs` passed. - The focused socket/UI suite passed 123 tests. The persisted eligibility suite passed 9 tests, including long history, exact viewer matching, and regex escaping. The existing Mine service suite previously passed 140 tests. - The named browser case `task toasts follow personal involvement in multiplayer` passed against the final commit in an isolated authenticated instance. It used two real sessions, real WebSocket delivery, and persisted tasks, edits, comments, and mentions. It verified quiet unrelated activity, viewing alone, first and historical mentions, own-action suppression, visible-task suppression, and live cache refresh. - A prior-head server shard passed its single rerun after a fixture-cleanup deadlock. The final-head CI run passed without a rerun. - The broad local run remained in progress when CI completed the full test suite. Local focused checks and CI provide the completed test evidence. ## Risks - This intentionally reduces live notifications. A new client stays quiet against an older server that omits eligibility. - Eligibility queries add work to live event delivery. A lookup failure suppresses the toast and still delivers the authorized event. - Deleted mentions cease to qualify unless another participation rule applies. Historical comment authorship retains the existing Mine behavior. - No database migration or notification-settings change is required. ## Model Used OpenAI Codex with GPT-6 assisted with implementation, tests, documentation, and PR preparation. It used repository tools, shell commands, and browser automation. The runtime did not expose an exact backend revision or 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-10-13 08:09:19 -05:00
DottaandPaperclip	2ad36f4ff2	Fix skill source removal with a keep-or-delete choice (#16150) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - GitHub sources import skills and keep their updates together. > - Disconnect only disabled a source and kept its read-only imports. > - A disabled source could not be removed or imported again. > - Removing a source needs an explicit decision about its imported skills. > - This pull request removes the source after the user keeps editable copies or deletes the imports. > - Existing disabled sources use the same removal flow. ## Linked Issues or Issue Description Refs #15731, #14713. **What happened?** Disconnect left the repository on Sources. Its Disconnect action was then disabled. The saved repository still blocked a new import. **Expected behavior** Remove the repository from Sources. Require a choice to keep editable copies or delete its imports. Allow removal of sources that are already disconnected. **Steps to reproduce** 1. Import a repository in Skills → Sources. 2. Choose Disconnect source. 3. Observe the disconnected row and disabled removal action. 4. Try to import the repository again. **Paperclip version or commit** d67e3507b2. ## What Changed - Add one confirmation with a required keep-or-delete choice. - Remove the source and entries, including legacy disabled sources. - Keep complete editable copies in My Skills, including shared repository files and executable modes. Preserve skill IDs, keys, versions, and agent assignments. - Delete imported skills and source in one transaction with its activity record. Check policy for every linked skill, including deselected entries. Reject deletion of skills still used by agents. - Fence removal with the source revision. Reload stale confirmations and require a new choice. Prevent an in-flight refresh from restoring removed imports. - Reject incomplete legacy copies with a recovery message. Lock copied skill rows against concurrent deletion and check publication succeeded. - Add regression tests and production-page Storybook examples. Make an initially unselected radio-card group keyboard accessible. ## Verification - Workspace typecheck and build passed. Final affected server/UI typechecks passed. - Focused server, UI, and API suites passed: 114 tests initially. After review fixes, all 21 source persistence and 58 route authorization tests passed, including the complete repository copy regression; affected server/UI typechecks and token gates passed again. - Design token gates passed. - Real isolated app: imported a public repository, assigned bro to the CEO, verified that deletion reports the assignment, kept an editable copy, observed the source disappear, opened the copy in My Skills, saved an edit, and refreshed. The assignment remained. Re-imported the same repository, deleted its new unused import, and verified the original editable copy and assignment remained. No model tasks ran. - Full local Vitest was attempted but terminated with exit 137 before completion; it is not counted as a pass. Current-head sharded CI is pending. Greptile reviewed the current head at 5/5 with no new actionable comments. The final workspace build passed again. - Storybook catalog aligned. The legacy removal example was inspected in the browser; the Delete choice enables removal. - Storybook: Skills / GitHub-synced skills / Sources · Disconnect source and Sources · Remove disconnected source. ## Risks - DELETE of a skill source now requires the saved revision and an explicit copy/delete choice. Old callers must update their request body. - Deletion removes imported skills and their records. Assigned skills must be detached first. - Incomplete legacy versions must be refreshed before keeping copies; removal does not silently discard supporting files. - Copies intentionally stop receiving upstream updates. Their IDs and keys remain stable for assigned agents. - No database migration. Copy writes use new managed directories and clean up on failure. Delete restores quarantined files before releasing publication locks on failure. ## Model Used OpenAI GPT-6 through Codex, configured model `gpt-6-astra`. The runtime does not expose the context-window size. Used shell tools, code editing, tests, and browser interaction. ## 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-10-13 07:53:13 -05:00
DottaandPaperclip	df06df2306	fix(slack): allow direct messages without at-mentions (#16151) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Slack connections let people start and continue agent tasks. > - The Require at-mention setting currently applies to channels and direct messages. > - A person who sends a direct message has already selected the agent. > - This pull request exempts direct messages from mention checks, including queued work. > - People can talk normally in DMs while channel messages keep the configured mention rule. ## Linked Issues or Issue Description Refs #15612, which introduced the Require at-mention setting. Searches found no duplicate PR for the DM exemption. **What happened?** With Require at-mention enabled, a plain Slack DM does not start or continue agent work. New Slack connections enable the setting by default. **Expected behavior** Direct messages do not need an at-mention. Top-level DM replies remain top-level. Channel messages and channel thread replies still follow the saved mention setting. **Steps to reproduce** 1. Enable Allow direct messages and Require at-mention on a Slack connection. 2. Send a plain DM from an authorized sender. 3. Confirm the agent responds without an at-mention. Send a plain follow-up and confirm it also works. 4. Confirm unmentioned channel messages remain filtered when Require at-mention is enabled. 5. Disable Allow direct messages and confirm new DMs remain blocked. **Paperclip version or commit** Source baseline: `eb06c9fedd`. **Deployment mode** Built from source. Automated tests use disposable local Postgres and provider fixtures. This change has not been deployed or retested in live Slack. ## What Changed - Exempt DMs at inbound admission, task mutation, work authorization, and heartbeat queue claim. - Keep channel mention checks and all existing sender, endpoint, and destination checks. - Update regressions for new connections, follow-ups, deferred delivery, and coalesced queued messages. - Clarify the Slack settings copy, connection documentation, and verification maps. - Refresh the affected Storybook review references after source inspection. ## Verification - Passed 55 Slack and durable scheduler tests with Vitest on the current rebased commit, including admission through the extracted inbound module. - Passed `pnpm -r typecheck` and `pnpm build` on the rebased PR commit. - Passed token gates and map checks. - Passed Storybook catalog validation after rebase: 223 files and 2,210 stories. - Full local `pnpm test:run` was stopped before completion after three failures in the unchanged tool-access suite. All 418 tests in that suite passed in a standalone rerun. The focused regressions passed; full GitHub CI remains the merge gate. - Greptile reviewed commit `b0293fa6571403c5e01c30bb7b5fcc5e91b88c97`: 5/5, with no findings or unresolved review threads. All 55 GitHub checks passed on this commit; two optional Storybook jobs were skipped. - No live Slack messages were sent during implementation verification. ## Risks Existing Slack connections now accept authorized plain DMs even when Require at-mention is enabled. Allow direct messages and sender authorization still apply. Queued DM work follows the same exemption. Channel behavior and DM reply routing are unchanged. No schema or migration change is required. ## Model Used OpenAI GPT-6, running as Codex, with reasoning, tool use, and code execution. The runtime does not expose a more specific model ID or 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-10-13 07:40:46 -05:00
DottaandPaperclip	fc3b15537b	fix(runner): match call_api to existing agent REST permissions (#16040) ... Route native call_api through existing agent REST permissions. Preserve admitted credentials across restarts, protect sensitive replies and private snapshots, and compare saved completion with provider history through the same redaction projection. Add permission, privacy and recovery regressions and update the access map and run-log guide. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 07:34:15 -05:00
DottaandPaperclip	eb06c9fedd	refactor(server): split chat channel workflows into provider and shared modules (#16080) ... Move provider operations into channel folders and shared chat work into named interaction, setup, admission, delivery and publication workflows. Consolidate reviewed PRs #16085, #16089, #16096 and #16105. Preserve upstream execution-default and recovery behavior. The main service is 7,917 lines. All 55 current-head CI checks pass, with two optional Storybook skips. Greptile is 5/5 with no findings. All 1,294 current chat integration cases, repository-wide typecheck and build pass locally. Broad local tool-route timing/socket failures are recorded in the PR. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 07:26:32 -05:00
DottaandPaperclip	d67e3507b2	feat(runner): qualify Codex platform packages and cache hosted builds (#16028) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Native execution needs a compatible installed daemon and provider dependency. > - The Codex-default work found missing platform packages and clean-install startup failures. > - Release builds also repeat dependency compilation and run preparation serially. > - This prerequisite packages four daemon targets and verifies installed native startup. > - It also caches hosted Cargo dependencies and overlaps JavaScript preparation with compilation. > - Agent creation defaults and experimental gates stay at the current master behavior. ## Linked Issues or Issue Description Refs #15683. Refs #15555. Refs #15422. Refs #15926. Refs #15932. Extract runtime and installation support from #15683. This prerequisite has 65 changed files. Creation, onboarding, imports, UI runner selection and graduation remain in the dependent PR. Feature/access maps and the Storybook source catalog stay synchronized. Existing agents keep their execution choices. ## What Changed - Correct the existing runner test fixtures. Reserve owned credential quorum listeners through the existing bounded fixture helper. Keep foreign listeners intact, run actual credential staging once, and preserve its rejection and unchanged-auth assertions. Reuse the durable-resume outer-limit correction. Wait for actual warm-completion and held-authorization callback entry under the existing recovery deadline and surface early request errors. Preserve every semantic assertion. - Retain bounded installation failure diagnostics through the existing qualification receipt upload. Keep the original error, 10-minute deadline and all success checks. - Keep startup ownership until credential preparation and registration drain. Reject duplicate and post-close startup/resume work. Observe shutdown during normal and adopted authentication readiness. Preserve the primary failure and retain private state when cleanup is unconfirmed. - Package Linux x64/ARM64 and macOS Apple Silicon/Intel daemons. Verify target headers, source identities, manifests, and hashes before assembly and installation. - Reuse the existing release producer/consumer workflows. Cache Cargo dependencies by target, OS, compiler, lockfile, and contract inputs. Rebuild workspace binaries. Permit trusted cache writes only for canonical exact-source master pushes. - Overlap JavaScript preparation with native compilation. Join both commands and failure/cancellation cleanup before artifact verification. - Preserve shell positional arguments in the shared SSH runner and apply environment assignments correctly. Reject environment option keys. Six before/after controls and two real SSH subprocess paths pass with zero provider calls; this fix lands before both Codex and Claude defaults. - Admit verified suspended SSH backups during cold controller continuation, using the same full-scope, integrity and lifecycle checks as sandbox targets. Two positive SSH cases fail before; all 14 positive/negative matrix cases pass afterward. Active ownership and corrupt/malformed/nonempty state remain rejected. - Record measured sandbox platform facts through the existing explicit environment probe. Bind facts to the company, effective provider configuration, immutable OCI image and actual captured image binding. Check the returned cleanup receipt. Reject client-authored proof and stale or named boot identities. Creation and discovery allocate nothing. Preserve connection-only behavior. - Resolve the actual remote Codex target and preserve same-host development overrides. Preserve runtime artifact verification. Use actual protocol/model compatibility rather than a numerical CLI version fence. - Resolve the installed Codex login dependency on 64-bit Linux and Mac independently of the daemon libc baseline. Preserve account homes and safe errors. - Fix actual clean-install TOML table comparison. Preserve strict semantic checks, comments, private writes, and malformed-input rejection. Preserve primary startup failures and bounded cleanup. - Document GNU libc 2.39+ and stock Ubuntu sandbox prerequisites. Qualify ARM startup with a scoped distribution profile and unchanged global restrictions. Preserve Windows and Alpine deferral. - Preserve selected and saved native Codex reasoning effort in the existing UI builder, while excluding it from other providers. This small shared correction prevents import edits higher in the stack from dropping effort. - Reuse existing installed-package checks and assertions. Paperclip tarballs contain no Codex native payloads. Official npm dependencies supply the consumer's Codex binaries. All Docker and native builds stay remote. ## Verification Candidate: `271d434c170e74bdedde65d0b13059a55419c943`. It includes current master `e168512f7bdbb6af6ea01954c6d7ed80b91e903e` and preserves prior candidates through ordinary commits. Current [full CI](https://github.com/paperclipai/paperclip/actions/runs/38346601686) is successful on attempt 2. GitHub reports 54 successful checks and four conditional skips, including required verify and browser aggregates, workspace typecheck/tests/build, Linux DB controls, both runner shards and [isolated native compilation](https://github.com/paperclipai/paperclip/actions/runs/38346601609). Fresh current-head Greptile is 5/5 with all four threads resolved. The passing build's clean Grok/Codex report records CI merge source `7a82a37438e6e448abc7cc5caa60dc2519a97be0`, 18 installed packages, omitted Codex payloads, official host-only npm dependencies and zero provider calls. Pi setup and its no-prompt lease verification also pass. The first attempt's single 60-second Node archive download timeout remains retained; its DNS/TLS/download cause remains unknown. One unchanged-source retry was requested through the normal Build-job dialog with debug logging disabled. GitHub's attempt 2 graph reports the other CI jobs as well; no second retry or source/deadline relaxation was made. The [final exact-source package campaign](https://github.com/paperclipai/paperclip/actions/runs/38347027535) is successful on literal `271d434c170e74bdedde65d0b13059a55419c943`. It passes all four native producers, public Linux package assembly and clean installed consumers on Apple Silicon, Intel Mac and Linux ARM64. The nine qualification-mode skips are intentional; full CI above covers their ordinary gates. Native builds and Docker assembly ran remotely. The predecessor [`dae808` package campaign](https://github.com/paperclipai/paperclip/actions/runs/38342104102) remains literal historical evidence. Only tests and the dated record differ from that source; runtime, package and workflow code is unchanged. The reused credential fixture correction passes all 42 canonical Node 24 controls with synthetic data and independent matching-source review, and the current hosted runner shard passes. Production credential behavior is unchanged. **Merge hold:** current-source CI, fresh 5/5 review and exact-source package qualification pass. Actual code-owner approval and normal protected merge remain pending. No slice has merged or deployed. GitHub CLI authentication needs refresh; the normal signed-in embedded GitHub UI provided this status without credential workarounds. - The master merge preserves both Storybook source-review appendices and the guarded test-home cleanup. All six existing cleanup controls pass without skips. Master's isolated-home helper/test/setup are byte-identical. The two existing whitespace lines in master's unrelated privacy test remain outside this PR's diff. - Canonical Node 24 passes all 24 existing public-install helper tests. Three narrow added cases prove bounded/redacted failure metadata, symlink exclusions, original exception identity, failed diagnostic writes and no false failure on success. The Mac installer now uses `--timing`; at most two 16 KiB tails and 32 structured entries per tail enter the existing receipt upload. Raw argv, URLs, environment, error text and stacks are omitted. A failed receipt explicitly remains FAILED/unqualified/runtime-not-attempted. The 600,000 ms install deadline and every real package/hash/payload/lock/lifecycle/runtime oracle are unchanged. - Canonical Node 24 reproduces the durable-resume outer timeout under controlled fake latency. Only its outer test limit changes to 15 seconds; internal 500 ms/5 second deadlines and usage/effect assertions remain. Controlled warm-recovery and before-bootstrap authorization scheduling delays reproduce their callback polling failures, while the explicit entry signals pass. Early recovery errors surface unchanged. Independent review is clear. Historical mock binaries support the fixture controls; fresh full hosted CI remains decisive. The original hosted callback failure cause is inconclusive. - The composed runner/surfaces/server/E2E TypeScript checks pass. Map checks pass 35 areas/171 capability IDs. Token gates pass. The existing Storybook catalog passes 223 files/2,210 stories; story IDs and classifications remain intact. The current master had 25 inherited stale fingerprints from three changed map recipes. Only those guarded fingerprints and a source-only review note change; all 92 non-map story/component/fixture inputs remain unchanged. Existing classifications are retained. This proves source structure, not visual or live acceptance. - The 65-file contribution audit has no code file crossing from below 1,000 lines to above the limit. Earlier comment cleanup preserves executable emissions, parsed workflows and action pins. Independent cleanup/catalog and three-file reporting reviews are clear. No new workflow, suite, grader or local native/Docker build was added. **Prior `dae808` gate evidence:** fresh Greptile is 5/5 with four resolved threads, isolated native compilation and the browser aggregate pass. Its first runner shard passes the previous two corrections but fails a different held-authorization cell at the implicit one-second polling deadline. It records 1,672 passes/one failure/three skips. This candidate applies the verified entry-signal correction without changing production deadlines or any semantic assertions. Its original hosted cause remains inconclusive until fresh CI. **Previous-source evidence, kept literal:** the [exact `16a532` package campaign](https://github.com/paperclipai/paperclip/actions/runs/38338806076) passes all four native producers, public Linux package assembly, Apple Silicon, Intel Mac and Linux ARM64 installed consumers. Its fresh review is 5/5 with all four threads resolved. Full CI records 52 successful checks, four conditional skips and the two fixture failures corrected here. This is not a green full-CI candidate or proof for the new source. `64c074fb8da1b31f8d6042c4fef48dc4164e759b` passed [full CI](https://github.com/paperclipai/paperclip/actions/runs/38332726938), 54 checks/four conditional skips, [isolated native compilation](https://github.com/paperclipai/paperclip/actions/runs/38332726787/job/115085895328), and fresh Greptile 5/5/all four resolved threads. The hosted transport suite passed 246 tests and startup trust passed 22, closing that source's local fake-binary limitation. These are historical after reconciliation. The [previous exact-source package campaign](https://github.com/paperclipai/paperclip/actions/runs/38332921463) built all four platform daemons and passed public Linux package assembly plus Apple Silicon and Linux ARM64 installed consumers. **Intel Mac failed:** its initial scripts-disabled npm install timed out before lifecycle/runtime assertions. The underlying download/resolution/host cause is unknown because the old helper deleted the npm logs. This is the concrete baseline for the diagnostic change. The failed campaign remains failed; no all-platform signoff or automatic retry is claimed. The earlier `a200495` [four-target campaign](https://github.com/paperclipai/paperclip/actions/runs/38283695248) and [scoped ARM qualification](https://github.com/paperclipai/paperclip/actions/runs/38291535914) remain component evidence. Cargo restores were cold misses; no warm-cache speedup is claimed. Paperclip tarballs contain no Codex payloads. Official npm dependencies supply Codex on the user's platform. Current-source full workspace typecheck/tests/build, Linux DB controls, static/Rust/native tests, all browser shards and exact-source package consumers must pass. New-agent defaults and final managed onboarding belong to #15683. Actual private Cloud composition, warm/cold signup, task/follow-up and rollback compatibility remain later release gates. Source audits found that ordinary managed onboarding does not run the saved platform probe and Cloud distributes named snapshots without a verified final boot-image binding. These dependent release blockers remain open; prequalified E2E fixtures do not close them. Master adds task-workspace migrations; the final image/migrator and previous-image checks must include them. ARM paid task/follow-up and ordinary OS APT installation are not proven. ## Risks - Multi-target packages require source and header agreement. Missing or mismatched artifacts fail explicitly. Existing execution choices remain unchanged. - Linux requires GNU libc 2.39+ and compatible sandbox prerequisites. The scoped hosted ARM preparation does not qualify arbitrary containers or kernels. Windows, 32-bit ARM, and Alpine remain deferred. - Only dependency crates are cached. Preview jobs cannot write trusted caches. Concurrent command cleanup must preserve the primary failure. - Native-free Paperclip packaging retains official Codex npm dependencies. No Codex payload bundling, schema migration, automatic agent migration, or production deployment is included. ## Model Used OpenAI Codex, GPT-6 family, with reasoning, repository tools, code execution, and parallel agents. The exact serving model snapshot and context-window size are not exposed. ## 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-10-13 06:24:07 -05:00
Dotta	4a641d0980	fix(ui): default human task replies to the latest assigning agent (#15594) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Tasks let agents ask a person for input. > - The reply composer needs a useful default recipient. > - A recent comment does not identify the agent that assigned the task. > - The old fallback can select the person who is writing the reply. > - This change uses the latest agent assignment and keeps manual choices. ## Linked Issues or Issue Description **What happened?** When an agent assigns a task to a person, the reply composer can select that person or a different commenter. A data refresh can also replace a manual selection. **Expected behavior** For a task assigned to the current person, select the latest agent that assigned it to them. If no such assignment exists, use the latest other commenter. If neither exists, leave the recipient empty. Keep explicit choices during refreshes. **Steps to reproduce** 1. Have agent Alpha assign a task to a person. 2. Assign it to agent Beta, then have Beta assign it to the same person. 3. Open the task as that person. 4. Check that the reply composer selects Beta. 5. Select another recipient. Refresh task data. Check that the selection stays. Related work: #15091 shares task composer controls. This change fixes recipient defaults. ## What Changed - Read real assignment changes from REST and native runner task activity, in time order. - Record human assignee fields in native create and reassign activity. - Ignore unchanged assignment fields and assignments to other people. - Use the assigning agent before comment hints for human-owned tasks. - Connect the suggestion to current and classic task composers and pipeline replies. - Keep manual selections when suggestions change. - Add regression tests and document the fallback. - Use tasks with no assignee in the attachment receipt tests. This keeps the tests on the comment route. Dismiss announcements through the real UI. - Record human and agent assignees in REST creation receipts. Include child creation in the assignment history resolver. ## Verification - Focused tests cover assignment order, creation, other recipients, unchanged fields, fallback, and manual selections. - Browser fixture uses the real composer and assignment resolver. It selects Beta and keeps a manual human selection after history refresh. - Passed: 223 focused tests across four suites. - Passed: `pnpm --filter @paperclipai/ui typecheck`. - Passed: `pnpm --filter @paperclipai/ui build`. - Passed: `pnpm check:token-gates`. - The initial CI run passed full build, typecheck, Rust, unit tests and seven E2E shards. The attachment shard exposed tests that relied on the old self-selection default. The tests now select the recipient explicitly. - Native assignment regression tests and resolver tests pass: 40 tests. - Attachment E2E suite: 10 passed; one page-load timing failure passed on an isolated rerun. All 11 cases passed across the suite and rerun. - Previous full CI passed at cc7ed05. New CI must pass on the current head. - Latest local checks: 16 resolver tests and 7 workspace policy tests pass. REST creation audit tests cover both creation routes. - The latest browser check could not start. The UI build exceeded the local memory limit (exit 137). Full typecheck, tests, build, and browser checks will run in CI. ## Risks - Old activity rows without previous assignment values cannot prove a reassignment. They use the comment fallback. - An empty fallback requires the person to choose a recipient or use the existing no-assignee flow. - No database or API schema changes. ## Model Used OpenAI Codex, GPT-6. The session does not expose an exact model build or context window. Used code editing, shell tools, tests, and browser 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 Final validation at f83f2f6: 55 checks passed. Two optional Storybook checks were skipped. All browser shards passed. Both review threads are resolved. Classic attachment tests use the real no-assignee confirmation.	2026-10-13 00:56:15 -05:00
DottaandPaperclip	d837b65be8	refactor(server): move provider setup, inventory and delivery into channel folders (#16058) ... Consolidate the ten reviewed provider-folder extractions. Preserve the verified source tree and current master changes. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-13 00:26:33 -05:00
DottaandPaperclip	7d7f55e4be	fix(apps): show user avatars and center access rows (#15577) ... ## Thinking Path > - Paperclip helps people manage AI agents and their access to apps. > - The app access page shows people with linked chat accounts. > - The identity response omitted the user's saved image. > - The row placed the avatar beside only the first name line. > - This change returns the image and centers the avatar beside both name lines. > - People can recognize linked accounts and still see initials when no image is available. ## Linked Issues or Issue Description **What happened?** The app access page showed initials even when the linked Paperclip user had a profile image. The avatar was above the vertical center of the Disconnect button. **Expected behavior** Show the linked user's saved image. Center it beside the Paperclip and chat names. Keep initials when no image is available. **Steps to reproduce** 1. Link a Slack account to a Paperclip user with a profile image. 2. Open the app's Access tab. 3. Inspect the person's avatar and the two name lines. Searched public issues and pull requests. No duplicate fix was found. Related avatar work in #15095 concerns agent uploads, not linked user profiles. ## What Changed - Return `paperclipUserImage` from the chat principal service and declare it in the API and client types. - Use the shared avatar primitives and center the avatar beside the full name block. Keep full names available in hover text. - Add image and initials examples to the existing Storybook access story, with image and alignment checks. - Extend the service test to check saved images and missing images. ## Verification - Token gates and `git diff --check` pass. - The 33 existing chat setup and identity-link UI tests pass. - The OAuth installer service regression test passes. - Chromium rendered the Storybook Access story at desktop and mobile sizes. The avatar, name block, and Disconnect button centers all measured 307 CSS pixels on desktop. - UI typecheck passes. Full repository typecheck and build stop at the Rust runner because this workspace has no `cargo`. The initial parallel typecheck also exceeded the 4 GiB workspace limit. The full local test attempt was stopped as memory approached the 4 GiB limit; it has no complete verdict. CI passed the full build, typecheck, test, and E2E lanes on the initial commit. The previously reviewed commit passed 54 checks with two intentionally skipped Storybook checks. Master was merged on October 10 to resolve an import conflict; fresh CI is running for `24badb742d331c1b6ee3e90cbd06defefe5cd634`. Token gates and whitespace checks pass after conflict resolution. The single retry after CI runner shutdowns passed. Greptile gives this commit 5/5, with both review threads resolved. ### Screenshots The Storybook fixture shows an image, fallback initials, and a pending account.   ## Risks Low risk. The API field is additive and needs no migration. The image uses the same avatar primitive as other user identities. Missing or failed images retain the initials fallback. Other chat providers share this access row. ## Model Used OpenAI Codex, GPT-6. Tool use and code execution. The runtime does not expose a more specific model ID or 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 - [ ] 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-10-12 23:54:01 -05:00
Devin FoleyandPaperclip	6c198d616e	fix(issues): preserve human handoffs from the active agent run (#16082) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Tasks have one owner, and the server records assignment changes. > - An agent can finish its work by handing the task to a human for review. > - The assignment route stops the active run before it saves that handoff. > - When the caller is that run, a slow workspace restore can exceed the stop timeout and prevent the assignment from saving. > - Recovery can then mark the task Blocked while its comment says the handoff succeeded. > - This pull request lets the authenticated legacy run save a human handoff and finish its turn normally. > - Other actors and transfers to executable agents keep the verified stop requirement. ## Linked Issues or Issue Description Refs #13730. Related: #13782, #14700, and #15094. **What happened?** An agent posted its review handoff, then sent `PATCH /api/issues/{id}` to assign the task to its human creator with status `in_review`. The route cancelled that same run before saving the assignment. Workspace restore took 66 seconds. The stop limit is 60 seconds. The assignment never committed. Recovery marked the task Blocked, and it stayed assigned to the agent. **Expected behavior** The authenticated active legacy run can hand its own task to a human and finish normally. The human assignment and requested review status must save without waiting for workspace restore. Native runs, board reassignment, agent API keys, and transfers to another agent still require a verified stop. **Steps to reproduce** 1. Run a legacy agent on its assigned task with a signed run token. 2. Send a task PATCH from that run with a human `assigneeUserId`, a null `assigneeAgentId`, and status `in_review`. 3. Make stopping the sandbox take more than 60 seconds. Before this fix, the handoff fails before the task update. With this fix, the update saves and the run finishes normally. **Paperclip version or commit** Reproduced in hosted execution. The patch is based on master at `56a0bf0d492`. **Deployment mode** Hosted authenticated server with a legacy agent in a remote sandbox. The same route serves local deployments. PR #13782 proposes a broader exemption for all self-handoffs. This focused change limits the exemption to human recipients and legacy runs. It checks the exact active run, agent, company, and task, and it retains the stop requirement before an executable successor can take ownership. PRs #14700 and #15094 address later wake and recovery behavior after a reassignment stop. ## What Changed - Skip the reassignment cancellation only for an authenticated legacy run handing its own task to a human. - Reject later mutations from the outgoing run against its human-owned task, both in route authorization and under the update transaction locks. - Keep assignment permission checks, goal control, and queued human response protection. - Add route regressions for slow stops, active-run lookup, actor and runtime boundaries, recipient types, permission denials, and follow-up edits, completion, and reassignment. - Update the real HTTP low-trust handoff test to prove the run stays alive, its late edit fails, and the human wake receipt remains invalidated. - Add Postgres tests for saved assignment, former-owner rejection, and review state after the outgoing run succeeds or fails. - Document the handoff rule and update the task feature and agent access maps. ## Verification - 328 relevant tests passed across the route, issue service, low-trust HTTP, and legacy recovery suites. The route suite passed all 160 tests, and all 13 low-trust HTTP tests passed after updating the obsolete cancellation expectation. - Removing the production guard makes both slow-shutdown handoff regressions fail with HTTP 500. - `pnpm -r typecheck` passed. - `pnpm build` passed. - `node scripts/check-maps.mjs` passed. - `git diff --check` passed. - All 54 current-head checks passed; 2 optional Storybook checks were skipped. The CI lanes cover the full Vitest suite, typecheck/build, Runner checks, and product E2E checks. - Apex reviewed `c68fbfb356c3d80eb7136babb49940709a3c3459` at 5/5 with no findings; both earlier review threads are resolved. - The complete test lanes passed in CI. The duplicate local full `pnpm test:run` was stopped after CI completed; it did not finish locally. All 328 focused local tests and full local typecheck/build passed. ## Risks - The outgoing legacy turn stays alive after the human takes ownership. Route and transactional ownership checks reject its later mutations of the human-owned task. Read and comment access follows normal policy. Goal control still runs before the handoff. - This exemption does not apply to native runs or another agent as recipient. Those paths still stop the old execution before assignment. - This fix prevents future failed handoffs. It does not infer or replay old assignment requests. - There is no schema change or API shape change. ## Model Used OpenAI GPT-6 through Codex, with reasoning, repository tools, and code execution. The session does not expose a more specific runtime model ID or 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-10-12 20:34:28 -07:00
DottaandPaperclip	e168512f7b	perf(chat): stop polling failed run retries (#15871) ... Stop one-second scans of failed chat-run retries. Wake the existing retry queue after transaction commits and at saved retry or stale-claim deadlines. Preserve claim fences, authorization, recovery, and idempotent agent admission. Resolve conflicts with the current chat-service extraction by applying the retry signals and shared deadline predicate in the failed-run retry module. Verified with pnpm typecheck, pnpm build, all 1,328 chat and coordinator regression tests, and current-head CI. Greptile reviewed the final head at 5/5 with no unresolved threads. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-12 19:49:47 -07:00
3 people	56a0bf0d49	Support test Cloud connector identities (#16033) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Its Cloud connector uses an environment-bound identity to call a hosted broker. > - The identity parser and enrollment flow accept development, staging, and production. > - A separate test broker needs its own environment identity. > - This pull request accepts test identities and maps the test broker to that environment. > - Known hosted brokers still reject identities from other environments. ## Linked Issues or Issue Description **What existing behavior does this improve?** Cloud connector configuration and self-host enrollment. **Current behavior** The app rejects an identity with environment `test`. Self-host enrollment infers development for the test broker. **Proposed behavior** Accept `test` identities at `https://test.paperclip.app`. Infer test during self-host enrollment. Reject development, staging, and production identities at that broker. Continue to reject test identities at the production and staging brokers. **Reason and benefit** Branch testing needs a separate broker so test identities and requests stay in their selected environment. The existing identity, enrollment, and signature flow can provide that isolation with a new allowed environment value. **Breaking changes** Existing environment values and broker checks keep their current behavior. Older app versions cannot use test connector identities. ## What Changed - Add `test` to managed and self-hosted connector environment types and validation, and to the board API enrollment status type. - Infer test from its hosted broker and enforce the matching environment. - Test enrollment persistence, signed request environment/audience claims, and broker mismatch rejection. - Document test broker configuration in the development guide. ## Verification - Connector, enrollment, and board API-client suites passed: 63 tests across three files. Board UI typecheck and token gates passed after synchronizing its enrollment response type. - `pnpm -r typecheck` and `pnpm build` passed, including after rebasing onto current master. - `pnpm test:run` completed its general server stage: 17,867 passed, 105 skipped, and 9 failed across 5 files. The runner stops at that failing stage, so it did not run subsequent workspace/serialized stages locally. All nine failures also reproduce on the unchanged base commit in a separate checkout. Five skill-related cases resolve an unrelated ancestor skills directory; two workspace cases accept a remote main branch that their fixture expects to be absent; two permission-cleanup cases return macOS `ENOTEMPTY` instead of the expected permission error. - Current-head GitHub CI passed, including full general and serialized test suites, typecheck, build, runner checks, and browser e2e. Greptile is 5/5 with no unresolved comments. - `git diff --check` and Gitleaks passed. ## Risks The new environment value is additive. The test broker must support test identities before use. This change preserves existing signature handling, managed identity overrides, and rejection of mismatched identities at known hosted brokers. A local full-suite pass is not claimed; the nine failures above also occur without this change. ## Model Used OpenAI Codex, GPT-6, with reasoning and tool execution. The exact serving model ID and context window are not exposed in this session. ## 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 - [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> Co-authored-by: Dotta <34892728+cryppadotta@users.noreply.github.com>	2026-10-12 19:32:33 -07:00
3 people	83e13db8fa	fix(inbox): keep automatic recovery cleanup out of personal participation (#16063) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The personal inbox uses issue activity to identify a person's participation. > - Issue reads can cancel stale recovery actions and record that cleanup as the reader's action. > - This adds unrelated tasks to the inbox and refreshes their activity timestamps. > - A workspace owner hold can also alternate between creation and cancellation after a task finishes. > - This pull request corrects cleanup attribution, excludes historical read cleanup, and retains one exact owner hold. > - Agents can read authorized issue activity to diagnose the same problem themselves. ## Linked Issues or Issue Description Refs #15742 excludes logs by the execution-recovery actor from activity timestamps. This PR covers reader-attributed stale recovery cleanup, personal inbox participation, exact workspace owner holds, and sandbox issue activity access. I searched open issues and PRs for recovery inbox and activity bridge fixes. I found no duplicate for this defect. **What happened?** Loading issue lists cancels stale recovery actions under the reader's identity. The personal inbox treats those rows as user participation. One completed issue had hundreds of such rows and no edits or comments by the affected reader. A retained native workspace owner repeatedly creates a verification action that read projections then cancel. Sandbox agents cannot inspect the issue activity because the reverse bridge rejects the route. **Expected behavior** Automatic cleanup belongs to the system and does not add an issue to a reader's inbox. Historical cleanup rows remain auditable but do not count as participation or recent activity. An unresolved physical workspace owner keeps one stable verification action. Agents can inspect activity only for issues their identity may read. **Steps to reproduce** 1. Finish a task whose native run retains an unverifiable workspace owner receipt. 2. Repeat workspace recovery checks and GET requests for issue detail, compact lists, and recovery actions. 3. Observe new recovery action IDs and reader-attributed cancellations in the activity history. 4. Query the personal inbox for that reader and observe the unrelated task. 5. From a sandbox agent, request GET /api/issues/:id/activity and observe Route not allowed. **Paperclip version or commit** Observed at f5346c05b9. Regression tests use current master behavior. **Deployment mode** Authenticated hosted instance with native and legacy sandbox agents. The inbox defect is independent of the adapter. ## What Changed - Attribute automatic stale recovery cleanup to the recovery system actor. - Exclude exact historical read cleanup rows from personal inbox membership, unread counts, and both activity timestamp queries. Keep all audit rows and explicit user recovery decisions. - Retain owner verification holds only while the exact company, run, issue, and owner fingerprint still match. Apply the same rule to reads and background recovery. - Make repeated checks for the same owner hold leave its identity, attempts, and timestamps unchanged. Keep physical takeover blocked. - Allow GET issue activity through the sandbox bridge. Keep the existing company and issue-read authorization and reject broader audit routes. - Add regressions and update the runtime API and recovery documentation. Refresh generated source references for the documentation edits. Update the paired activity, inbox, and recovery maps. ## Verification - Focused Vitest verification: 315 tests pass across five files. The updated terminal owner hold regression also passes. The files cover issue service, recovery routes, activity authorization, sandbox callback bridge, and native workspace finalization. - `pnpm -r typecheck` and `pnpm build` pass locally. The full general and serialized unit test matrix passes in CI on the latest commit. The duplicate local `pnpm test:run` was stopped after about 30 minutes once that full CI coverage passed; it did not report a local full-suite pass. - `node scripts/check-maps.mjs` passes for all paired areas and capability IDs. - Apex is 5/5 on commit 44c3787888. Its access map finding is fixed and resolved. All CI checks are green on this commit. - The new regression repeats reads and background sweeps for done and cancelled tasks. It checks one unchanged hold, zero physical copyback, zero personal inbox participation, and system cleanup after the exact receipt is cleared. - Historical cleanup tests preserve explicit recovery decisions, nullable metadata, unread counts, and the original audit rows. - Authorization tests permit an authorized agent and reject cross-company or issue-boundary reads. Bridge tests reject write methods, extra path segments, and company-wide audit routes. ## Risks Existing inbox items can disappear if their only participation evidence was automatic read cleanup. No data migration or audit deletion is needed. An unresolved workspace owner remains visible after task completion; this preserves the physical writer fence. A stale or cleared owner does not retain the hold. Issue activity access expands only the sandbox transport allowlist and still uses existing controller authorization. ## Model Used OpenAI GPT-6 through Codex, with reasoning, repository inspection, code editing, shell execution, and test tools. The session identifies the model family as GPT-6. A more specific runtime model ID and context window size are not exposed. ## 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> Co-authored-by: Amy (Opus) <noreply@anthropic.com>	2026-10-12 19:25:15 -07:00
DottaandPaperclip	f329b24ee1	feat: give tasks durable project-optional workspaces (#15749) ... Give tasks durable company-scoped workspace bindings independent of project assignment, channel defaults and authorized repository preparation. Reuse verified input seeds and sparse output recovery while preserving trust, privacy and controller provisioning boundaries. Full CI and E2E, Superagent, legacy checks and Greptile Apex 5/5 passed on reviewed head 753680b61c. All review findings are resolved; the PR records focused verification and historical acceptance limits. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-10-12 20:45:18 -05:00
3 people	4b958ecbd8	fix(server): keep classified provider quota runs out of Sentry (#16029) ... A run that stops because the user's provider account hit its usage limit is an expected wait, not a Paperclip defect. The adapter already classifies it (errorCode and resultJson.errorFamily are both provider_quota) and recovery schedules a retry at the reset time. Skip the Sentry report only when both adapter-owned fields agree, the run status is failed, no signal stopped it, and the failure did not happen during setup. Timeouts, cancellations, signals, other codes and missing or mismatched families still report. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Co-Authored-By: Dotta <cryppadotta@users.noreply.github.com>	2026-10-12 15:59:27 -07:00