mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-17 10:06:42 +02:00
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Contributors use the feature map to understand and verify product capabilities. > - Agents need APIs and usable entry points within their permission boundaries. > - Product recipes and agent access need separate records with shared capability IDs. > - This pull request establishes that contract and gives maintenance ownership of both maps. > - The benefit is repeatable access review without changing product behavior or permissions. ## Linked Issues or Issue Description Refs: #15983, which added the portable verification skills and updated the feature map. This is its contract-only follow-up. Related: #15288 added the original feature map. **Issue type** Missing documentation and maintenance contract. **Where is the issue?** The product map, its missing agent access companions, and the verification skills. **What's wrong?** There is no shared convention for API presence, agent entry points, permission boundaries, access gaps, or evidence. An API declaration does not prove that a permitted native or remote agent can use it. **Suggested fix** Keep the product and agent access maps as siblings under `maps/`. Reuse capability IDs. Record representative source inventory separately from operation review and live proof. Keep both maps aligned through the maintenance skill. ## What Changed - Move the existing product map to `maps/feature-map/`. Preserve its recipes and Poteto format. Update relative links and add companion links. - Add `maps/agent-access-map/` with 35 area files and 171 matching capability IDs. Seed representative API operations, agent paths, policies and known gaps from the reviewed source inventory. Mark entries as `baseline`, `source-only`, and live verification `not-run`. - Define the shared contract in `maps/README.md`. Track API presence, agent availability, policy, evidence and review depth separately. Require operation enumeration before marking a broad capability operation-reviewed. - Extend `maintain-verification-skill` to reconcile both maps and inspect actual route policy and production tool admission. Update creation, verification, notices and contributor references to use the shared contract. - Add `scripts/check-maps.mjs` and ten regression tests. Check matching areas/IDs, indexes, references, contract fields, API method/path examples, justified exceptions and evidence-state consistency. - Keep the coverage inventory unchanged. Preserve skill invocation policies and both MIT license blocks. No product API, permission, UI, runtime helper, migration, dependency or workflow changes. ## Verification - Passed: `node scripts/check-maps.mjs` reports 35 paired areas and 171 matching capability IDs. All local map references resolve. - Passed: `node --test scripts/check-maps.test.mjs` runs ten tests. Fixtures cover missing companions, renamed/orphan/duplicate IDs, broken references, missing operation fields, empty exceptions, missing API examples, empty policy fields, and verified evidence without passed verification. - Passed: metadata validation for all three verification skills. Skill and contributor links resolve. Invocation policies and both license blocks are unchanged. - Compared relocated recipes with current master. Contents differ only in relative links and companion links. `coverage.json` is byte-for-byte unchanged. Master's updated read-only interaction test reference is retained. - Passed: `git diff --check`. The branch starts from current master and contains only this contract change. - Repository-wide typecheck, tests and build were not run locally for this documentation and Node structural-check scope. Live agent access was not exercised. Those gaps are explicit in the baseline entries; the structural check does not certify behavior. CI and automated review are pending. ## Risks - The companions are representative source baselines. They are not complete operation inventories or passed agent journeys. - The checker cannot establish actual permissions, native tool admission, operation completeness or truthful live evidence. Maintenance must inspect source and verify with the actual permitted agent context. - External links to the old product-map directory may need updates. Repository references have been updated. - Existing access gaps and board/user restrictions remain recorded. This contract does not change authority or implement missing paths. ## Model Used OpenAI GPT-6 through Codex assisted with this change. The session does not expose the exact serving model ID, configured context-window size, or reasoning setting. Capabilities used: source analysis, file edits, shell commands, and structural regression tests. ## 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 Co-authored-by: Paperclip <noreply@paperclip.ing>
157 lines
8.1 KiB
Markdown
157 lines
8.1 KiB
Markdown
# Connection setup
|
|
|
|
People connect an app or account, choose who may use it, and recover incomplete
|
|
setup from either Apps or a task that needs access. A saved draft, a completed
|
|
provider login, a usable connection, and a resumed task are separate checkpoints.
|
|
Chat channels additionally require an endpoint and linked sender identity.
|
|
|
|
Agent access: [companion](../agent-access-map/connection-setup.md).
|
|
|
|
## Sub-features
|
|
|
|
- `catalog`: find a provider, inspect its available methods, and open setup;
|
|
unavailable methods explain their prerequisite rather than silently switching.
|
|
- `identity-and-access`: select personal/shared identity and eligible agents;
|
|
an empty explicit selection and company-wide access must not be confused.
|
|
- `credentials`: provider sign-in, key, or generic MCP URL follows its supported
|
|
setup method; credentials are not retained in browser draft storage.
|
|
- `handoff`: provider popup/full-page callback returns to the correct setup
|
|
host with the original task intent and identity choice intact.
|
|
- `draft-recovery`: cancel, Back, Save & exit, reload, Finish setup, and reconnect
|
|
preserve the exact draft rather than creating duplicate connections.
|
|
- `task-request`: only the addressed person resolves the requested connection;
|
|
usable access releases the pending task request through normal continuation.
|
|
- `channel-setup`: provider endpoint, represented agent, linked sender, and
|
|
communication instructions are configured before an external message is used.
|
|
- `failure`: denied login, unreachable/private URL, expired credentials, and
|
|
permission errors leave an actionable state rather than a false success.
|
|
|
|
## How to get to it (user POV)
|
|
|
|
### `apps-catalog`
|
|
|
|
Open Apps (`/apps`), choose an app, and connect from its landing page. Select an
|
|
available method and access, then complete setup. Existing connections open
|
|
their details; unfinished ones offer a way to finish setup.
|
|
|
|
### `mcp-link`
|
|
|
|
Use **Connect with a link** or `/apps/byo` for a generic MCP server. Paste its
|
|
URL, select access, and follow the probe's sign-in/key guidance. Provider-specific
|
|
catalog setup and a generic endpoint may use different flows.
|
|
|
|
### `task-request`
|
|
|
|
Open the task's pending connection request and its setup action as the named
|
|
user. Setup can open in a task dialog and may use an OAuth popup. Follow the
|
|
request's original link if setup falls back to a standalone page.
|
|
|
|
### `resume-connection`
|
|
|
|
From Apps or connection details, use Finish setup, reconnect, or the offered
|
|
authentication recovery action. Reload or return from the provider before
|
|
checking whether the same saved connection became usable.
|
|
|
|
### `chat-channel`
|
|
|
|
With chat connectors enabled, select a supported chat/email provider in Apps
|
|
or open `/apps/chat/connect`. Complete that provider's endpoint setup, then
|
|
open its settings (`/apps/chat/:endpointId/settings`). Follow identity linking
|
|
as the intended sender before messaging the agent externally.
|
|
|
|
## Driving it with Playwright and the Paperclip CLI
|
|
|
|
Preconditions: follow the [baseline](./README.md#before-driving-a-journey).
|
|
Choose a disposable provider account/resource and record its auth method,
|
|
deployment mode, account ownership, and access selection. For live setup, use
|
|
the provider's documented prerequisites in the
|
|
[connector playbook](../../doc/connections/CONNECTOR-PLAYBOOK.md). Automated fixtures
|
|
do not establish OAuth registration, public callbacks, or production provider access.
|
|
|
|
### `apps-catalog`
|
|
|
|
Automated: [Browse](../../ui/src/pages/apps/Browse.test.tsx),
|
|
[unconnected app](../../ui/src/pages/apps/AppNotConnected.test.tsx), and
|
|
[AppsConnect](../../ui/src/pages/apps/AppsConnect.test.tsx) cover catalog entry,
|
|
access selection, provider-specific method choices, and setup failures with
|
|
mocked APIs. [Connection intents](../../tests/e2e/connection-intents.spec.ts)
|
|
drives store and task setup against one fake provider through a useful continuation:
|
|
|
|
```sh
|
|
pnpm exec vitest run ui/src/pages/apps/Browse.test.tsx ui/src/pages/apps/AppsConnect.test.tsx
|
|
pnpm exec playwright test -c tests/e2e/playwright.config.ts tests/e2e/connection-intents.spec.ts
|
|
```
|
|
|
|
Manual: connect from an unconnected provider landing. Select the intended
|
|
identity and agent access, complete authentication, reload, and inspect the
|
|
saved connection. Run a permitted read-only action with an eligible agent and
|
|
verify its useful result. Try an ineligible agent and confirm denial. Repeat
|
|
with a user who cannot install company-wide; the UI must not imply broad access.
|
|
|
|
### `mcp-link`
|
|
|
|
Automated: AppsConnect's generic MCP cases cover probe-driven auth, private or
|
|
unreachable endpoints, preregistered clients, secret-backed headers, and unsafe
|
|
authorization URLs. These are component/API mocks, not remote provider proof.
|
|
|
|
Manual: connect a known test MCP URL through the link flow, verify its saved
|
|
endpoint and a read-only action, then repeat with a bad URL and wrong credential.
|
|
The error should explain the next action and preserve non-secret setup context.
|
|
Test no-auth and authenticated endpoints separately; never infer one from the other.
|
|
|
|
### `task-request`
|
|
|
|
Automated: [interaction card](../../ui/src/components/IssueThreadInteractionCard.test.tsx)
|
|
checks addressed-user controls. AppsConnect tests cover page/dialog parity,
|
|
task-bound OAuth, popup handoff, and verifying a saved connection before closing.
|
|
The connection-intents browser suite above exercises fixture-backed continuation.
|
|
|
|
Manual: ask an agent to use an unavailable app, open its request as the named
|
|
user, and complete setup in the dialog. Verify the card settles, the exact task
|
|
resumes, and the agent returns a useful provider result. Repeat the page-host
|
|
fallback and denied OAuth path. As another user, confirm that merely seeing the
|
|
task does not grant the right to resolve the request.
|
|
|
|
### `resume-connection`
|
|
|
|
Automated: AppsConnect tests cover exact-draft resume, declined OAuth, reconnect
|
|
lookup failure/retry, response-lost creation, archived connection revival, and
|
|
saved account reuse. [App detail](../../ui/src/pages/apps/AppDetail.test.tsx) covers
|
|
the connection host. These tests do not complete a real provider login.
|
|
|
|
Manual: leave setup through its footer, reload Apps, choose Finish setup, and
|
|
confirm the same connection is resumed. Decline provider login and recover from
|
|
that checkpoint. Reconnect an expired disposable account and verify a permitted
|
|
action afterwards. Count connections before/after to catch accidental duplicates.
|
|
|
|
### `chat-channel`
|
|
|
|
Automated: [setup routing](../../ui/src/pages/apps/chat/ChatEndpointSetup.routing.test.tsx),
|
|
[saved setup state](../../ui/src/pages/apps/chat/ChatEndpointSetup.state.test.ts),
|
|
[email setup](../../ui/src/pages/apps/chat/EmailEndpointSetup.test.tsx), and
|
|
[identity confirmation](../../ui/src/pages/apps/chat/ChatIdentityConfirm.test.tsx)
|
|
cover shared UI logic with fixtures. Provider-specific live setup is not implied.
|
|
|
|
Manual: complete setup for one named provider, reload endpoint settings, link
|
|
the intended sender, and send a disposable message. Verify one task and a useful
|
|
reply in the originating conversation. Inspect an unlinked sender's denial and
|
|
the endpoint's pause behavior. Repeat independently for each provider at issue;
|
|
Slack setup does not qualify Discord, Telegram, GitHub, email, or iMessage.
|
|
|
|
## Gotchas
|
|
|
|
- Private endpoint rejection depends on deployment: owned loopback MCP servers
|
|
are supported in local-trusted/private instances. Public authenticated
|
|
deployments apply the private-network restriction.
|
|
|
|
- A successful OAuth callback is not proof of saved connection access or task
|
|
continuation. Verify all three checkpoints.
|
|
- Personal identity, shared account access, and per-agent access are distinct.
|
|
Connecting an account does not waive an Off action or Ask first review.
|
|
- A tool app connection is not a chat endpoint. The same provider can offer both.
|
|
- Old Apps/Connections URLs can redirect to Apps. Use the current navigation and
|
|
record the actual destination rather than documenting an obsolete screen.
|
|
- Full provider matrix, AI-account selection, gateway/profile administration,
|
|
and account revocation lifecycles remain outside this seed recipe.
|
|
- For governed actions after setup, use [questions and approvals](./questions-and-approvals.md).
|