DottaandPaperclip
47027e7ba5
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Routines save work for later execution under a responsible person's authority. > - An agent can create a routine through its normal REST or native API tools. > - The create route kept the agent creator but dropped the authenticated responsible user. > - The service then selected a parent task's user or a company default, even when the source run had a different user. > - This pull request passes the authenticated responsible user separately from creator attribution. > - Future automatic runs then use the authenticated responsible user saved in the routine revision. ## Linked Issues or Issue Description **What happened?** An authenticated native agent created a routine without a parent task. The stored responsible user became a different company owner. An unrelated parent task could also replace the authenticated user. The defect changes the identity saved for future automatic work. **Expected behavior** Creation must use the server-resolved responsible user from the authenticated run or API key. The agent remains the creator. A person who clicks Run now still supplies that manual run's identity. **Steps to reproduce** 1. Create an active company member and a different company owner. 2. Initialize a native agent run with the member's identity. 3. Use `call_api` to create a paused, self-assigned routine without a parent. 4. Read the routine and its first revision. Before this fix, both use the company owner. **Paperclip version or commit** Reproduced on master `56517dda6c5b32bc901b7dbf1605eaaa041c5fba`. **Deployment mode** Local source integration with real HTTP routes, agent authentication, native tool authority, and embedded PostgreSQL. No provider turn is needed for the reproduction. Related work: [#19128](https://github.com/paperclipai/paperclip/pull/19128) adds board controls for saved responsibility. [#15207](https://github.com/paperclipai/paperclip/pull/15207) repairs synthetic identities from built-in installers. Neither fixes this authenticated create path. ## What Changed - Pass the authenticated agent's responsible user as a separate internal actor field. - Select the board user first, then the agent’s server-resolved responsible user, before the existing parent and company fallback. - Keep creator attribution, initial revision attribution, manual dispatch identity, and existing records intact. - Add real native API, HTTP, and PostgreSQL regressions for identity selection, replay, client spoofing, stale claims, revoked membership, cancellation, cross-company calls, API keys, and fallback behavior. - Document the creation and manual dispatch identity rules in the execution contract. Correct the obsolete responsibility sentence in the agent access map. - Make the existing live-retry route fixture wait for its committed comment’s durable wake before draining. Keep all process and saved-owner assertions. ## Verification - Captured a failing native `call_api` test before changing production code. The persisted responsible user was the unrelated company owner. - The same real route and database boundary passes after the fix. - Initial affected routine and identity checks: 131 passed. The existing pending-AI-card fence also passed. - Follow-up routine checks: 118 passed. The owning scheduled-retry suite passed all 31 tests. - Initial CI serialized shard 7/9 failed with a `23503` wake-to-agent foreign key error during test cleanup. A controlled real-route/PostgreSQL pause reproduced that exact error on unchanged base `56517dda6c`. The drain returned before the route registered its deferred comment wake. The same pause passed after the fixture waited for the actual commentId’s durable wake receipt. The original failure is preserved. - Affected server typecheck after the fixture query change: passed. - `pnpm -r typecheck`: passed. - `pnpm build`: passed. - `pnpm test:run`: still running as supporting coverage. The worktree changed during the run: map cleanup, then the six-line fixture wait. Production and routine-test files stayed unchanged. This is mixed-working-tree coverage, not an immutable full-suite pass for a commit. Exact next-head CI remains required. - `node scripts/check-maps.mjs` and `git diff --check`: passed. - Exact head `a12e3f6c42b8ad5826fd58faa3cd9553ea251e09`: all CI gates passed. Greptile and the native substantive review both gave 5/5 with no open findings. The native reviewer did not run tests or exercise shadow-mode authorization. - Live provider execution remains unverified. This change does not grant access to another person's AI account. ## Risks New agent-created routines now use their authenticated responsible user before a parent or company default. This is the intended behavior change. The service keeps its fallback when no bound identity exists. Missing agent-key identity still fails authentication. Missing personal AI configuration still blocks execution. Existing routines, revisions, tasks, grants, and manual dispatch behavior do not change. The fixture waits for a persisted wake record before draining; its original live-process and saved-owner assertions remain. ## Model Used OpenAI `gpt-6.1-sol` with reasoning, tool use, and code execution. The host did not expose the context window size. ## 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>
7.1 KiB
Routines, schedules, and triggers — agent access
Product map: Routines, schedules, and triggers.
Feature ID: routines.
Review date: 2026-10-12. Source commit: 58e16dbddfc9c8d0cf60867f9d9847f0feda055b.
Native REST transport reconciled in this change; see the
shared transport contract.
This is a source-reviewed baseline of representative operations and known gaps. Each capability needs operation-level review before its entire scope can be qualified. No live agent execution is claimed. Follow the map contract for format, permission checks, evidence and maintenance.
definition
Capability ID: routines/definition.
Review: baseline.
API: present — representative operation IDs:
POST /api/companies/{companyId}/routines.PATCH /api/routines/{id}.
Agent access: available — Agent REST / native call_api / CLI routine create/update;
optional installed MCP generic request.
Policy: Agents may read company routines but only create/manage routines assigned to themselves; trigger secrets need secure handling.
Evidence: source-only — implementation at
the reviewed commit above.
Verification: not-run — exercise a listed permitted operation with actual agent
credentials/run context; inspect its result and applicable persistence/attribution.
Assert the relevant denied actor, owner, company or mode from Policy. Review the
remaining operations before qualifying the whole capability.
Gaps: No dedicated production manage_routine binding; generic call_api provides
the permitted REST path. Creation resolves responsibility from the authenticated
agent's on-behalf-of user, then the parent issue or company default.
triggers
Capability ID: routines/triggers.
Review: baseline.
API: present — representative operation IDs:
POST /api/routines/{id}/triggers.PATCH /api/routine-triggers/{id}.
Agent access: available — Owned-routine agent REST / native call_api / CLI trigger
commands.
Policy: Agents may read company routines but only create/manage routines assigned to themselves; trigger secrets need secure handling.
Evidence: source-only — implementation at
the reviewed commit above.
Verification: not-run — exercise a listed permitted operation with actual agent
credentials/run context; inspect its result and applicable persistence/attribution.
Assert the relevant denied actor, owner, company or mode from Policy. Review the
remaining operations before qualifying the whole capability.
Gaps: No dedicated production trigger-management binding; generic call_api
provides the permitted REST path. Credential replies use inline delivery and encrypted
mutation receipts rather than shared response assets.
Sentry alerts use the ordinary POST /api/routine-triggers/public/{publicId}/fire
endpoint and its trigger authentication. Configure filtering and loop prevention
in Sentry; see the Sentry repair tutorial.
The host-only GET /api/instance/task-drain?idleSleepSafety=1&scheduledWake=1
extension reports the earliest supported future routine deadline under an owned
idle hold. It requires signed Cloud control authority; company agents and tenant
admin tokens cannot use it. It does not grant routine management or execution
authority. See the hosting protocol
and route authorization tests.
The signed scheduledWake=domain-deadlines-v1 catalog can combine this routine
obligation with other supported domain deadlines. Its generation receipt is
mandatory even when no future alarm remains. See domain scope.
These are local contract checks, not a live provider sleep/wake qualification.
run-now
Capability ID: routines/run-now.
Review: baseline.
API: present — representative operation IDs:
POST /api/routines/{id}/run.
Agent access: partial — Owned-routine agent REST / CLI run; native call_api from
an authorized active run.
Policy: Agents may read company routines but only create/manage routines assigned to themselves; trigger secrets need secure handling.
Evidence: source-only — implementation at
the reviewed commit above.
Verification: not-run — exercise a listed permitted operation with actual agent
credentials/run context; inspect its result and applicable persistence/attribution.
Assert the relevant denied actor, owner, company or mode from Policy. Review the
remaining operations before qualifying the whole capability.
Gaps: Scheduled/waiting native agents cannot independently call this operation: native authority requires a running bound run. A separate control binding remains absent.
history
Capability ID: routines/history.
Review: baseline.
API: present — representative operation IDs:
GET /api/routines/{id}/runs.GET /api/routines/{id}/revisions.
Agent access: available — REST / native call_api / CLI routine.
Policy: Agents may read company routines but only create/manage routines assigned to themselves; trigger secrets need secure handling.
Evidence: source-only — implementation at
the reviewed commit above.
Verification: not-run — exercise a listed permitted operation with actual agent
credentials/run context; inspect its result and applicable persistence/attribution.
Assert the relevant denied actor, owner, company or mode from Policy. Review the
remaining operations before qualifying the whole capability.
Gaps: Runs are readable in company scope; configuration revision access checks routine ownership for agents.
management
Capability ID: routines/management.
Review: baseline.
API: present — representative operation IDs:
PATCH /api/routines/{id}.
Agent access: available — Owned-routine agent REST / native call_api / CLI.
Policy: Agents may read company routines but only create/manage routines assigned to themselves; trigger secrets need secure handling.
Evidence: source-only — implementation at
the reviewed commit above.
Verification: not-run — exercise a listed permitted operation with actual agent
credentials/run context; inspect its result and applicable persistence/attribution.
Assert the relevant denied actor, owner, company or mode from Policy. Review the
remaining operations before qualifying the whole capability.
Gaps: Pause/archive mutations have a generic native REST path under routine ownership rules. Plugin-managed routine rules remain separate.
Execution resolves referenced project skills against agent/responsible-user access, then saves immutable version selections in the heartbeat execution context. New runs resolve latest installed content; resumed runs retain selections and recheck access. An unavailable explicit reference produces an actionable configuration error. Live agent execution across an upstream update remains required acceptance evidence.