2 Commits

Include renames

Author	SHA1	Message	Date
Devin Foley	8c6cc7dccf	feat(cloud): sync primary-company archive state with the Cloud control plane (#13837) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Paperclip Cloud runs managed instances and controls their lifecycle from a control plane. > - Inside the app, a person can archive a company. On a managed instance, the Cloud-pinned primary company is the whole organization. > - Today that archive stays local. The control plane does not learn about it, so it keeps the instance running and shows the organization as live. > - This pull request notifies the control plane when the primary company crosses the archived boundary, and adds two control endpoints so the control plane can verify the state and undo the archive during a restore. > - The benefit is that an archived organization stops running and shows as archived, and a restore brings the company back without manual steps. ## Linked Issues or Issue Description No public issue exists. Description follows the enhancement template: **What existing behavior does this improve?** Company archive on Cloud-managed instances. Archiving the primary company pauses agents and cancels runs, but the hosting control plane never learns about it. **Subsystem affected** Server: company service, cloud-control middleware, instance routes. **Current behavior** A person archives the primary company. The instance keeps running. The Cloud portfolio still shows the organization as live. Unarchive after a Cloud restore requires manual steps inside the product. **Proposed behavior** The company service rings a Cloud lifecycle doorbell when the primary company is archived or unarchived. The control plane verifies the state through `GET /api/instance/lifecycle` before it acts. During a restore, the control plane calls `POST /api/instance/lifecycle/unarchive-primary` to bring the company back. Self-hosted instances are not affected. **Reason and benefit** An archived organization should not keep running, and its hosting console should show it as archived. The verified read-back keeps the doorbell a hint: a forged or duplicated ring cannot change state. ## What Changed - New `services/cloud-lifecycle-sync.ts`: fire-and-forget doorbell `POST {cloudOrigin}/v1/tenant/lifecycle-changed` with bounded retries. It runs only on cloud-managed instances, and only for the derived primary company id. It never blocks or fails the company mutation. - `services/companies.ts`: ring the doorbell after a committed archive or unarchive transition, in both the `update()` status-patch path and `archive()`. - New `GET /api/instance/lifecycle`: reports the primary company id, its status, and how many other companies are not archived. Bound to a `lifecycle:read` Cloud control assertion; board members can also read it. - New `POST /api/instance/lifecycle/unarchive-primary`: idempotent unarchive of the primary company as a system actor. Bound to `lifecycle:unarchive-primary`; requires instance admin otherwise. - `middleware/cloud-control.ts`: a closed endpoint→method→action table replaces the single hardcoded endpoint. Each assertion still authorizes exactly one action on one endpoint. - `services/cloud-instance.ts`: the primary-company id derivation moves here as the single definition; `middleware/auth.ts` delegates to it. The derivation itself is unchanged. ## Verification - `pnpm exec tsc --noEmit` in `server/` is clean. - `pnpm exec vitest run src/__tests__/cloud-lifecycle-sync.test.ts src/__tests__/cloud-control-task-drain.test.ts src/__tests__/instance-settings-routes.test.ts src/__tests__/companies-service.test.ts src/__tests__/cloud-tenant-company-provisioning.test.ts` — all pass. - New tests cover: doorbell env-gating, retry bounds, no-throw contract; the read-back status and sibling count; idempotent unarchive and the admin gate; non-cloud 404s; control-assertion action binding for the new endpoints, including cross-action and wrong-method rejection; and a companies-service test that proves the doorbell rings exactly on archived-boundary transitions. ## Risks - Self-hosted instances see no behavior change: without a Cloud signal the doorbell is a no-op and the endpoints answer 404. - The doorbell is advisory by design. The control plane verifies through the read-back before it acts, so a lost or duplicated ring cannot corrupt state. - The unarchive endpoint reuses the existing `companyService.update` path, so agent reactivation and activity logging behave exactly like an in-product unarchive. ## Model Used - Claude Fable 5 (`claude-fable-5`), via Claude Code CLI, extended thinking and tool use enabled. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-09-22 17:49:15 -07:00
DottaandPaperclip	5858ccb981	feat: make in-app features cloud-aware (#10850) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Operators use the same board application in self-hosted and Paperclip Cloud deployments. > - A Cloud tenant contains one company, so an in-app company switch does not change the active Cloud stack. > - Cloud operators need the sidebar and company surfaces to use the signed-in user's stack portfolio. > - The server must derive Cloud identity and links from trusted instance context instead of client input. > - This pull request adds canonical Cloud context, a trusted stack portfolio proxy, and Cloud-aware navigation. > - The benefit is consistent stack switching on Cloud while self-hosted company behavior stays unchanged. ## Linked Issues or Issue Description **Subsystem affected** Cross-cutting: server REST routes and the React board UI. **Problem or motivation** A Cloud-managed instance contains one company. The existing company switcher could only switch records inside that tenant. It could not move the operator to another Cloud stack. The existing header also gave long organization names too little width. **Proposed solution** Expose a canonical public Cloud context in health data. Add a trusted server proxy for the current user's stack portfolio. Use that data in the board UI to switch stacks with top-level navigation. Keep the existing company behavior on self-hosted instances. Move search into the navigation and keep long organization names inside the sidebar panel. **Alternatives considered** An in-app `/stacks` route was rejected because Cloud tenant hosts reserve that path and stack selection must wake or authenticate another tenant. Client-supplied user identity was rejected because the server can derive the trusted Cloud actor. **Roadmap alignment** This change advances the Cloud deployments milestone. It keeps the product local-first and Cloud-ready without changing the self-hosted mental model. ## What Changed - Added canonical Cloud instance context and public health metadata. - Added a Cloud-only stack portfolio proxy with trusted actor forwarding and per-user caching. - Prevented normal company creation on Cloud-managed instances. - Switched the sidebar and Companies page from company actions to stack actions on Cloud. - Added full-page stack navigation and Cloud create-stack links. - Moved search into the sidebar navigation so the organization name keeps more width. - Added truncation and hover recovery for long organization and stack names. - Added server and UI regression coverage for Cloud and self-hosted behavior. - Updated the implementation specification for the Cloud contracts. ## Verification - `node scripts/check-token-gates.mjs` passed. All three token gates are clean. - `pnpm --dir server exec vitest run src/__tests__/health.test.ts src/__tests__/cloud-instance.test.ts src/__tests__/cloud-routes.test.ts src/__tests__/company-cloud-floor.test.ts src/__tests__/company-portability-routes.test.ts` passed: 5 files and 66 tests. - `pnpm --dir ui exec vitest run src/components/SidebarCompanyMenu.test.tsx` passed: 1 file and 11 tests. - Pre-PR QA report `7da87ca7` passed all 8 acceptance criteria with real HTTP route factories and real Chromium screenshots in Cloud and self-hosted modes. - Security reviews passed for the canonical Cloud context and stack portfolio proxy. ## Risks - Cloud stack switching depends on the configured Cloud application and tenant portfolio URLs. - The new health `cloud` block is public by design, but it contains only canonical public instance metadata. - The stack proxy fails closed on self-hosted instances and derives the user identity from the trusted actor. - Self-hosted navigation and company creation retain their existing paths and behavior. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, model `gpt-5`. The run used reasoning, repository tools, shell execution, and GitHub integration. The deployment did not expose its context-window size. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-04 23:00:14 -05:00