2 Commits

Include renames

Author	SHA1	Message	Date
DottaandClaude Opus 5.5	b184e40108	perf(ui): serve every project list from one includeArchived read (#20395) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The board UI reads the company project list in many places: the sidebar, starred projects, the command palette, the new-task dialog, and archive-aware pages such as the Mine inbox > - Active-only consumers read `GET /projects`, and archive-aware ones read `GET /projects?includeArchived=true`, under two React Query keys > - A Mine load therefore fetched the same large payload twice (580–590 KB each on our dev instance) > - The two responses differ only by archived rows; the server's active list is exactly the rows where `archivedAt` is null > - This pull request makes every consumer share the `includeArchived=true` query, and active-only consumers filter it with `select` > - The benefit is one project read per page instead of two ## Linked Issues or Issue Description **What existing behavior does this improve?** Duplicate project list reads on page load. **Subsystem affected** Board UI project queries (`ui/src/lib/company-projects-query.ts` and its consumers). **Current behavior** A cold Mine load sends both `/companies/:id/projects` (sidebar) and `/companies/:id/projects?includeArchived=true` (inbox). **Proposed behavior** One `includeArchived=true` read serves both. Active-only consumers apply `selectActiveProjects`. **Reason and benefit** The project list is one of the largest shell payloads. Reading it once saves a large response on every page that has both kinds of consumer. ## What Changed - New `companyProjectsQuery(companyId, { includeArchived? })` in `ui/src/lib/company-projects-query.ts`. It always uses the `includeArchived: true` key and fetch. For active-only use it adds a stable, module-level `select` that keeps rows without `archivedAt`. - 22 files that read the active list now spread `companyProjectsQuery(...)`, and so do the plugin SDK project picker and 16 archive-aware pages that wrote the shared key and fetcher inline. Their `enabled` and other options are unchanged. `OnboardingWizard`'s one imperative read is unchanged. `pages/Inbox.tsx` already reads the same key and fetcher, so it shares the entry without an edit. - Invalidation: project mutations and live events invalidate `queryKeys.projects.all(companyId)`, which matches the shared key. The onboarding wizard invalidated the old active-only key; it now invalidates `projects.all`. - Tests: new `company-projects-query.test.tsx` (one request for both consumers, correct filtering, and one refetch after `projects.all` invalidation). Three existing tests (`CommandPalette`, `CompanyExport`, `GitHubBotManagement`) now seed or expect the shared key. - New browser check `tests/perf/collections/shared-project-list.spec.ts`: after the Mine inbox read completes, the page has sent no active-only project request. ## Verification - `pnpm verify` passes. - `ui`: the consumer suites (`CoordinatorSidebar`, `SidebarProjects`, `SidebarStarredProjects`, `CommandPalette`, `NewIssueDialog`, `AgentWorkPanels`, `CoordinatorNeedsYou`, `IssueDetail`, `ProjectDetail`, `Projects`, `CompanyExport`, `ChatExecutionDefaults`, `GatewaysList`, `Search`, `IssueProperties`, `persisted-query-cache`) pass. - Browser check: `PAPERCLIP_COLLECTION_PERF_BASE_URL=http://127.0.0.1:<port> pnpm exec playwright test --config tests/perf/collections/playwright.config.ts shared-project-list.spec.ts`. It passes on this branch and fails on `master`. ## Risks - A page that needs only active projects now downloads archived rows too. For most companies that is a small difference; the duplicate read it removes is a full copy. - The server does not order either list, and consumers sort for display, so filtering on the client keeps behavior. ## Model Used - Claude Opus 5.5 (`claude-opus-5-5`), Anthropic, via Claude Code with tool use (shell, file edits, browser). 1M-token context window. Extended thinking was off. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-09 17:42:47 -06:00
DottaandPaperclip	d0c8f0b090	fix: explain project access denials and add an authorized repair path (#17509) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Low-trust agents may read only the projects in their allowed scope. > - Workspace setup correctly stops a task outside that scope. > - The task previously showed a generic failure, and agent settings did not offer an additive repair. > - This pull request explains the denial and lets authorized operators add projects while preserving other restrictions. > - The saved task then offers an explicit retry. Saving access does not start work. ## Linked Issues or Issue Description **What happened?** A project access denial appeared as an ordinary failed attempt. Operators could not add a second allowed project from agent settings. **Expected behavior** The task should explain the denied access and link to a working permission editor. The editor should preserve existing scope and restrictions, enforce operator authority, and retain drafts after a failed save. **Steps to reproduce** 1. Assign a low-trust agent to a task whose project is outside its allowed projects. 2. Let workspace setup deny project access. 3. Open the task, follow Manage project access, add the project, save, reload, and return to the task. 4. Confirm that the saved message remains and Retry task is a separate action. ## What Changed - Record a typed, non-retryable project denial before provider dispatch. Project denials do not enter automatic continuation or provider comment policy. - Project current and historical setup denials into a safe task notice. Keep unrelated failures, prior assignees, and approval/pause/budget gates separate. Recheck current project authority, including standard trust and root-issue grants. Accepted retries keep their working state. - Add board-only project-access reads and additive saves under the agent row lock. Enforce company scope, agent-management authority, pending-approval restrictions, and an audit record for new additions. - Add the production notice and searchable multi-project editor, including read-only, saving, cancellation, and failed-save states. Preserve the return-to-task query through canonical agent redirects. - Register board-only project-access routes in OpenAPI with a strict request schema. - Add production Storybook examples and API/persistence/concurrency regressions. Retain the approved design snapshot and update the behavior maps and implementation contract. ## Verification - Passed: `pnpm -r typecheck`, `pnpm build`, `pnpm build-storybook`, `pnpm check:token-gates`, `node scripts/check-maps.mjs`, and `node scripts/storybook-catalog.mjs`. - Passed: 11 permission/projection tests and 30 run-completion tests against an isolated PostgreSQL database. These cover historical failures, concurrent additions, idempotent audit, preserved restrictions, foreign projects, read-only users, agent self-grants, and no automatic wakeup. - Passed: all 27 OpenAPI route tests, including route coverage and the new board-only request/response contract. - Browser: the real app displayed a historical denial; Manage project access opened the editor; saving retained the original project and survived reload; Return to task showed the ready notice. Saving created one audit event and zero runs. Explicit Retry returned 202 and reached the separate sandbox requirement, which remained enforced. No external provider was used. - All five production Storybook interaction checks pass: blocked task, save, cancellation, failed-save recovery, and read-only settings. These use fixture callbacks; durable authorization is covered separately above. - `pnpm test:run` was attempted locally but stopped after repeated embedded PostgreSQL startup failures caused by macOS semaphore exhaustion. Full-suite CI is required before merge. The separate UI suite passed all 9,095 tests. The 41 focused server regressions also passed after rebasing onto the latest master. A further 26 recovery-classification tests pass, including a red-to-green regression for automatic continuation after a project denial. ## Risks - No schema migration. The new endpoint only adds same-company project IDs and preserves the rest of the stored policy. - The historical notice recognizes one exact setup denial message. It does not display arbitrary run errors or disclose a different source project's identity. - The retry still passes all current admission and isolation checks. The notice does not promise that other execution requirements are satisfied. - Related open work: #13309 covers inherited secret restrictions; #11234 covers the broader repository catalog. This change does not replace either policy surface. ## Model Used OpenAI Codex (GPT-6), with code execution and browser tools. The precise runtime 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 #` 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 (focused server and full UI suites; full-suite infrastructure limit above) - [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-24 16:16:29 -07:00