Files
DottaandPaperclip 45862dd210 docs: add a product feature map (#15288)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Its user journeys span tasks, agents, projects, connected apps,
governance, and CLI operations.
> - Existing tests do not provide a shared index of entry points and
verification steps.
> - Contributors need to see which surfaces a change affects and what
evidence exists.
> - This pull request adds an optional product feature map with recipes
and explicit coverage gaps.
> - The map adds no CI checks or required maintenance for future pull
requests.
> - Contributors can use it to find verification steps and state what
they checked.

## Linked Issues or Issue Description

**Issue type**

Missing documentation.

**Where is the issue?**

User-journey verification guidance in AGENTS.md and doc/DEVELOPING.md.

**What's wrong?**

There is no shared index of product features, user entry points,
available test evidence, and remaining coverage gaps. Shared components
can hide differences between their hosts.

**Suggested fix**

Add a documentation-only capability index and verification recipes. The
format takes inspiration from [Omnigent's feature
map](https://github.com/omnigent-ai/omnigent/tree/91acfbbb59f6fc210ff95a9e9428aadd62e06582/feature-map).
The recipes describe Paperclip's own behavior and tests.

Searched GitHub PRs and issues for `feature map` and `feature-map`. No
duplicate change was found. Checked ROADMAP.md. This PR documents
existing capabilities.

## What Changed

- Added 35 feature recipes, 171 named sub-features, and 91 entry points
across product, CLI, operator, and developer surfaces.
- Each recipe describes setup, expected results, existing automated
evidence, manual verification, and coverage gaps.
- Added a dated source snapshot of 185 non-test page TSX modules in 15
areas. The snapshot describes documentation coverage, not runtime
health.
- Included entry points within existing pages, CLI/API operations, and
experimental surfaces. Identified helper-only test evidence where a
rendered journey has no automated proof.
- Linked the map from AGENTS.md and doc/DEVELOPING.md as an optional
reference.
- The final diff contains only Markdown and the inventory JSON. It adds
no checker, tests, package commands, workflows, dependencies, scheduled
work, or mandatory inventory updates.

## Verification

- PASS: local documentation links resolve and the inventory JSON parses.
Confirmed the final PR diff contains only 39 documentation files.
- PASS: `node --test '.github/scripts/tests/*.test.mjs'` — 381 existing
tests after removal of the feature-map tests.
- PASS: `git diff --check`.
- Earlier local build and typecheck passed. The full local test run was
stopped after 26 minutes with failures in unchanged chat-channel and
native-runner integration tests. It did not complete. These application
checks were not repeated for the documentation-only removal.
- [CI on the preceding
head](https://github.com/paperclipai/paperclip/actions/runs/37398407523)
passed all applicable checks. Checks on the final documentation-only
head are pending.
- PASS: Greptile review on final head
`45c4b0aeb26540324825da43e81bee2336ad1c1f` is 5/5. There are no
unresolved findings.
- Live product/provider journeys were not run to author the map. The
recipes identify available evidence and manual steps, not new
qualification results.

## Risks

Low product risk: the PR changes documentation only. Recipes and the
source snapshot can become stale. Maintenance is optional and based on
review. Linked tests do not prove that every documented journey works.
The map states remaining coverage gaps.

## Model Used

OpenAI Codex, GPT-6 family, with repository inspection, reasoning, tool
use, and code execution. The exact serving model ID and context window
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
#` / `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
- [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-06 02:08:47 +00:00

2.9 KiB
Raw Permalink Blame History

Login, invitations, and access

People and agents enter the correct instance and company with the permissions granted to their identity. Login, membership, resource access, and CLI authorization have separate controls.

Implementation: auth page, company members, invitation.

Sub-features

  • login: sign in or claim the board in the configured deployment mode.
  • invitations: join through a valid invite and handle expired or already-used links.
  • membership: review join requests and manage company/instance membership and permissions.
  • resources: respect company and resource boundaries on deep links and mutations.
  • cli-auth: authorize a CLI session and revoke or replace credentials.

How to get to it (user POV)

login

Open /auth; first-owner bootstrap uses /board-claim/:token when configured.

invite-members

Open /invite/:token; operators manage members in company settings and join requests at /inbox/requests.

cli-authorization

Start the CLI auth/connect flow and approve its /cli-auth/:id browser page; instance access is under Settings when visible.

Driving it

Preconditions: follow the baseline. For login tests use authenticated mode and two test users; local-trusted mode does not prove session enforcement. Use two companies for isolation checks.

login

Automated: auth UI and session routes cover their respective layers.

Manual: Sign in, reload a company deep link, sign out, and revisit it. Confirm the browser requests authentication rather than showing cached company data. Test an invalid claim separately on disposable state.

invite-members

Automated: member UI and invite replay provide component and route evidence.

Manual: Accept an invite as the intended user, inspect the resulting company and permissions, then reuse and expire disposable invites. Change a member permission, reload as that member, and verify a denied operation on another company remains denied.

cli-authorization

Automated: board auth client and token commands cover the client contracts.

Manual: Authorize the intended CLI context, make a read-only company request, then revoke its token and retry. Verify failure is explicit and does not silently fall back to another identity.

Gotchas

  • Settings visibility is not authorization; direct requests still need permission checks.
  • An agent bearer key must not gain another company’s access.
  • Never put invite tokens, session cookies, or API keys in verification evidence.