2 Commits

Include renames

Author	SHA1	Message	Date
DottaandPaperclip	72c42fad99	[codex] Add optional Ramp skill (#9157) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Skills are how operators give agents reusable, reviewable operating instructions without baking every integration into core runtime code. > - Finance setup is a sensitive workflow because account onboarding, incorporation, cards, spend controls, and data sharing can all create real-world effects. > - Ramp publishes an agent-facing setup skill and playbooks, but Paperclip needs a curated wrapper that makes those instructions subordinate to Paperclip governance. > - This pull request adds an optional Ramp catalog skill that fetches Ramp's live entrypoint while preserving Paperclip approval gates. > - The benefit is that companies can opt into Ramp setup assistance while reviewers can see the source model, allowed hosts, and fail-closed safety rules in one shipped catalog entry. ## Linked Issues or Issue Description No public GitHub issue exists for this optional catalog skill. Feature request context: - **Problem / motivation:** Paperclip companies need a safe, installable way for agents to follow Ramp's public agent setup flow without giving those fetched instructions authority over financial, legal, credential, or spend decisions. - **Proposed solution:** Ship a markdown-only optional `paperclipai:optional:finance:ramp` skill that points agents at Ramp's live get-started skill, documents the thin-wrapper source model, allowlists the Ramp host, and requires Paperclip approval for financial, incorporation, credential, connector, third-party tool, and money-movement actions. - **Alternatives considered:** Vendoring a snapshot would reduce runtime source drift but would stale quickly as Ramp updates its own onboarding flow. The wrapper instead fetches fresh instructions while explicitly failing closed on unclear provenance and keeping fetched instructions subordinate to Paperclip instructions. - **Roadmap alignment:** This fits the completed Skills Manager roadmap area by adding a focused optional catalog skill rather than expanding core workflow code. ## What Changed - Added a markdown-only optional Ramp skill under the finance catalog. - Documented the source model for live Ramp instructions, the allowed host, provenance handling, community/unclear playbook approval requirements, and safety rules. - Added mandatory Paperclip approval gates for Ramp account setup, incorporation/legal filings, CLI installers, connector/auth flows, third-party browser/MCP/CLI tooling, financial data sharing, Agent Cards, spend controls, and money movement. - Updated the Skills Store guide to document thin fetch-and-follow wrappers for curated optional skills. - Regenerated the shipped skills catalog manifest. - Added catalog tests for the Ramp entry, approval-gate wording, mixed-provenance handling, and avoiding remote-fetch execution hard-stop patterns. ## Verification - `pnpm --filter @paperclipai/skills-catalog build:manifest` - `pnpm --filter @paperclipai/skills-catalog validate` - `pnpm --filter @paperclipai/skills-catalog test -- src/shipped-catalog.test.ts` — 1 file, 8 tests passed. - `git diff --check` ## Risks - Ramp-hosted instructions can change after install. The wrapper mitigates this by keeping fetched content subordinate to Paperclip instructions, limiting the source host, failing closed on unclear provenance, and requiring scoped approvals before governed actions. - The skill is markdown-only and optional, so it does not add executable package code or install by default. - The generated catalog manifest changes hashes for the shipped catalog entry; catalog validation passed after regeneration. ## Model Used OpenAI Codex, GPT-5-based coding agent, with repository file access, shell execution, GitHub CLI/tooling, and medium-reasoning mode. ## 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 - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-07-07 08:33:46 -05:00
3 people	a71c4b6782	[codex] feat(watchdog): add task watchdog control plane (#8339) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The task lifecycle and recovery subsystems decide when agent work is still productive, stalled, or ready for review. > - Existing recovery paths can observe stopped or incomplete work, but there was no first-class per-task watchdog model with scoped review permissions. > - Watchdog follow-ups also need strict boundaries so recovery/status-only runs cannot mutate approvals or perform deliverable work. > - This pull request adds the task watchdog data model, API/service layer, scheduler/review flow, adapter wake context, UI configuration surfaces, and docs. > - The branch has been rebased onto current `paperclipai/paperclip` `master`; the watchdog migration is now ordered after master's latest migrations as `0104_issue_watchdogs`. > - The benefit is a more explicit task-review loop that preserves Paperclip's single-assignee and governance invariants while making stalled work easier to route. ## Linked Issues or Issue Description No linked GitHub issue. Paperclip task: [PAP-11275](/PAP/issues/PAP-11275). ## Problem or motivation Task recovery needs a first-class watchdog path that can inspect stopped work and create scoped follow-ups without bypassing normal task ownership. Board/UI users need a way to configure watchdogs on tasks and see watchdog-related live work. Recovery/status-only runs must remain limited to status reporting and must not create approvals, link approvals, or submit approval comments. ## Proposed solution Add a task-watchdog data model, scheduler/classifier, scoped mutation guard, adapter wake context, API/UI configuration surfaces, and documentation so watchdog agents can review stopped task subtrees under explicit boundaries. ## Alternatives considered Reuse the existing recovery-action flow only. That would keep stopped-work detection implicit, make per-task watchdog assignment harder to expose in the UI, and would not provide a durable scoped-review issue for stalled task trees. ## Roadmap alignment This is Paperclip control-plane lifecycle infrastructure for task execution and recovery. I checked `ROADMAP.md`; this PR does not duplicate an existing planned core item. ## What Changed - Added issue watchdog schema, migration, shared contracts, validators, CRUD API, and service support. - Added task watchdog scheduler/classifier behavior, scoped mutation enforcement, adapter wake context, and default watchdog mandate guidance. - Added UI surfaces for configuring watchdogs on new/existing tasks, viewing watchdog activity, and exposing the experimental setting. - Added docs for the user-facing task watchdog workflow and implementation semantics. - Gated new-task watchdog setup behind `enableTaskWatchdogs` and blocked cheap status-only recovery runs from approval mutations. - Rebased onto current `master` and renumbered the idempotent watchdog migration from the branch-local `0102_issue_watchdogs` slot to `0104_issue_watchdogs`. - Addressed Greptile feedback by loading watchdog classifier input with a recursive subtree query and centralizing the watchdog origin-kind constant. - Added and updated focused server/UI tests for watchdog routes, scheduler/classifier behavior, scope boundaries, live task visibility, settings, and new issue dialog behavior. ## Verification - `pnpm vitest run server/src/__tests__/task-watchdogs-scheduler.test.ts server/src/__tests__/task-watchdogs-classifier.test.ts` - `pnpm vitest run server/src/__tests__/approval-routes-idempotency.test.ts server/src/__tests__/issue-agent-mutation-ownership-routes.test.ts` - `pnpm vitest run ui/src/components/NewIssueDialog.test.tsx` - `pnpm --filter @paperclipai/server typecheck` - `git diff --check` - Verified the PR diff does not include `pnpm-lock.yaml` or `.github/workflows`. ## Risks - Medium risk: this introduces a new task lifecycle surface touching DB schema, server routes/services, adapter wake context, and UI task configuration. - Watchdog scheduling behavior depends on the new experimental setting and runtime context checks behaving consistently across local and production agents. - The watchdog migration is idempotent (`IF NOT EXISTS` / duplicate-object guards) so users who tried the previous branch-local migration number should not get duplicate-object failures. - CI and the second Greptile pass are pending after the latest review-fix push. > 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, GPT-5-class coding agent in the Paperclip workspace. Exact runtime model id and context window were not exposed to the agent; tool use and local command execution were 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] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots — N/A per Paperclip task instruction: do not add screenshots/images to this PR unless they are specifically part of the work. - [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 --------- Co-authored-by: Paperclip <noreply@paperclip.ing> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-19 15:38:52 -05:00