PaperClipAI/maps/feature-map/tasks.md

navigation

navigation
section sectionOrder order Tasks and conversations 20 10

Task creation and lifecycle

People create, assign, organize, discuss, and finish tasks. A task retains its owner, project, priority, history, and outputs as it moves through the work lifecycle.

Feature ID: tasks.

Implementation: new task, task list, task detail.

Agent access: companion.

Sub-features

• create: tasks/create — capture a title/request with the intended agent, project, and attachments.
• organize: tasks/organize — filter, sort, group, and navigate tasks without losing the selected context.
• properties: tasks/properties — change status, priority, assignee, project, and relationships where authorized.
• discussion: tasks/discussion — persist comments, references, and files on the task.
• completion: tasks/completion — distinguish backlog, active work, review, blocked, done, and cancelled outcomes.
• privacy: tasks/privacy — create private tasks, share or revoke access, and inspect parent/project inheritance before changing visibility.

How to get to it (user POV)

new-task

Use New task from the global launcher, task list, or project task view.

task-list

Open /issues or a project’s Issues view; legacy /tasks links redirect.

task-detail

Open /issues/:issueId from a row, mention, or direct link.

task-sharing

Use the privacy control in New task, or open an existing task’s menu and choose Make private, Share…, or Make public where allowed. The share sheet lists direct grants and inherited access from private ancestors or project membership. Inherited rows have no local revoke action; manage that access at its source.

Driving it with Playwright and the Paperclip CLI

Preconditions: follow the baseline. Use a disposable project. Persistence checks can assign work to Me or leave it unassigned; execution checks additionally need an invokable test agent. Record whether a real or simulated harness handles execution.

new-task

Automated: creation dialog is component coverage with mocked requests.

Manual: Create a uniquely named task with an agent and project. Open its resulting link and reload. Confirm text, attachment, assignment, and project persisted, and verify execution started only when the task and agent are eligible.

Creation is request-first: enter Describe a task…, choose the assignee and project, and submit Create task. A standalone title field is not always shown. Use a human/unassigned task to verify persistence without invoking a model.

task-list

Automated: task-list helpers cover search URLs, pagination, deduplication, and presentation constants. The suite does not render the page or exercise filtering, grouping, opening a task, and returning; those interactions still need a running-browser check.

Manual: Seed human-created, agent-created, scheduled routine, human-initiated chat-channel, and creator-less tasks. Confirm automation is hidden by default, show agent-created tasks reveals it, reload preserves the choice, and Clear filters hides it again. Verify list and board search with automation newer than the human results, and expand contextual ancestors/subtasks without promoting unrelated automated roots. Repeat in project task lists. Agent profiles and task-detail subtasks retain complete history.

Manual: Filter by status and assignee, change grouping/sort, open a task, and return. Verify the correct records and selected view survive navigation and reload. Include an empty result and a failed request.

task-detail

Automated: task detail covers component behavior, while issue service covers server contracts.

Automated: paused assignee relevance uses a real disposable server and paused process agent, with no inference, to check both task interfaces. Done and cancelled tasks hide the paused-agent warning; reopening restores it. The agent stays paused and no run starts.

Manual: For a disposable task owned by a legacy agent, have its current run assign the task to a human with status In review. Verify that assignment and status persist, that the current run finishes without issue_reassigned, and that slow workspace restoration does not turn the task Blocked. Try a later edit from the outgoing run and verify rejection. Repeat a board reassignment and confirm that the outgoing run still stops.

Manual: Add a comment and edit authorized properties. Reload and verify history, actor, and values. Complete a disposable task and inspect its deliverable; reopen through an available action and confirm the next execution follows current policy.

Manual: Ask a standard native agent to schedule a future check on its current task. Reload and confirm the persisted monitor. After the agent yields, verify one later wake and a consumed schedule. For malformed-call recovery, use the agent access recipe and verify that schema feedback supports a corrected call before a wait is claimed. For a due monitor held by execution recovery, confirm that the schedule remains and task activity explains the deferral. Repeated checks must not replay the held work. Resolve the hold through its existing recovery action, then verify one wake. Hold native finalization after the provider has stopped, and verify that both scheduled and manual checks retain the due monitor. After settlement, verify one wake. If its timeout passes during workspace recovery, verify settlement followed by the configured expiry recovery, with no ordinary monitor wake or duplicate escalation. For a timer already dispatched before recovery, verify that the saved result settles without changing the task, removing a successor's checkout, or creating another wake. The monitor regression and scheduler regression cover these boundaries with PostgreSQL.

Manual: Add an ordinary Board comment while a task retry is queued or running. Confirm that the same execution keeps working and receives the saved message, without a second executor or an implicit move to Todo. Repeat with a parked retry and verify that fresh instructions can supersede it. Explicit Stop must still cancel active work. The comment route regressions and HTTP/process and interrupted-cancellation tests cover these boundaries locally; deployed runner acceptance remains separate.

task-sharing

Automated: Share sheet, privacy controls, grant routes, and privacy production review cover component actions, persisted grants, inheritance, and actor/resource denials. They do not establish a live two-person browser journey.

Manual: Use authenticated mode with two ordinary operators, an eligible agent, and disposable parent/child/sibling tasks. Create private work as the first person; confirm the second person cannot discover or cold-open it. Share only the child, reload both sessions, and verify child/descendant access without exposing the private parent, sibling, or unreadable project metadata. Inspect direct and inherited rows in Share; inherited rows must identify access managed at its source and offer no local revoke action. Confirm a shared reader cannot manage the task’s grants. Revoke the direct grant as its manager, reload, and retry list and direct reads; change inherited access at its ancestor or project source separately. Inspect blocked Make public actions under a private parent or nonpersonal private project; separately confirm the offered personal-project publish action removes that project binding while private descendants remain private. With an actual granted agent, test the responsible user’s access intersection and the allowed restriction to private; agent access must not permit sharing or publishing.

Sources: Privacy actions, share sheet, issue routes, and authorization.

Gotchas

• Private task sharing and private project membership are distinct read sources. Revoking a direct task grant does not revoke an independent ancestor/project grant; inspect the actual access source.

• Priority remains an API field, but ordinary priority UI editing is hidden.

• A status label alone does not prove that the requested work exists.

• Single-assignee and atomic checkout rules still apply when tasks are created from different hosts.

• Use coordination, steering, and documents for their distinct workflows.

Documentation scope: Tasks, conversations, and attention

Recipes cover the main task/conversation/attention workflows. Full shell, permission, attachment, long-thread, and concurrency permutations remain to be enumerated.