forked from farhoodlabs/paperclip
a1b30c9f35
## Thinking Path > - Paperclip is a control plane for autonomous AI companies. > - Issues are the core unit of work, and issue comments are how board users and agents coordinate execution. > - Some issue conversations need to produce plans and approvals instead of immediate implementation work. > - The existing issue contract did not distinguish standard execution comments from planning-oriented issue work. > - This pull request adds an issue work-mode contract and board UI affordances for standard vs planning mode. > - The benefit is that planning-mode issues can be created, displayed, discussed, and carried through agent heartbeat context without losing the normal issue workflow. ## What Changed - Added `standard` / `planning` issue work-mode contracts across DB, shared validators/types, server issue flows, plugin protocol, and adapter heartbeat payloads. - Added an idempotent `0081_optimal_dormammu` migration for `issues.work_mode`, ordered after current `public-gh/master` migrations. - Updated heartbeat/context summaries and issue-thread interaction behavior so planning work mode is preserved when creating suggested follow-up issues. - Added UI support for planning-mode issue creation, issue rows, detail composer styling, and composer work-mode toggles. - Added focused server/shared/UI tests plus a Playwright visual verification spec for planning-mode surfaces. - Rebased the branch onto current `public-gh/master` and added durable planning-mode screenshots under `doc/assets/pap-3368/`. ## Verification - `pnpm --filter @paperclipai/db run check:migrations` - `pnpm exec vitest run --project @paperclipai/shared packages/shared/src/validators/issue.test.ts` - `pnpm exec vitest run --project @paperclipai/server server/src/__tests__/heartbeat-context-summary.test.ts server/src/__tests__/issue-thread-interactions-service.test.ts server/src/__tests__/issues-goal-context-routes.test.ts --pool=forks --poolOptions.forks.isolate=true` - `pnpm exec vitest run --project @paperclipai/ui ui/src/components/IssueChatThread.test.tsx ui/src/components/NewIssueDialog.test.tsx ui/src/components/IssueRow.test.tsx ui/src/pages/IssueDetail.test.tsx` - `pnpm exec vitest run --project @paperclipai/adapter-utils packages/adapter-utils/src/server-utils.test.ts` - `PAPERCLIP_E2E_SKIP_LLM=true npx playwright test --config tests/e2e/playwright.config.ts tests/e2e/planning-mode-visual-verification.spec.ts` ## Screenshots Desktop planning detail:  Desktop planning row:  Desktop staged standard toggle:  Mobile planning detail:  Mobile planning row:  ## Risks - Medium migration risk: this adds a non-null issue column. The migration uses `ADD COLUMN IF NOT EXISTS` so installations that applied an older branch-local migration number can still apply the final numbered migration safely. - Medium contract risk: issue payloads, plugin payloads, and adapter heartbeat payloads now include work mode; compatibility is handled by defaulting missing values to `standard`. - UI risk is moderate because composer controls changed; focused component tests and visual e2e coverage exercise standard vs planning display and toggle behavior. > 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 in a local Paperclip worktree, with shell/tool use. Exact context-window size is not exposed in this runtime. ## 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 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 - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>
OpenClaw Gateway Adapter
This document describes how @paperclipai/adapter-openclaw-gateway invokes OpenClaw over the Gateway protocol.
Transport
This adapter always uses WebSocket gateway transport.
- URL must be
ws://orwss:// - Connect flow follows gateway protocol:
- receive
connect.challenge - send
req connect(protocol/client/auth/device payload) - send
req agent - wait for completion via
req agent.wait - stream
event agentframes into Paperclip logs/transcript parsing
Auth Modes
Gateway credentials can be provided in any of these ways:
authToken/tokenin adapter configheaders.x-openclaw-tokenheaders.x-openclaw-auth(legacy)password(shared password mode)
When a token is present and authorization header is missing, the adapter derives Authorization: Bearer <token>.
Device Auth
By default the adapter sends a signed device payload in connect params.
- set
disableDeviceAuth=trueto omit device signing - set
devicePrivateKeyPemto pin a stable signing key - without
devicePrivateKeyPem, the adapter generates an ephemeral Ed25519 keypair per run - when
autoPairOnFirstConnectis enabled (default), the adapter handles one initialpairing requiredby callingdevice.pair.list+device.pair.approveover shared auth, then retries once.
Session Strategy
The adapter supports the same session routing model as HTTP OpenClaw mode:
sessionKeyStrategy=issue|fixed|runsessionKeyis used when strategy isfixed
Resolved session key is sent as agent.sessionKey.
Payload Mapping
The agent request is built as:
- required fields:
message(wake text plus optionalpayloadTemplate.message/payloadTemplate.textprefix)idempotencyKey(PapercliprunId)sessionKey(resolved strategy)
- optional additions:
- all
payloadTemplatefields merged in agentIdfrom config if set and not already in template
- all
Timeouts
timeoutSeccontrols adapter-level request budgetwaitTimeoutMscontrolsagent.wait.timeoutMs
If agent.wait returns timeout, adapter returns openclaw_gateway_wait_timeout.
Log Format
Structured gateway event logs use:
[openclaw-gateway] ...for lifecycle/system logs[openclaw-gateway:event] run=<id> stream=<stream> data=<json>forevent agentframes
UI/CLI parsers consume these lines to render transcript updates.