mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-26 18:31:34 +01:00
docs/external-task-protocol-replacement
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 DottaandClaude Fable 5
|
b996b71a38 |
Deduplicate wake-payload issue descriptions and compact resume deltas (#10216)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Heartbeat wake payloads and the task-context markdown are the two channels that deliver an issue's brief into an agent's prompt > - #10151 fixed wake-prompt-only adapter lanes waking without the issue description by adding it to the structured wake payload > - That left the description delivered twice per prompt on lanes that also inject the task-context markdown, and re-delivered in full on every resume wake, permanently bloating persistent-session context > - This pull request makes the task markdown the single description carrier on lanes that use it, and omits the description from non-assignment resume deltas on all lanes while keeping it for assignment-shaped and recovery wakes > - The benefit is that every lane receives the brief exactly once when it needs it, and long-lived sessions stop re-paying the full brief in tokens on every wake ## Linked Issues or Issue Description Refs #10151 Related prior work: #2883, #8402 (earlier description-delivery attempts referenced by #10151). I searched the PR list for open work on wake-payload description handling and found none besides the merged #10151. **Bug:** After #10151, adapters that inject the `Paperclip task context` markdown (ACPX engine lanes, claude-local CLI, hermes server and gateway) receive the issue description twice in a single prompt — once in the wake prompt's `Issue description:` block and once in the task markdown. Separately, resume deltas re-send the full description (up to 12k characters) on every wake even though the persistent session already received it. **Expected behavior:** The description appears exactly once per prompt on every lane, and resume deltas only carry it when the resuming session may not have seen the brief (assignment-shaped or recovery wakes), leaving an explicit fetch breadcrumb otherwise. **Reproduction:** Wake a claude-local or ACPX agent on an issue with a description and inspect the assembled prompt: the description text appears in both the wake-payload block and the task-context block. Wake the same session again via a comment: the full description is present again in the resume delta. **Affected version:** Current `master` (with #10151 merged). **Deployment mode:** Adapter-backed heartbeat execution, local and sandboxed lanes. ## What Changed - `renderPaperclipWakePrompt` accepts `suppressIssueDescription`; the four task-markdown lanes pass it so the task markdown stays the single, uncapped description carrier there. - Non-assignment resume deltas omit the description and emit `- issue description: omitted from this resume delta; fetch the issue if you need the latest brief`. Assignment-shaped reasons (`issue_assigned`, `issue_reopened_via_comment`, `issue_recovery_action_restored`, `issue_tree_restored`) and recovery wakes still deliver the full brief. - `buildPaperclipTaskMarkdown` gains `includeDescription`; the server now also publishes `context.paperclipTaskMarkdownCompact` (description stripped, directives and wake comment kept), and the new `selectPaperclipTaskMarkdown` helper picks the right variant under the same resume rules, falling back to the full markdown when no compact variant exists (version skew safety). - The wake prompt's description block now carries the same user-authored trust framing the task markdown already had. ## Verification - `npx vitest run packages/adapter-utils/src/server-utils.test.ts packages/adapters/claude-local/src/server/acp.test.ts packages/adapters/codex-local/src/server/acp.test.ts server/src/__tests__/heartbeat-context-summary.test.ts` — 137 tests passed, including new coverage for suppression, resume omission plus breadcrumb, assignment-shaped resume inclusion, compact-variant building, variant selection, and an end-to-end ACPX prompt-assembly test asserting the description appears exactly once on fresh wakes and not at all on comment resumes. - `npx vitest run` in `packages/adapters/hermes` — 59 tests passed, including a gateway execute-level test asserting the brief is sent exactly once on fresh runs and not re-sent on stable-session resumes. - `tsc --noEmit` in `packages/adapter-utils`, `packages/adapters/claude-local`, `packages/adapters/hermes` — clean; `server` matches the `master` baseline exactly (pre-existing plugin-sdk resolution errors only, none in touched files). - Pre-existing failures confirmed identical on clean `master`: claude-local `execute.remote.test.ts` / `test.probe.test.ts`, adapter-utils `mcp-isolation.integration.test.ts` (requires a newer local Claude CLI). ## Risks - Behavioral shift, prompt-only: a resumed session woken by a comment on an issue it never handled (rare — assignment wakes normally precede comment wakes) would not get the inline description; the breadcrumb plus the standard issue-fetch path covers it. - Additive context key (`paperclipTaskMarkdownCompact`); older adapters ignore it and newer adapters fall back to the full markdown when it is absent, so mixed-version deployments degrade to current behavior. - No schema, migration, or API changes; the structured wake-payload JSON shape is unchanged. - Known follow-up deliberately out of scope: openclaw embeds the raw wake-payload JSON (which still contains the description) in prompt text for machine parsing. The hermes-gateway lane is handled: it detects stable-session resumes (issue/agent session-key strategy plus a stored prior session id), compacts the task markdown, and omits the description from its prompt-embedded JSON copy. > This is a focused correctness/efficiency fix to existing wake plumbing and does not overlap with planned roadmap feature work. ## Model Used - Anthropic Claude Fable 5 (`claude-fable-5`), extended thinking enabled, with repository tool use, shell execution, and local test execution via Claude Code. ## 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) - [ ] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details (execution-workspace branch, same convention as merged #10202) - [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 (code-level docs; no user-facing docs affected) - [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 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
DottaandPaperclip
|
d32ed88443 |
fix(recovery): route recovery by failure cause (#9634)
## Thinking Path > - Paperclip is the open source control plane people use to coordinate AI-agent companies and their work. > - Its recovery subsystem detects stranded issue execution and decides whether to retry, escalate, or request operator intervention. > - The existing recovery path used a mostly generic owner ladder and generic execution contract, so transient failures could wake a manager who then performed the deliverable instead of repairing and returning the task. > - Provider quota failures also entered the same takeover path even when the correct action was to wait for capacity and retry the original assignee. > - Recovery actions already retain the source owner and evidence needed to choose a cause-specific route, render a scoped contract, and measure whether work was handed back. > - This pull request adds a cause-keyed recovery playbook, propagates its contract through every built-in adapter, and makes resolved recovery actions return work to the original owner by default. > - The benefit is bounded self-recovery that preserves task ownership, avoids needless management takeover, and makes recovery outcomes observable. ## Linked Issues or Issue Description No matching public GitHub issue was found. Related recovery work was reviewed but is not duplicated here: #9630 restores bounded recovery continuations, #8807 changes one assignee-ranking case, and #9404 records runtime-failure transition evidence. This change instead introduces cause-specific routing and recovery contracts across the recovery lifecycle. ### What happened? When an issue became stranded, recovery generally selected an owner through the same fallback ladder and rendered the normal execution contract. That made the recovery wake look like ordinary deliverable work, even when the correct action was to retry the original agent, repair its runtime, or wait for a provider quota reset. ### Expected behavior Recovery should select a response by failure cause, tell the recipient to recover rather than complete the deliverable, suppress takeover wakes for provider quota waits, and return repaired work to its original assignee unless the recovery owner explicitly completes it. ### Actual behavior Recovery could escalate transient failures to management, omit the cause-specific next action from the wake, and leave the recovery owner assigned after the runtime problem was resolved. ### Impact The generic path creates avoidable management work, ownership churn, and budget consumption while obscuring whether recovery successfully returned work to the responsible agent. ## What Changed - Added cause-keyed routing for process loss, missing disposition, provider quota limits, Codex output inactivity, workspace validation failures, and fallback recovery causes. - Added recovery-scoped wake rendering that replaces the generic execution contract with the failure summary, original assignee, attempt count, next action, and cause-specific playbook instruction. - Propagated the structured recovery contract through all built-in adapter execution paths, including Hermes local and gateway adapters. - Added provider-quota wait monitoring so capacity failures schedule the original assignee instead of enqueueing a takeover wake. - Added hand-back behavior and `handed_back` / `owner_completed` outcome accounting when recovery actions are resolved. - Added focused routing, renderer, quota-monitor, and hand-back regression coverage plus implementation-spec documentation. ## Verification - `pnpm exec vitest run packages/adapter-utils/src/server-utils.test.ts server/src/__tests__/heartbeat-process-recovery.test.ts server/src/__tests__/heartbeat-workspace-branch-containment.test.ts server/src/__tests__/issue-recovery-actions.test.ts` - 4 test files passed; 194 tests passed. - Targeted `pnpm --filter ... typecheck` across `@paperclipai/adapter-utils`, `@paperclipai/shared`, `@paperclipai/server`, `@paperclipai/ui`, and all nine changed adapter packages. - 13 affected workspace packages passed typecheck. - `pnpm check:token-gates` - All UI token gates passed. ## Risks - Recovery routing behavior changes for stranded work, so an incorrectly classified cause could select a different recipient than before; fallback causes retain the existing management ladder. - Provider quota detection depends on structured failure evidence and conservative text matching; unmatched failures continue through fallback recovery. - Adapter prompt plumbing changes across built-ins, covered by shared renderer tests and compile-time call signatures. > 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 with exact model ID `gpt-5.6-sol`, using reasoning, tool use, and code execution. The runtime does not expose its configured 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> |
||
|
neerajdad123-byte
|
70c86d2c73 |
fix(hermes): strip ANSI escape codes from terminal output in UI parsers (#8731)
## Thinking Path
> - Paperclip is the open source app people use to manage AI agents for
work
> - Hermes adapter produces terminal output with ANSI color codes on
stdout
> - These escape sequences flow through the UI parsers untouched and
render as raw garbage text
> - This PR adds ANSI stripping at the entry point of all four Hermes
parse-stdout entry points
> - The same regex is already proven in claude-local adapter
> - The benefit is clean, readable terminal output for Hermes agents
## Linked Issues or Issue Description
No existing issue. This is a bug report:
**What happened**
Hermes terminal output displayed ANSI color codes as raw text in the
Paperclip UI, making agent output unreadable.
**Expected behavior**
Terminal output in run transcripts should be clean text without
invisible control characters.
**Steps to reproduce**
1. Connect a Hermes agent to Paperclip
2. Create and assign a task to the agent
3. View the run transcript — ANSI escape codes appear as raw garbage
**Paperclip version or commit**
|
||
|
DottaandPaperclip
|
d77fab6aae |
fix(adapters/hermes-gateway): improve onboarding configuration (#8678)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Paperclip runs agents through adapters, including built-in local and gateway-style adapters. > - Hermes gateway users need to connect Paperclip to an already-running Hermes API server. > - The gateway setup flow was missing clear non-local adapter configuration fields and accepted fewer URL shapes than operators naturally paste from Hermes. > - It also surfaced sparse diagnostics when the gateway was unreachable or when Paperclip generated onboarding prompts for gateway agents. > - This pull request tightens Hermes gateway configuration, URL normalization, diagnostics, and onboarding defaults. > - The benefit is that Hermes gateway setup is easier to complete and easier to debug without affecting unrelated adapters. ## Linked Issues or Issue Description No public issue found for this exact follow-up. Related prior/in-flight Hermes work: - Refs #2363 - Refs #4359 - Refs #6473 Problem statement: - **Type:** Adapter follow-up / setup reliability - **Adapter:** `hermes_gateway` - **Motivation:** Operators configure `hermes_gateway` against a running Hermes API server, but the UI and onboarding flow did not expose enough gateway-specific configuration or diagnostics. - **Expected behavior:** Paperclip should render the gateway fields, normalize common Hermes dashboard/API URL inputs, preserve sensible gateway onboarding defaults, and report reachability failures with actionable detail. - **Deployment mode:** Built-in adapter package in the Paperclip monorepo. ## What Changed - Added UI config fields for non-local Hermes gateway settings, including tests for rendering and field behavior. - Accepted Hermes dashboard URLs by normalizing them to gateway API URLs for execution. - Improved gateway reachability and run URL diagnostics. - Updated Hermes gateway onboarding text/default behavior so join prompts preserve gateway configuration. - Added focused server, UI, and adapter tests for the gateway configuration and onboarding paths. ## Verification - `pnpm install --frozen-lockfile --prefer-offline` - `pnpm --filter @paperclipai/hermes-paperclip-adapter exec vitest run src/gateway/server/execute.test.ts` — 20 passed - `pnpm exec vitest run server/src/__tests__/invite-accept-gateway-defaults.test.ts server/src/__tests__/invite-onboarding-text.test.ts ui/src/adapters/hermes-gateway/config-fields.test.tsx ui/src/components/AgentConfigForm.render.test.tsx ui/src/lib/agent-onboarding-prompt.test.ts` — 23 passed across 5 files - Confirmed the PR diff excludes `pnpm-lock.yaml` and `.github/workflows`. ## Risks Low to moderate risk. The changes are scoped to Hermes gateway configuration/onboarding and generic non-local adapter field rendering. The main risk is rejecting an unusual Hermes URL shape that should be accepted; the normalization tests cover dashboard and API URL variants added here. > 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-based coding agent in a tool-enabled local CLI environment, with shell/GitHub/Paperclip API access. Exact runtime model identifier was 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> |
||
|
DottaandPaperclip
|
fd2f82ac5b |
[codex] Add built-in Hermes adapters (#8543)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Agent adapters are the boundary between the control plane and the runtimes that actually do work. > - Hermes support needs to be available as first-class local and gateway adapters while still preserving the adapter-manager override path for external packages. > - The adapter work touches runtime execution, UI adapter metadata, onboarding prompts, scoped credentials, release packaging, and smoke coverage, so the handoff needs concrete verification rather than only unit tests. > - This pull request adds built-in Hermes local and Hermes gateway support, keeps external adapter overrides compatible, and documents/tests the gateway flow end to end. > - The benefit is that operators can hire Hermes-backed agents without a manual plugin install, while self-hosted installs can still override/shadow the built-ins through Adapter manager packages. ## Linked Issues or Issue Description No public GitHub issue exists for this exact Hermes built-in adapter, gateway onboarding, and release-source work. Problem description: - Hermes local and gateway adapters need a public, reviewable source path in the monorepo so package artifacts and built-in adapter behavior match the application source. - Operators need built-in `hermes_local` and `hermes_gateway` adapter choices without losing the ability to install external Hermes packages as overrides. - Gateway onboarding needs secure defaults for API server URLs, API keys, and generated agent setup text. - Hermes-originated task bridge credentials need narrower API-key scope configuration. - Related public PRs found during duplicate search include #3027, #2363, #7544, #7950, #8095, and #8543. ## What Changed - Added the unified Hermes adapter package with local and gateway server/UI/CLI exports, config schemas, transcript parsing, model detection, and package metadata. - Registered `hermes_local` and `hermes_gateway` as built-in adapters across shared constants, server registries, CLI packaging, and UI adapter registries. - Kept the external adapter override path compatible so installed Hermes packages can shadow built-ins and restore the built-in parser when disabled. - Added Hermes gateway onboarding docs, board-operator docs, Docker smoke assets, and shell smoke harnesses for join/e2e validation. - Added scoped task-bridge API-key support, authorization checks, issue-origin handling, and tests for Hermes-created Paperclip tasks. - Hardened gateway transport and redaction behavior for API keys, headers, session data, and smoke diagnostics. - Updated release packaging/bootstrap checks for the Hermes packages while leaving `pnpm-lock.yaml` out of the PR per repository policy. ## Verification Targeted local verification recorded before PR handoff: - `pnpm --filter @paperclipai/hermes-paperclip-adapter exec vitest run src/gateway/server/execute.test.ts` — 14/14 passed. - `pnpm test:hermes-gateway-smoke` — 6/6 passed. - Hermes package typecheck/build checks passed. - Focused server/UI adapter tests passed — 31/31. - Release helper Node tests passed — 18/18. - `git diff --check origin/master..HEAD` passed. Fresh Docker E2E smoke evidence: - Ran `pnpm smoke:hermes-gateway-e2e` on 2026-06-26 with a fresh state directory and fresh Docker container against a live Paperclip dev server. - Hermes direct execution reached `completed`. - Hermes stop/cancel path reached `cancelled`. - Hermes gateway created a Paperclip task, Paperclip ran the Hermes agent, and the task reached `done` with the expected marker response. - Temporary board auth keys, token files, smoke state, and Docker containers were cleaned up after the run. PR checks on head `b5eae40ce`: - GitHub Actions passed: `policy`, `review`, `Typecheck + Release Registry`, all general test shards, all serialized server shards, `Build`, `Canary Dry Run`, `e2e`, and aggregate `verify`. - External checks passed: Snyk and Socket Project Report. - External Socket Pull Request Alerts remained pending after the first-party CI matrix completed. ## Risks - Medium risk: this spans adapter registration, package publishing, gateway execution, onboarding docs, API-key scoping, and UI adapter metadata. - Migration risk is low: the scope-config migration adds a nullable column and does not rewrite existing keys. - Gateway execution depends on operator-provided Hermes API configuration; the smoke covers the Docker gateway path but real deployments may differ by network/auth setup. - Direct Greptile review on the latest expanded diff is file-count limited, although the commitperclip review gate passed. > 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 coding agent, tool use enabled in a local repository workspace. Context window size is not exposed in this environment. ## 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] Commitperclip review gate is green; direct Greptile review is file-count limited on the latest expanded diff - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing> |