## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Governed MCP access spans contracts, runtime enforcement, adapters, UI surfaces, and operator verification > - The parity reference PR #9534 is too large for effective automated or human review > - The feature therefore needs a linear stack whose individual diffs stay below the 100-file review limit > - This pull request is split 2/8 and focuses on database schema and shared governance contracts > - The benefit is a standalone, testable review boundary while preserving byte-for-byte parity at the top of the stack ## Linked Issues or Issue Description - Related parity reference: #9534 - Problem: The governed access model needs additive persistence and synchronized shared types before server enforcement can compile. - Proposed solution: Adds migrations 0148–0169, tool-access and Smoke Lab schema, shared types/validators/gallery helpers, and the minimal compile-required contract consumers identified by boundary testing. - Alternatives considered: keeping #9534 as one 403-file review, or rewriting the feature to manufacture seams; both were rejected in favor of path extraction plus compile-driven boundary moves. - Roadmap alignment: this advances the existing governed MCP/tool-access work already represented by #9534; it does not introduce a separate roadmap initiative. - Stack position: base branch is `pap10341-split/01-demo-servers`. - Merge policy: merge bottom-up, in order, only after the complete eight-PR stack has been reviewed and the top-of-stack parity gate remains empty. - Requested review: QA for migrations/validators; Greptile on every PR. ## What Changed - Adds migrations 0148–0169, tool-access and Smoke Lab schema, shared types/validators/gallery helpers, and the minimal compile-required contract consumers identified by boundary testing. - Keeps this PR below 100 changed files and independently typecheckable. - Preserves the final tree from #9534 when combined with the other seven stack levels. ## Verification - `pnpm typecheck` — passed, including migration numbering and safety checks - `pnpm --filter @paperclipai/db test` — passed - `pnpm --filter @paperclipai/shared test` — passed ## Risks - Migration or contract mistakes could affect every upper layer; all migrations are additive/idempotent and compile consumers are included in this boundary. - Stack risk: merging out of order can expose incomplete layers; mitigate by following the documented bottom-up merge policy. - Parity risk: later edits to an intermediate branch can drift from #9534; mitigate by re-running the empty top-of-stack diff before merge. > 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, exact model ID `gpt-5.4`; runtime-managed context window; medium reasoning with repository, shell, Git, GitHub CLI, and code-execution tools 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] Internal references are omitted except the execution-plan link explicitly required for this coordinated split stack - [x] My branch name describes the change 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 ## Stack Coordination - Internal execution plan: [PAP-13874](/PAP/issues/PAP-13874#document-plan) - Parity reference: #9534 - Stack: #9556 → #9557 → #9558 → #9559 → #9560 → #9561 → #9562 → #9563 - Merge bottom-up only after full-stack review and an empty parity diff at #9563. --------- Co-authored-by: Paperclip <noreply@paperclip.ing> |
||
|---|---|---|
| .. | ||
| scripts | ||
| src | ||
| README.md | ||
| package.json | ||
| tsconfig.json | ||
README.md
File Browser Example Plugin
Example Paperclip plugin that demonstrates:
- projectSidebarItem — An optional "Files" link under each project in the sidebar that opens the project detail with this plugin’s tab selected. This is controlled by plugin settings and defaults to off.
- detailTab (entityType project) — A project detail tab with a workspace-path selector, a desktop two-column layout (file tree left, editor right), and a mobile one-panel flow with a back button from editor to file tree, including save support.
This is a repo-local example plugin for development. It should not be assumed to ship in a generic production build unless it is explicitly included.
Slots
| Slot | Type | Description |
|---|---|---|
| Files (sidebar) | projectSidebarItem |
Optional link under each project → project detail + tab. |
| Files (tab) | detailTab |
Responsive tree/editor layout with save support. |
Settings
Show Files in Sidebar— toggles the project sidebar link on or off. Defaults to off.Comment File Links— controls whether comment annotations and the comment context-menu action are shown.
Capabilities
ui.sidebar.register— project sidebar itemui.detailTab.register— project detail tabprojects.read— resolve projectproject.workspaces.read— list workspaces and read paths for file access
Worker
- getData
workspaces—ctx.projects.listWorkspaces(projectId, companyId)(ordered, primary first). - getData
fileList—{ projectId, workspaceId, directoryPath? }→ list directory entries for the workspace root or a subdirectory (Nodefs). - getData
fileContent—{ projectId, workspaceId, filePath }→ read file content using workspace-relative paths (Nodefs). - performAction
writeFile—{ projectId, workspaceId, filePath, content }→ write the current editor buffer back to disk.
Local Install (Dev)
From the repo root, build the plugin and install it by local path:
pnpm --filter @paperclipai/plugin-file-browser-example build
pnpm paperclipai plugin install ./packages/plugins/examples/plugin-file-browser-example
To uninstall:
pnpm paperclipai plugin uninstall paperclip-file-browser-example --force
Local development notes:
- Build first. The host resolves the worker from the manifest
entrypoints.worker(e.g../dist/worker.js). Runpnpm buildin the plugin directory before installing so the worker file exists. - Dev-only install path. This local-path install flow assumes this monorepo checkout is present on disk. For deployed installs, publish an npm package instead of depending on
packages/plugins/examples/...existing on the host. - Reinstall after pulling. If you installed a plugin by local path before the server stored
package_path, the plugin may show status error (worker not found). Uninstall and install again so the server persists the path and can activate the plugin. - Optional: use
paperclip-plugin-dev-serverfor UI hot-reload withdevUiUrlin plugin config.
Structure
src/manifest.ts— manifest withprojectSidebarItemanddetailTab(entityTypes["project"]).src/worker.ts— data handlers for workspaces, file list, file content.src/ui/index.tsx—FilesLink(sidebar) andFilesTab(workspace path selector + two-panel file tree/editor).