DottaandPaperclip
0c9d10d695
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Product and agent access maps describe the same capability IDs. > - Agent connection management changes the callable operations and permission boundaries. > - Reviewers need an operation inventory that distinguishes API access, human handoffs, and fixture evidence. > - This pull request adds saved setup screens and updates the maps for #17737. > - The benefit is that users and contributors can inspect the coverage and remaining boundaries. ## Linked Issues or Issue Description **Subsystem affected** Product and permission documentation, saved authentication setup UI and consent metadata, and product/agent access maps. **Problem or motivation** The current maps describe board-only management paths. They need to match delegated connection management and distinguish administration from ordinary tool execution. **Proposed solution** Record route operations, required grants, responsible-user limits, transport, saved authentication handoffs, provider-fixture evidence, and explicit local-operator boundaries for every connection family. **Roadmap alignment** This is the documentation companion to #17737. It covers existing Connected Apps, governed MCP gateways, chat channels, and personal/shared AI accounts. It uses existing server setup operations and adds their saved handoffs to the existing UI. ## What Changed - Show saved AI sign-in and connection setup handoffs in the existing UI. - Open GitHub import and rotation links at the required human step. Resume a committed rotation after reload without asking for another secret. - Restore saved Google service choices for the addressed user while preserving newer consent. Successful direct/cloud consent records its own timestamp, independently of refresh or lease writes; existing refresh paths preserve it. - Update product, implementation, and permission-default documentation. - Reconcile app permissions, connection setup, chat channels, profiles/gateways, and model account coverage. - Use matching capability IDs in the product and agent access maps. - Label source-reviewed operations separately from fixture-tested operations and live provider setup. - Preserve catalog creator attribution under the responsible user, with the actual agent still recorded. This follow-up moved from the implementation to keep both reviews below 100 files. This companion now changes 38 files, including the preserved Vercel personal-credential and OAuth callback attribution follow-ups alongside consent and catalog ownership. - Name the addressed-human browser-session and consent step for Slack managed authorization and installation. Preserve source-only evidence for those individual operations. ## Verification - Current companion head: `04d40cdd605452d91cf4931476eb292a210825af`, including implementation `2ecd6451d0` and master `ea727dc3c2`, 38 files. All intended companion files survive: 35 are byte-identical to the previous companion; two chat maps and qualification add current evidence. Exact-head Superagent passed and Paperclip Review supplied an actual neutral5/5 assessment with no findings and explicit no-independent-runtime/live/current-CI verification limits. Exact-head Greptile also completed at5/5 with no findings; both formerly failed shards and their verification aggregate passed on attempt2; full exact-head Linux CI workflow40446969603 completed SUCCESS. All current checks and statuses are terminal clean, with no unresolved findings. This PR remains dependent on #17737 and needs fresh checks after its required post-squash replay. The preceding 605 head’s reviews are historical after this update. Older b0ea Linux workflow success after its single rerun also remains historical. - Earlier preserved-stack verification passed **2,165 tests**: 70 assembled-server actual-auth scenarios, 27 OpenAPI contracts, 2,022 native API tests and 46 saved GitHub wizard cases in fresh PostgreSQL. The parent also passed **141 existing gateway/policy tests**. Workspace typecheck/build, maps and token gates passed. The initial typecheck IPC denial and all material intermediate regressions remain in the qualification record; no full local sweep or live provider setup is claimed. - Operation maps now cover issuer/target gateway policy intersection and post-approval revocation, bounded activity pagination through private-only windows, and native local-login encrypted receipts. The companion preserves the Vercel OAuth callback ownership change with its existing credential ownership follow-up. - Parent CI has one retained connection-intent e2e failure from a periodic-recovery timing race. GitHub refused the first job-rerun attempt while its workflow was nonterminal. Once completed, the single failed-job rerun was accepted as attempt 2 and passed, including the full parent Linux workflow. - Companion Linux server shard 4/12 retained a cleanup-idleness timeout in `login-cleanup-work.test.ts` (active work was still 1 after its five-second wait). The same unchanged cleanup suite passed all 16 cases in the parent Linux job 121950185096 and all 16 cases locally against a fresh disposable PostgreSQL database. Relevant cleanup/reaper/scheduling runtime code is unchanged. The single unchanged-code failed-job rerun was accepted as **attempt 2** on the previous `b0ea3c940f` head (workflow 40431671705). The failed shard and complete Linux workflow passed on attempt 2; no additional unchanged-code rerun was used for this failure. The first local attempt failed the existing dedicated `_test` database-name guard before running tests; the correctly named fixture passed without weakening the guard. - **Earlier 82 GitHub UI tests passed**. All three new replacement cases were red before the fix. A confirmed unchanged generation preserves the earlier copy; a changed or unreadable generation blocks copying and reconnecting. An explicit status check can restore the copy when it is still current. All earlier import, rotation, verification, and retry states remain covered. - The complete stack passed **82 API/OpenAPI tests** in fresh PostgreSQL, including 55 scenarios with real agent keys, run JWTs, human sessions, production defaults, persistence, and deterministic providers. The parent also passed **60 Copilot installation tests**, preserving published v62 and binding combined guidance as v63. - **Earlier 10 focused Google/OAuth tests passed**: eight picker cases and two local-HTTP protocol cases proving consent metadata survives concurrent token refresh. The refresh and legacy UI cases were red before the fix. These protocol fixtures use the existing injected board actor and do not count as agent-authenticated proof. - Workspace typecheck/build passed after the consent change; normal migration generation reported no SQL changes for the additive JSON metadata. The parent's latest caller-authorization correction passed server typecheck/build. Map validation and token gates passed. Maps cover 35 areas and 192 capability IDs. The specification names migration `0380_broken_aqueduct.sql`. - The test-call operation maps now record the full caller/target tool access decision (profiles, policies, and explicit grants), credential identity for every auth label, approval, and rate checks. The profile-only precondition was removed after the new permitted-access cases failed; those cases and the no-auth identity regression now pass. Saved test status requires its originating principal and current linked-task access; actual key/JWT privacy-denial evidence is recorded. - Tool-connection activity is now operation-verified: 100 events over two tasks require two capability decisions and at most two run captures (previously 100/102), preserve private-event filtering, and deny the next request after audit revocation. The regression was red before the fix. - Cloud enrollment creation and callback entries now name instance-administrator and company/principal checks. The callback is a browser return with HTML or a 303 redirect. Status reads retain their separate board-actor rule. - Operation maps identify the API, transport, authorization, evidence, and human/operator boundaries. Structural checks do not establish live provider behavior. Earlier failures and fixture corrections remain in `doc/plans/2026-10-13-connection-api-parity.md`. - An earlier companion head (`26edbe17`) received an actual Paperclip Review assessment of 5/5 with no actionable findings, published with neutral status. That review did not run tests or confirm CI, and it is historical for this new head. The prior incomplete execution result is not counted as a passed assessment. Fresh review remains pending. The duplicate enrollment findings have explanatory replies and are resolved. - The latest implementation correction passed all 55 actual-auth scenarios and 27 OpenAPI contracts (separate commands). It repairs unavailable old credential material, preserves fresh import versus configured reconnect links, and distinguishes credential field sets/completion modes in handoff keys. The new fresh-link and collision cases were red before the fix. All 41 GitHub wizard tests now pass, including filling the fresh saved handoff and asserting App import rather than reconnect; UI typecheck, maps and token gates also pass. Qualification retains the earlier failures and an incorrect OpenAPI filename that selected only the integration module before the correct separate contract run. - Configured GitHub credential-entry links carry canonical requested fields and all/any mode. The form displays and submits those values through human reconnect while retaining other saved credentials. Two webhook/client-secret cases were red before the fix; combined all/any and legacy-link cases also pass. The current UI fixes the oldbf760912baseline referenced by the duplicate main review finding. - After merging masterbaec3abd67and regenerating migration0380, the complete stack passed **128 tests** (55 actual-auth, 27 OpenAPI and 46 GitHub wizard cases), workspace typecheck/build, maps and token gates. Eight current Google UI cases also passed. The two local-HTTP OAuth cases could not initialize embedded PostgreSQL in this fresh attempt, so that attempt is not a protocol pass; the earlier ten-case evidence is historical and fresh Linux CI remains required. - The reproduced Linux automatic-Slack challenge failure is fixed by retaining verification only for the same signing fingerprint and callback URL; all eight neighboring provider compatibility cases pass. Qualification also retains the uncommitted GitHub field variant that failed initial-secret compatibility before the extension was narrowed to reconnect, and the first unmigrated external-database diagnostic. Upstream 0379 remains intact; normal generation/pruning produced additive/idempotent 0380, with repeated application verified. - Both PRs must ship together. The user authorized merging when checks pass. Merge #17737 first, replay only this companion's changes onto master, retarget this PR, and require fresh current-head CI and review before its squash merge. - The updated maps distinguish authorized bot-token/API-key setup from human verification-key entry and forbid generic channel secret-reference replacement. Actual key/JWT security baselines were red before both guards; all 82 API/OpenAPI cases, eight native receipt protections, and 49 policy-service tests now pass. The qualification record preserves the initial lifecycle/fixture/union-assertion diagnostics and the preceding Linux CI assertion failures. Maps pass on this updated stack. Fresh exact-head CI and reviews remain required. - The parent now preserves a per-field credential-change boundary before retiring saved credential-entry cards. Old health, unchanged entry, unrelated repair and retries cannot bypass it. Current authority is checked before and inside credential persistence; a real provider-time revocation regression was red before the fix. Final 82 API/OpenAPI tests, four neighboring lifecycle cases, and server typecheck/build pass. Maps pass, and qualification retains the hidden-metadata fixture failure and the measured minute-boundary rate-test failure. Production rate behavior is unchanged; only the relevant test Date clock is fixed. - After the current master/parent refresh, all **341 affected UI cases**, combined workspace typecheck/build, maps and token gates pass. The updated parent also passed **97 actual-auth/OpenAPI cases**, **141 gateway/policy cases** and **61 profile installation cases**. Published upstream Copilotv62/v63 remain unchanged; combined guidance is now v64 (`sha256:22e31f95ef972bcead98a4a707c9f33433558fd111e390e027a2bbb4346e112a`). Qualification retains the initial source-identity failure and fixture port/migration setup failures. No full local sweep, fresh local OAuth protocol run or live acceptance is claimed; fresh Linux CI must qualify this successor. - Latest review follow-up: the parent fixes caller-policy bypass in Slack tests/invitations and premature identity-handoff completion. The maps now name caller/target Block/Ask/rate intersection, one charge for a shared bucket, and the addressed human’s exact current identity link. Parent verification passes all **99 actual-auth/OpenAPI tests**, typecheck and build. The preserved combined companion passes the four focused tests (including twelve Slack policy/recipient combinations and the actual human OAuth confirmation path), workspace typecheck/build and maps. The 50 embedded-PG continuation cases were skipped locally because their database could not start; fresh Linux CI remains required. All material red/intermediate results and corrected-fixture evidence are retained in the qualification record. - Current `04d40cdd60` CI workflow40446969603 retained two new failures: server1/12 `workspace-runtime.test.ts` could not reach a fixture subprocess’s health endpoint within its ten-second readiness window (job122001926052), and chat2/3 `wakes Slack session sync from publication commit and leaves settled action queues quiet` observed one select after its idle predicate (job122001925936). Both same cases passed in parent `2ecd6451d0` Linux jobs122001920494/122001920581. The runtime and queue implementations are unchanged by this companion. Both failing cases also pass unchanged locally: two real-subprocess runtime readiness/reuse tests and the exact Slack quietness assertion against a fresh migrated PostgreSQL database. Logs: `/tmp/parity-04d-server1-failure.log`, `/tmp/parity-04d-chat2-failure.log`, `/tmp/parity-2ecd-server1-green.log`, `/tmp/parity-2ecd-chat2-green.log`, `/tmp/parity-04d-runtime-qualified.log`, `/tmp/parity-04d-chat-quiet-qualified.log`. The single standard unchanged-code failed-job rerun was **accepted as attempt2** on the unchanged exact head at `2026-10-27T04:24:30.513973+00:00` after the workflow completed. Both new failure retry allowances are now **consumed**; both failed shards and the complete Linux workflow have now passed on attempt2, including the verification aggregate. No additional unchanged-code rerun will be requested for either failure. No timing, assertion, idle-work guard or policy was weakened. If either case fails again, investigate/fix rather than rerun again. The older 5b/b0ea rerun allowances remain consumed and separate. ## Risks - Saved handoff links depend on the API changes in #17737, including the nonsecret credential-generation metadata. Both PRs must ship together. - A map can overstate operation coverage. Entries identify their evidence and retain human authentication and trusted-host limits. - Structural map checks do not prove live provider behavior. ## Model Used - OpenAI Codex, GPT-6 family, with reasoning, repository tools, and code execution. The runtime does not expose a more specific deployment ID or 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 — focused UI/guidance and map checks - [x] I have added or updated tests where applicable — saved setup UI tests and map validation apply - [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 — exact `04d40cdd60` full Linux CI completed SUCCESS on attempt2; all current checks/statuses are terminal clean, with an actual neutral5/5 Paperclip assessment - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups — exact `04d40cdd60` review completed with no findings - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>
21 KiB
navigation
| navigation | ||||||
|---|---|---|---|---|---|---|
|
External chat and email
People can talk to an assigned agent through configured external channels, bind their identity, exchange files, and inspect delivery state. Each provider has a different identity, threading, and attachment contract.
Feature ID: chat-channels.
Implementation: endpoint setup, endpoint detail, email setup.
Agent access: companion.
Sub-features
providers:chat-channels/providers— configure the available Slack, Discord, Microsoft Teams, Telegram, GitHub, AgentMail, and experimental iMessage Photon and Speko paths; availability still depends on gates and provider support.identity:chat-channels/identity— link the external sender to the intended authorized Paperclip identity.conversation:chat-channels/conversation— route inbound messages to the selected agent and send replies to the correct thread.attachments:chat-channels/attachments— transfer supported files with inspectable delivery and failure states.lifecycle:chat-channels/lifecycle— inspect endpoint activity, repair auth, and disable delivery when required.outbound-email:chat-channels/outbound-email— start a task-bound AgentMail conversation, reply to its exact message, and inspect deduplicated publication and provider delivery.
How to get to it (user POV)
external-thread
Message the configured bot/address from its external provider and follow the corresponding Paperclip conversation/task.
endpoint-management
Delegated setup can save ordinary bot tokens and API keys. Provider verification keys require the addressed human credential-entry step or verified provider provisioning. Generic setup returns the saved handoff without changing those keys, and generic connection updates cannot replace channel credential references. A replacement card waits for an actual protected-value change and restored verification; old health, unchanged entry and unrelated bot-token repair do not complete it. Fresh GitHub handoffs open the import form; configured endpoints retain reconnect. Credential-entry field sets and completion modes stay distinct while matching retries reuse their saved baseline. Complete human replacements can repair disabled, deleted or unreadable old vault values. Saved links name the requested fields and completion mode; configured GitHub forms support targeted replacements while keeping other saved credentials. Provisioned Slack challenge proof survives runtime storage only for the same signing key and callback URL. The actual-auth Slack/GitHub fixtures cover these boundaries, retries, revocation and permitted bot-token repair; live provider repair remains separately qualified.
Open /apps/chat/:endpointId/settings and the endpoint’s other available tabs; identity confirmation uses /chat-identity/confirm.
For delegated Slack test messages and identity invitations, apply a Block or Ask first rule to the calling agent while allowing the endpoint's assigned agent. Verify no message is sent. Exercise caller, target and shared rate limits: one shared quota admits one send and the next distinct request is denied. For a saved GitHub identity handoff on an otherwise healthy endpoint, verify the card stays pending before identity confirmation and after an OAuth callback alone. Confirm the addressed user's identity through their human session, then verify continuation becomes available. Revoked, expired, wrong-user and wrong-installation links must keep the handoff blocked. These cases pass through the assembled API with real key/JWT/session middleware and deterministic providers; live Slack/GitHub consent remains separate evidence.
outbound-agentmail
Use paperclipai email inboxes --company-id <company-id>, then email send --company-id <company-id> --file <new-email.json> or email reply --company-id <company-id> --file <reply.json>. Inspect email thread <email-task-id> --company-id <company-id> and email delivery <publication-id> --company-id <company-id>. Agent mutations must provide --run-id or the active PAPERCLIP_RUN_ID.
Driving it with Playwright and provider clients
Preconditions: follow the baseline. Use a
test provider account/channel with permission to send messages. Gates differ:
AgentMail bypasses the chat-connectors UI gate, GitHub uses
enableGitHubReviewBots, and other chat providers use enableChatConnectors.
Setup is covered in connection setup.
external-thread
Automated: channel integration uses provider fixtures; it does not prove a live Slack, Discord, Teams, Telegram, GitHub, email, or Photon delivery.
Monitor continuation regression: database checks verify the exact originating conversation, rejected forged/mismatched receipts, one working publication, no completion for a yielded run, and saved-response recovery. In a disposable live thread, request work that needs deferred repository preparation. Verify a useful continuation explanation, automatic resumption, and the final result in that same thread. A successful provider turn alone is insufficient.
GitHub review comment regression (2026-10-19): repeated PR review requests reuse
one main App comment, including across restart and reconnect. Test a leading
request for an external bot (@greptile review) and verify it creates no wake or
acknowledgement. Stop execution before a milestone is staged, run maintenance,
and verify the existing comment reports the stop; saved requests on a blocked
task show paused state. Preserve newer progress and confirmed or uncertain replies.
Repeat terminal reconciliation with native identity and no legacy wake fields.
Check delayed acknowledgements, check-only assessments followed by formal reviews,
and combined requests with separate pre-upgrade placeholders.
GitHub review attention regression: publish a 3/5 assessment, then wait for the next provider event. The task stays in review without a completion card or Mine entry. A later 5/5 review with passing required checks can finish quietly. A real repository-access request enters Mine until resolved. The native external-chat database suite checks these states and revoked endpoints using stored provider receipts; live model adherence remains a separate check. It also checks saved monitors, disabled repositories, multiple reviewed heads, read-only finish validation, withdrawal rollback, and separate approval gates. Repeat the review wait after a tree resume and a same-agent continuation with no new provider message. Accepted requester lineage and the latest saved review publication keep the task in review without a self-wake or duplicate publication. A newer unreviewed head, changed requester/repository, or revoked access cannot inherit the prior head's passive wait. Omitted/null yielded continuation is filled from authorized server task context after a current-head review, an accepted tree resume inheriting it, or a same-head follow-up with this run's processed useful reply bound to its exact current source. Pending or ambiguous replies and acknowledgements do not authorize this fallback. A malformed first report can recover by omitting the continuation; explicit malformed input remains rejected. Revocation between context read, finish and commit preserves the task without self-waking. Done policy is unchanged.
Manual: For each supported provider being changed, send a unique message, verify the intended agent/company receives it, and inspect the actual external reply in the original thread. Repeat with an unlinked/unauthorized sender, duplicate inbound delivery, and one supported attachment. Record provider-specific results separately.
GitHub review prompt regression: open a PR and push twice. Each task message contains the event and commit identifiers; configuration comes from the admitted delivery snapshot and the PR description is fetched when needed. Inspect the native provider's submitted envelopes: a verified resume sends only the current batch and any changed configuration, while a fresh session receives full review instructions and task context. Change configuration between pushes and verify the queued older request retains its original snapshot. Integration fixtures cover the database and prompt contracts; they do not prove live provider delivery.
For Slack, enable Require at-mention and Allow direct messages. Send a plain DM and follow up without a mention: both should reach the agent, with top-level replies to top-level DMs. Channel messages and thread replies still require a mention when that setting is enabled. Disable direct messages and confirm a plain DM is rejected. Use a private channel for threaded conversations.
For Slack acknowledgement latency, mention the bot with and without an attachment.
Eyes should appear after authorized task/comment persistence, independently of
file preparation, subscription and agent startup. Duplicate delivery must keep
one receipt; the final reply must remove only its source message's eyes. Record
live mention-to-reaction timing separately from the PostgreSQL fixture tests and
the chat.slack.receipt transport span described in Observability.
During a top-level DM run, verify that the bot adds eyes to the source message and removes them when the final reply arrives. The pinned Slack SDK encodes a linear DM with an empty thread timestamp; receipt transport accepts that address while still validating the channel and the source message timestamp.
For an agent with two linked Slack endpoints, compare assignment preparation and tool discovery in the run trace. Endpoint checks may overlap in pairs. Confirm that both permitted tool sets remain available, then revoke one linked identity and confirm that the next preparation excludes it. The database regression uses real PostgreSQL with one connection and controlled credential resolution; it does not prove live provider latency or an end-to-end response target.
Catalog discovery rechecks live authority and current credentials without computing the unused compatibility fingerprint. Assignment snapshots and governed calls retain full revision resolution. The same regression verifies identical catalog membership, absence of digest SQL during discovery, and revocation on the next preparation. A faster component is not proof of a faster Slack reaction or final reply; measure those separately on the deployed revision.
For GitHub and Slack tool continuity, start a task from the channel, then admit a later monitor or retry run for the same task. Check that the later run can discover and call its channel tools without a new inbound message. For GitHub, also continue from a board message by the same accepted requester and complete the review in the original conversation, including when the original source is recorded only in legacy wake metadata. Revoke the linked identity and check that the next call fails. Repeat the boundary checks with another task, agent, company, and requester. The channel and provenance fixtures above cover these contracts with synthetic providers; record a live journey separately. For a long-lived task, repeat more than 100 continuations and check that tool access remains available. Fail a later GitHub run after a final answer and check that the earlier answer remains intact. After publishing a PR assessment, deliver an ordinary no-new-work author reply. Hold native presentation after execution succeeds. Verify maintenance makes no provider write while undecided, including repeated passes and the explicit fallback path. Commit either a passive wait, genuine missing response, or failure and verify that the same request settles once with the corresponding behavior. Verify the actual shared summary stays unchanged during queued/running acknowledgements and after the committed passive wait, including maintenance, restart and cleanup. Confirm the per-request acknowledgement is terminal and a second maintenance pass makes no write. Then request a real same-head and changed-head assessment and confirm canonical publication can replace it. Real-PostgreSQL provider fixtures cover this producer and missing/error/unknown write safety; record hosted destination acceptance separately.
endpoint-management
Automated: channel integration covers shared endpoint/delivery behavior; live credential repair and provider ownership remain manual checks.
Manual: Inspect the bound agent and identity, recent activity, and delivery failure details. Repair a disposable credential, retry a safe message when offered, and verify exactly one external reply. Disable the endpoint and confirm new traffic is not silently processed.
For publication failures, reject one operation with a provider 403 and verify that its failure remains visible while unrelated tools and publications continue. Repeat with an authentication failure: the endpoint must require attention and stop provider traffic, while the connection's enabled setting remains unchanged. Reconcile persistent receivers and restart the service; authentication failures must remain stopped while transient disconnections can still recover. The PostgreSQL suite uses controlled provider failures for these cases; live provider credential repair remains a separate acceptance check.
GitHub connections in attention or revoked state show a repair notice above the settings. Reconnect GitHub → Reconnect saved App checks the same App with stored credentials and repairs delivery. Replace App credentials is the fallback, with the saved App ID, a link to its GitHub settings, and PEM upload or paste instructions. The production management Storybook's 04 Recovery group covers these views, pending/failure/success, mobile, and light theme with simulated provider responses. Verify actual credential validity and restored delivery separately against GitHub; a Storybook success does not establish live recovery.
For GitHub, submit a disposable PR and verify the summary heading uses the bot's display name and the check remains Paperclip Review. For two separate bots on one PR, verify their App-scoped checks and comments remain independent.
For GitHub publication recovery, interrupt a response after GitHub accepts a
write and verify one summary, finding, and App-scoped check. Retry the same tool
call and verify it returns the saved receipt. Include text longer than 500
characters and coverage with more than 50 entries. Change only the text suffix
or final coverage entry and verify rejection without another write. Remove the
completed durable publication and verify that a retry cannot dispatch a new write.
Also interrupt metadata reads before publication staging, repeat the exact
begin_review and submit_review requests, and verify typed results and one
assessment publication. Let the original metadata read finish alongside its
retry and verify that both converge on the same publication. Changed requests
and revoked access must still stop preflight recovery.
Leave a transient failure queued,
restart the instance, and verify publication resumes at its saved deadline
without another inbound message. Revoked access and permanent rejections must
stop retries. These recipes are separate from live provider proof.
Configure optional project and workspace defaults at the connection and destination levels. Start a new conversation and inspect its task workspace. Verify that inheritance, an explicit selection, and clearing a default remain distinct. Changing defaults must not move an existing conversation or interrupt its run.
For experimental Speko, enable chat connectors, choose an agent during setup, and verify the provider credentials. On an assigned task, use Talk to agent to open browser voice controls. Check microphone denial, mute, end/restart, navigation during a call, and access revocation. Inspect transcripts and the connection's call history. Callback preferences, incoming phone configuration, and incoming-call approval are separate settings and authorization journeys. The voice components and fixture tests cover presentation; they do not establish live answer retrieval or telephone playback. Those provider outcomes remain explicit release gates.
outbound-agentmail
Automated: Email channel integration uses controlled providers to test durable child tasks/intents, deduplication, reply binding, attachments, delivery, revocation, budgets, run authority, and company boundaries. No dedicated end-to-end CLI email test was identified; these fixtures do not establish actual recipient delivery.
Manual: Use a disposable parent task, authorized AgentMail inbox, and recipient you own. Put endpointId, a stable UUID idempotencyKey, text, parentIssueId, to, and subject in the new-message JSON; supply eligible attachmentIds only if needed. Send, inspect the child conversation/publication, and verify actual received mail. Repeat the identical request/key and confirm one child and provider send; changed content with that key must conflict. Reply with endpointId, conversationId, exact replyToMessageId, text, and a fresh stable idempotencyKey; inspect the actual recipients and received reply. Replies must reject caller-supplied recipient/subject/parent overrides. Test wrong inbox/task/company/run, a canceled task, revoked access/credentials, and an inaccessible attachment. Inspect uncertain provider outcomes before using the administrative resolution path.
Sources: Email CLI, request schema, email routes, and email authority/publication.
Gotchas
-
New outbound email requires a parent task. A reply binds to its stored conversation/message and cannot replace recipients or subject; a queued 202 is not a delivered message.
-
Visibility flags do not pause existing delivery. Disable the disposable endpoint itself to test stopped traffic.
-
One provider’s passing fixture does not qualify another provider or live delivery.
-
An accepted send request does not prove the recipient received the message or file.
-
Use steering and questions for their channel-specific interaction checks.
Storybook verification
attachments
Capability ID: chat-channels/attachments.
Scope: ui Storybook: Mount TaskChatBubble attachments and ChatEndpointDetail provider-specific consent/upload/delivery failure and unknown-outcome states. Local email attachment dialog remains a prototype. Production: Transfer a disposable supported file through each affected provider; verify recipient delivery, read scope, duplicate/replay handling and failure/unknown state without treating notification as file-upload proof. Sources: Source: TaskChatBubble.tsx, ChatEndpointDetail.tsx, chatEndpoints.ts, chat-channels.ts. Tests: TaskChatBubble.test.tsx, task-chat-attachments.test.ts, chat-channels.integration.test.ts, issue-attachment-routes.test.ts
Documentation scope: Chat and email channel setup
Shared recipes name provider checks; each provider transport/thread/identity/file-size/type combination needs separate live evidence and deeper instructions.
Saved-input Retry regression: fail a disposable GitHub turn, change the configured instruction skill, and send a new authorized request while an agent budget gate blocks admission. Clear that gate and use the task thread's ordinary Retry control. Verify the new saved message and its admitted skill snapshot reach one run, rather than replaying the previous failed request. Preserve both original receipts. With a committed failed native result, continuation requires verified controller and environment cleanup; an unknown executor remains held. After successful admission, reload and verify that the prior skipped receipt does not strand a later real provider reply or tree resume. Provider fixtures support this behavior; live fixed-source runtime and destination proof remain separate.
delegated-configuration
Endpoint activity hides private-task events while retaining a next-page cursor across private-only windows, so older readable history stays reachable. Actual-JWT fixtures verify this separately from live provider delivery.
See the canonical delegated configuration guidance and acceptance evidence.