mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-06 21:05:21 +02:00
DottaandPaperclip
329b229591
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The issue and routine editor surfaces share document annotation behavior for commentable text. > - The annotation layer currently observes document selections inside its container and converts those selections into pending comment anchors. > - Routine editor fields can live inside that same annotated document container while still needing normal native text selection behavior. > - When a user selects text inside an editable routine field, the annotation layer should leave that selection alone instead of preparing a comment. > - This pull request teaches the annotation layer to ignore selections touching editable controls and covers that case with focused component tests. > - The benefit is that routine editing remains editable text UX, while document annotation selection continues to work for normal read-only document text. ## Linked Issues or Issue Description No public GitHub issue exists for this bug. Inline bug report follows. ### Pre-submission checklist - [x] I have searched existing open and closed issues and this is not a duplicate. - [x] I am on current `master` for this PR branch. - [x] I have confirmed the error originates in Paperclip itself, not in an agent adapter, API provider, or local configuration. ### What happened? Selecting text inside an editable routine field could be interpreted as a document annotation selection. That meant the annotation layer could prepare a pending comment anchor or show annotation affordances while the user was just selecting text to edit routine content. ### Expected behavior Editable controls should keep native text selection behavior. Selecting text inside `input`, `textarea`, `select`, or contenteditable routine editor regions should not build a document annotation anchor or show the document annotation toolbar. ### Steps to reproduce 1. Render document annotation behavior around a document/editor container that also contains an editable routine text region. 2. Select text inside the editable region. 3. Observe that the document annotation layer treats the selection as commentable text instead of ignoring it. ### Paperclip version or commit Reproduced and fixed against `master` at `5356b7d73`, with PR head `4f53f83f1`. ### Deployment mode Local dev / component test environment. ### Installation method Built from source. ### Agent adapter(s) involved Not adapter-specific; core UI behavior. ### Database mode Not database-related. ### Access context Board / human operator UI behavior. ### Relevant logs or output No runtime logs. Regression coverage is in `ui/src/components/DocumentAnnotationLayer.test.tsx`. ### Relevant config Not applicable. ### Additional context Root cause: `DocumentAnnotationLayer` filtered selections by container membership, but did not exclude editable controls or all valid contenteditable hosts before building a pending annotation anchor. ### Privacy checklist - [x] I have reviewed all pasted output for PII and redacted where necessary. ## What Changed - Added an editable-selection guard in `DocumentAnnotationLayer` that ignores selections touching `input`, `textarea`, `select`, or contenteditable elements. - Covered both `contenteditable="true"` and bare/empty `contenteditable` hosts so routine editor selections do not build annotation anchors. - Added focused regression tests proving editable selections do not call the annotation anchor helpers or show the annotation toolbar. ## Verification - `pnpm vitest run ui/src/components/DocumentAnnotationLayer.test.tsx` - `git diff --check` - GitHub PR checks are green for head `4f53f83f1`, including policy, review, typecheck/release registry, build, general tests, serialized suites, e2e, canary dry run, security checks, and Greptile. ## Risks Low risk. The change only narrows annotation capture when a selection touches an editable element inside the annotation container. Normal read-only document annotation selections still use the existing anchor-building path. > 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 coding agent based on GPT-5, with shell, Git, Vitest, and GitHub connector/CLI tool use. The exact hosted runtime model identifier is 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 - [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 --------- Co-authored-by: Paperclip <noreply@paperclip.ing>
@paperclipai/ui
Published static assets for the Paperclip board UI.
What gets published
The npm package contains the production build under dist/. It does not ship the UI source tree or workspace-only dependencies.
Storybook
Storybook config, stories, and fixtures live under ui/storybook/.
pnpm --filter @paperclipai/ui storybook
pnpm --filter @paperclipai/ui build-storybook
Typical use
Install the package, then serve or copy the built files from node_modules/@paperclipai/ui/dist.