eliott/paperclip
1
0
Fork 0
mirror of https://github.com/paperclipai/paperclip synced 2026-04-25 17:25:15 +02:00
Code Issues Packages Projects Releases Wiki Activity
Files
fe14de504cdacc64cd58578c7d8617cd66ebe912
paperclip/doc/DEPLOYMENT-MODES.md
Dotta b9a80dcf22 feat: implement multi-user access and invite flows (#3784) 
## Thinking Path

> - Paperclip is the control plane for autonomous AI companies.
> - V1 needs to stay local-first while also supporting shared,
authenticated deployments.
> - Human operators need real identities, company membership, invite
flows, profile surfaces, and company-scoped access controls.
> - Agents and operators also need the existing issue, inbox, workspace,
approval, and plugin flows to keep working under those authenticated
boundaries.
> - This branch accumulated the multi-user implementation, follow-up QA
fixes, workspace/runtime refinements, invite UX improvements,
release-branch conflict resolution, and review hardening.
> - This pull request consolidates that branch onto the current `master`
branch as a single reviewable PR.
> - The benefit is a complete multi-user implementation path with tests
and docs carried forward without dropping existing branch work.

## What Changed

- Added authenticated human-user access surfaces: auth/session routes,
company user directory, profile settings, company access/member
management, join requests, and invite management.
- Added invite creation, invite landing, onboarding, logo/branding,
invite grants, deduped join requests, and authenticated multi-user E2E
coverage.
- Tightened company-scoped and instance-admin authorization across
board, plugin, adapter, access, issue, and workspace routes.
- Added profile-image URL validation hardening, avatar preservation on
name-only profile updates, and join-request uniqueness migration cleanup
for pending human requests.
- Added an atomic member role/status/grants update path so Company
Access saves no longer leave partially updated permissions.
- Improved issue chat, inbox, assignee identity rendering,
sidebar/account/company navigation, workspace routing, and execution
workspace reuse behavior for multi-user operation.
- Added and updated server/UI tests covering auth, invites, membership,
issue workspace inheritance, plugin authz, inbox/chat behavior, and
multi-user flows.
- Merged current `public-gh/master` into this branch, resolved all
conflicts, and verified no `pnpm-lock.yaml` change is included in this
PR diff.

## Verification

- `pnpm exec vitest run server/src/__tests__/issues-service.test.ts
ui/src/components/IssueChatThread.test.tsx ui/src/pages/Inbox.test.tsx`
- `pnpm run preflight:workspace-links && pnpm exec vitest run
server/src/__tests__/plugin-routes-authz.test.ts`
- `pnpm exec vitest run server/src/__tests__/plugin-routes-authz.test.ts
server/src/__tests__/workspace-runtime-service-authz.test.ts
server/src/__tests__/access-validators.test.ts`
- `pnpm exec vitest run
server/src/__tests__/authz-company-access.test.ts
server/src/__tests__/routines-routes.test.ts
server/src/__tests__/sidebar-preferences-routes.test.ts
server/src/__tests__/approval-routes-idempotency.test.ts
server/src/__tests__/openclaw-invite-prompt-route.test.ts
server/src/__tests__/agent-cross-tenant-authz-routes.test.ts
server/src/__tests__/routines-e2e.test.ts`
- `pnpm exec vitest run server/src/__tests__/auth-routes.test.ts
ui/src/pages/CompanyAccess.test.tsx`
- `pnpm --filter @paperclipai/shared typecheck && pnpm --filter
@paperclipai/db typecheck && pnpm --filter @paperclipai/server
typecheck`
- `pnpm --filter @paperclipai/shared typecheck && pnpm --filter
@paperclipai/server typecheck`
- `pnpm --filter @paperclipai/ui typecheck`
- `pnpm db:generate`
- `npx playwright test --config tests/e2e/playwright.config.ts --list`
- Confirmed branch has no uncommitted changes and is `0` commits behind
`public-gh/master` before PR creation.
- Confirmed no `pnpm-lock.yaml` change is staged or present in the PR
diff.

## Risks

- High review surface area: this PR contains the accumulated multi-user
branch plus follow-up fixes, so reviewers should focus especially on
company-boundary enforcement and authenticated-vs-local deployment
behavior.
- UI behavior changed across invites, inbox, issue chat, access
settings, and sidebar navigation; no browser screenshots are included in
this branch-consolidation PR.
- Plugin install, upgrade, and lifecycle/config mutations now require
instance-admin access, which is intentional but may change expectations
for non-admin board users.
- A join-request dedupe migration rejects duplicate pending human
requests before creating unique indexes; deployments with unusual
historical duplicates should review the migration behavior.
- Company member role/status/grant saves now use a new combined
endpoint; older separate endpoints remain for compatibility.
- Full production build was not run locally in this heartbeat; CI should
cover the full matrix.

## Model Used

- OpenAI Codex coding agent, GPT-5-based model, CLI/tool-use
environment. Exact deployed model identifier and context window were not
exposed by the runtime.

## 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 run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] If this change affects the UI, I have included before/after
screenshots
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] I will address all Greptile and reviewer comments before
requesting merge

Note on screenshots: this is a branch-consolidation PR for an
already-developed multi-user branch, and no browser screenshots were
captured during this heartbeat.

---------

Co-authored-by: dotta <dotta@example.com>
Co-authored-by: Paperclip <noreply@paperclip.ing>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-17 09:44:19 -05:00

4.8 KiB
Raw Blame History

Deployment Modes

Status: Canonical deployment and auth mode model
Date: 2026-02-23

1. Purpose

Paperclip supports two runtime modes:

  1. local_trusted
  2. authenticated

authenticated supports two exposure policies:

  1. private
  2. public

This keeps one authenticated auth stack while still separating low-friction private-network defaults from internet-facing hardening requirements.

Paperclip now treats bind as a separate concern from auth:

  • auth model: local_trusted vs authenticated, plus private/public
  • reachability model: server.bind = loopback | lan | tailnet | custom

2. Canonical Model

Runtime Mode Exposure Human auth Primary use
local_trusted n/a No login required Single-operator local machine workflow
authenticated private Login required Private-network access (for example Tailscale/VPN/LAN)
authenticated public Login required Internet-facing/cloud deployment

Reachability Model

Bind Meaning Typical use
loopback Listen on localhost only default local usage, reverse-proxy deployments
lan Listen on all interfaces (0.0.0.0) LAN/VPN/private-network access
tailnet Listen on a detected Tailscale IP Tailscale-only access
custom Listen on an explicit host/IP advanced interface-specific setups

3. Security Policy

local_trusted

  • loopback-only host binding
  • no human login flow
  • optimized for fastest local startup

authenticated + private

  • login required
  • low-friction URL handling (auto base URL mode)
  • private-host trust policy required
  • bind can be loopback, lan, tailnet, or custom

authenticated + public

  • login required
  • explicit public URL required
  • stricter deployment checks and failures in doctor
  • recommended bind is loopback behind a reverse proxy; direct lan/custom is advanced

4. Onboarding UX Contract

Default onboarding remains interactive and flagless:

pnpm paperclipai onboard

Server prompt behavior:

  1. quickstart --yes defaults to server.bind=loopback and therefore local_trusted/private
  2. advanced server setup asks reachability first:
  • Trusted local → bind=loopback, local_trusted/private
  • Private network → bind=lan, authenticated/private
  • Tailnet → bind=tailnet, authenticated/private
  • Custom → manual mode/exposure/host entry
  1. raw host entry is only required for the Custom path
  2. explicit public URL is only required for authenticated + public

Examples:

pnpm paperclipai onboard --yes
pnpm paperclipai onboard --yes --bind lan
pnpm paperclipai run --bind tailnet

configure --section server follows the same interactive behavior.

5. Doctor UX Contract

Default doctor remains flagless:

pnpm paperclipai doctor

Doctor reads configured mode/exposure and applies mode-aware checks. Optional override flags are secondary.

6. Board/User Integration Contract

Board identity must be represented by a real DB user principal for user-based features to work consistently.

Required integration points:

  • real user row in authUsers for Board identity
  • instance_user_roles entry for Board admin authority
  • company_memberships integration for user-level task assignment and access

This is required because user assignment paths validate active membership for assigneeUserId.

7. Local Trusted -> Authenticated Claim Flow

When running authenticated mode, if the only instance admin is local-board, Paperclip emits a startup warning with a one-time high-entropy claim URL.

  • URL format: /board-claim/<token>?code=<code>
  • intended use: signed-in human claims board ownership
  • claim action:
    • promotes current signed-in user to instance_admin
    • demotes local-board admin role
    • ensures active owner membership for the claiming user across existing companies

This prevents lockout when a user migrates from long-running local trusted usage to authenticated mode.

8. Current Code Reality (As Of 2026-02-23)

  • runtime values are local_trusted | authenticated
  • authenticated uses Better Auth sessions and bootstrap invite flow
  • local_trusted ensures a real local Board user principal in authUsers with instance_user_roles admin access
  • company creation ensures creator membership in company_memberships so user assignment/access flows remain consistent

9. Naming and Compatibility Policy

  • canonical naming is local_trusted and authenticated with private/public exposure
  • no long-term compatibility alias layer for discarded naming variants

10. Relationship to Other Docs

  • implementation plan: doc/plans/deployment-auth-mode-consolidation.md
  • V1 contract: doc/SPEC-implementation.md
  • operator workflows: doc/DEVELOPING.md and doc/CLI.md
  • invite/join state map: doc/spec/invite-flow.md
Reference in New Issue View Git Blame Copy Permalink