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
Devin Foley	daea92b647	feat(server): accept a Cloud control assertion on the task-drain endpoint (#13125) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The server has a task-drain admission hold so operators can stop new agent work and wait for quiescence before maintenance > - Cloud deploys restart tenant containers, but the Cloud control plane has no sanctioned credential for the drain routes, so agent runs are killed mid-restart > - The only Cloud credential this server trusts is the runtime identity assertion, deliberately scoped to the one-time bootstrap health call > - This pull request adds a disjoint, action-bound Cloud control assertion accepted only on the task-drain endpoint > - The benefit is that Cloud can hold new work and drain a stack before it restarts the container, through the same authorization and audit paths a human operator uses ## Linked Issues or Issue Description Refs #12485 (the task-drain admission hold this makes reachable for the Cloud control plane). **Problem or motivation** Cloud deploys restart the container without stopping agent work first. The task-drain hold from #12485 exists for exactly this, but its routes require instance-admin board authority. The Cloud control plane holds no such credential: the runtime identity assertion is accepted only on `GET /api/health`, by design. So in-flight runs die at every deploy. **Proposed solution** A second, deliberately disjoint use of the same Cloud signing key (`PAPERCLIP_CLOUD_RUNTIME_IDENTITY_JWKS`): a control assertion with its own JWS type (`paperclip-cloud-control+jwt`), its own audience, an `action` claim, a request id, and a short maximum lifetime. A new middleware accepts the `x-paperclip-cloud-control` header only on `/api/instance/task-drain`, binds each method to one exact action (`task-drain:read` / `task-drain:start` / `task-drain:stop`), verifies the assertion against the configured JWKS and `PAPERCLIP_CLOUD_STACK_ID`, and installs a synthetic instance-admin board actor so the existing route authorization, validation, transactional audit, and activity publishing run unchanged (audit rows record actor id `paperclip-cloud`). The header is rejected with 400 anywhere else, so it can never become an ambient credential. The board mutation guard exempts the new `cloud_control` source exactly like the other non-browser lanes. **Alternatives considered** Widening the existing runtime identity middleware would conflate a one-time bootstrap claim with a repeatable management credential and weaken both. A per-stack minted instance-admin API key would work with no auth change but adds a long-lived privileged credential per tenant to store and rotate. The action-bound short-lived assertion keeps authorization per-call and stateless. **Additional context** Self-hosted instances have no `PAPERCLIP_CLOUD_STACK_ID` and reject every assertion — the feature is inert off Cloud. A runtime identity token cannot replay as a control token or vice versa (disjoint `typ` and `aud`, covered by tests). The Cloud-side caller (drain before deploy, bounded quiescence wait) lands separately in the Cloud control plane. ## What Changed - `server/src/services/cloud-runtime-identity.ts`: `verifyCloudControlAssertion` plus the control header/audience/type/action constants, reusing the existing JWKS resolution, JWS parsing, and lifetime discipline. - `server/src/middleware/cloud-control.ts` (new): accepts the header only on the task-drain endpoint, per-method action binding, installs the synthetic instance-admin actor on success, 401 on invalid assertions, 400 anywhere else. - `server/src/app.ts`: mounts the middleware directly after the actor middleware, so a valid assertion replaces whatever actor the request otherwise resolved to. - `server/src/middleware/board-mutation-guard.ts`: `cloud_control` joins the non-browser exemptions. - `server/src/types/express.d.ts`, `server/src/services/authorization.ts`: `"cloud_control"` added to the actor source unions. ## Verification - `pnpm exec vitest run --project @paperclipai/server server/src/__tests__/cloud-control-task-drain.test.ts server/src/__tests__/instance-settings-routes.test.ts server/src/__tests__/heartbeat-task-drain.test.ts server/src/__tests__/heartbeat-scheduling-suppression.test.ts server/src/__tests__/cloud-runtime-identity.test.ts` — 87 tests, all passing. - `pnpm --filter @paperclipai/server exec tsc --noEmit` reports no new errors against the base commit's known pre-existing set. - The new suite covers: acceptance per method, cross-action rejection, unknown-action rejection, runtime-identity-token replay rejection, wrong-audience rejection, wrong-stack and self-hosted rejection, expiry and oversized-lifetime rejection, unknown-key rejection, request id validation, endpoint containment (400 elsewhere, 400 on unbound methods), pass-through without the header, and the mutation-guard exemption. ## Risks Low risk, additive. No behavior changes without the header; the header grants nothing outside the one endpoint; each assertion authorizes one action for at most five minutes; the existing route-level validation, queued transitions, and audit writes are unchanged. The browser-facing Cloud proxy strips Cloud headers, and possession of the shared tenant-session token cannot mint an assertion (signing key never leaves Cloud). ## Model Used Claude (Anthropic) — Fable 5 (`claude-fable-5`), extended thinking, agentic tool use via Claude Code. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes (module doc comments carry the contract) - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-09-10 11:56:28 -07:00