PaperClipAI/doc/plans/2026-10-13-connection-api-parity.md

Agent API parity for connection configuration

Dated 2026-10-13. Implementation and qualification record for the connection-management change based on e43af9770a36ff92e14cf0e31ee16fa238310f76.

Outcome

A newly created standard agent can administer connections using its existing default grants and its responsible user's authority. The default Operator has the human permissions needed for these operations. API reachability includes app/tool connections, chat/email endpoints, GitHub and Slack setup, AI accounts and pools, profiles, named gateways and gateway clients. Human authentication and trusted-host operations retain their explicit boundaries.

No agent grant backfill is performed. An existing missing or scoped grant remains missing or scoped. An operator can explicitly change those grants through the existing permission-management surface. Agents do not acquire tools:admin by default and cannot edit their own principal permissions or approve their own governed requests.

Authorization contract

server/src/services/connection-management.ts resolves authenticated management context and invokes the existing authorization evaluator. server/src/routes/connection-management-authz.ts resolves route resources and all referenced targets, then supplies that context to services. Capability reporting calls the same evaluator; every mutation checks authority again.

Operation	Agent grant	Responsible-user ceiling
Configure connections, channels and AI accounts	tools:manage_connections	Existing personal/creator authority or connection management
Profiles, assignments and action policies	tools:manage_profiles	Corresponding profile and target-agent authority; changes to connection audience also require connection management
Named gateways and client tokens	tools:manage_connections	tools:admin; bindings also require profile and target authority
Audit	tools:view_audit	Audit and resource visibility
Start/stop runtimes	tools:manage_runtime	Runtime and resource authority
Test actions	tools:use	Credential access, target-agent authority and ordinary tool/action policy

The acting principal, responsible user, credential owner and target agent remain distinct. Personal credentials belong to the responsible human. Activity records identify the actual agent, responsible user, run or API key, resource and authorization reason. API parameters cannot select a responsible user or forge ownership attribution.

Agent keys resolve their saved responsible user. Run JWTs require current run identity and assignment. Both fail closed on absent user context, inactive membership, foreign companies, unavailable personal credentials, invalid scopes or low trust. Connection authorization enforces the human ceiling even when general responsible-user authorization runs in shadow mode. skill_test and task_bridge cannot administer connections. Ask and Plan contexts cannot mutate configuration. Connection/profile/gateway/provider/purpose/operation grant scopes apply to resolved resources, including plural policy selectors and affected targets.

Services recheck management context after asynchronous provider work before sensitive persistence. Existing revisions, transaction locks, credential leases, vault storage, duplicate prevention and cleanup stay authoritative. Reads filter private accounts, referenced profile/pool resources and task activity. Configuration authority is separate from use: authorized policy changes, including self-targeted changes, take effect for subsequent calls. Pending governed action requests remain separate and cannot be self-approved.

Authorized policy administration includes user-requested changes that loosen the acting agent’s own tool controls. These writes remain bounded by management grants, resource scope and the responsible user’s current authority; they do not need an additional approval solely because the agent is a target. Subsequent tool calls obey the resulting policy. Agents cannot approve their own governed action requests or edit their own principal permission grants.

Binding and audience authorization checks field presence, including null, false and empty arrays. Clearing an assignment or reducing an audience remains a profile-management operation after an explicit grant revocation. Gateway binding changes check both the saved and replacement profile/project/task contexts; reauthorization reloads the saved side after asynchronous work. Referenced resources require each applicable connection and profile permission, including the replacement side of a project binding.

Saved authentication and delegation

Generic chat configure/reconnect treats signing/webhook secrets, private keys, client secrets and project secrets as human credential entry. A delegated request returns the saved endpoint's addressed handoff before provider work or vault mutation. Verified provider provisioning can still save provider-selected credentials. Authorized bot-token and API-key entry remains delegated. Generic tool-connection updates cannot replace channel credential references and bypass the provider setup boundary.

Credential-entry intents capture opaque generations for the requested fields. Vault persistence changes a field's generation only when its value changes, and commits those markers plus the active-endpoint verification fence with the new references. Retries preserve the original baseline. Old health, unrelated bot-token repair and unchanged key entry cannot satisfy a replacement request. Changed signing/webhook keys also require renewed webhook verification, and continuation rechecks task and current authority. Credential-entry cards without a completion boundary fail closed; ordinary authentication handoffs are unchanged. Saved credential links open the reconnect form.

Agent setup responses retain their browser fields and add requiredUserAction where a human step is needed. It identifies the addressed user, saved resource, setup destination, reason and continuation. Chat handoffs reuse the saved endpoint and existing connection-intent delivery. AI login handoffs reopen the saved sign-in intent in the existing credential UI. Completion is based on server state; the UI does not ask a human to certify setup success.

Generic app OAuth returns the saved setup destination without creating agent-bound provider state; the human browser starts the existing session-bound authorization flow. Its expiresAt is null until that human step creates an expiring provider session. Slack/GitHub provider callbacks preserve human subject and state checks. Agent-created GitHub setup binds its browser session when the addressed human opens it. Identity callbacks validate the current human and session before consuming state, and revalidate authority before saving identity. Wrong-user callbacks leave the rightful user's flow intact. Continuation rechecks task state and current authority after a yielding run; cancelled tasks and revoked access cannot be revived by a late provider result.

GitHub webhook signing-secret rotation is a human credential step. Agents receive the saved endpoint handoff without rotating or reading the secret; direct delegated service generation is rejected. Human sessions retain the existing rotation and vault persistence path.

Agent-issued durable gateway clients store responsible_user_id alongside created_by_agent_id. Token use reevaluates issuer/user authority, gateway/profile scope, target constraints, credential access and action restrictions. The responsible-user marker remains after deletion clears the issuer foreign key, so an orphaned delegated token fails closed instead of becoming a system client. It does not inherit the lifetime of the setup run. Heartbeat tokens remain bound to their authenticated run. Legacy agent-issued clients without a responsible user fail closed; existing board-issued clients retain their behavior. Migration 0380_broken_aqueduct.sql is additive and idempotent; it does not infer legacy identity or modify agent grants.

Discovery and guidance

OpenAPI carries explicit REST transport and connection-management authorization metadata. JSON authorization initiation and status are callable through default search_api/call_api; OAuth callbacks, redirects, MCP and WebSocket sessions retain their protocols. There is no new administration tool family.

The shared connection guidance is delivered by the runtime prompt, search tools and existing adapter/CLI consumers. It tells agents to distinguish tool/channel/AI purposes, configure what the user requested when authorized, suggest relevant missing connections, reuse saved drafts and hand off only missing decisions, credentials, consent or authority. It prohibits silently relaxing policy after failed execution and distinguishes saved, authenticated, usable and verified states. Native API setup secrets and gateway credentials use protected replay receipts and redacted history.

Operation inventory

The existing maps are the checklist, not a second runtime registry:

Inventory	Coverage
Connection setup	Catalog/method discovery, preflight, drafts, authentication, connection intents and host boundaries
App permissions	Account lifecycle, installations/grants, policy, catalog, action tests and activity
Chat channels	Endpoint/provider setup, settings, defaults, destination access, GitHub/Slack registration and identity, email, tests and lifecycle
Gateways and profiles	Profiles/bindings, gateway configuration, client tokens, runtime controls, protocol and audit
Model accounts	AI discovery, key/login setup, reconnect/defaults, managed agent bindings, pools and lifecycle

The route inventory was reconciled against the production tools, chatEndpoints, email, ai-connections, ai-connection-pools and relevant agents UI API clients. Human-only operations remain individually classified: browser callback/identity confirmation and credential entry, principal approvals, arbitrary local configuration import/host-template authoring, cloud instance enrollment, and manual chat publication/replay that does not run through the governed agent tool path. Approved template use and ordinary authorized remote configuration remain delegable. Catalog/provider availability gates still apply.

Qualification

server/src/__tests__/connection-management.integration.test.ts runs the assembled server, production bearer authentication, real database/vault persistence and deterministic provider responses. It creates each standard agent with an actual human-authenticated POST /companies/:companyId/agents; it provisions the human using normal Operator role defaults. It adds no special agent grants and does not inject req.actor. Only fixture sign-in throttling is disabled. GitHub/Slack/OpenAI/AgentMail responses are fixtures, not live provider proof.

The suite exercises:

• Fresh default app connections, profiles, chat settings, AI account/binding/pool and named gateway/token creation; no default tools:admin grant.
• Actual persistent API keys and run JWTs, native discovery/calls, and delivery of the new built-in guidance.
• Correct human ownership and actual-agent audit attribution, including personal grant delegation and revocation; persisted settings and optimistic revision conflicts.
• Slack configured credentials and test messages under ordinary action policy; repeated request IDs do not resend.
• GitHub app import, repository/verification configuration and real-session identity handoff; wrong-user and replay rejection.
• Saved chat handoff reuse and existing task continuation; late credential promotion after yield, cancellation and user revocation.
• User restrictions with legitimate personal self-service, missing/scoped agent grants, foreign companies/accounts, forged identity, invalid responsible users, bridge keys, low trust and work-mode restrictions.
• Durable gateway use after the setup run finishes, purpose-scoped grants, denial after membership or issuer-grant revocation and in the persisted cleared-issuer state, encrypted native token receipts, redacted history and retry without a second token.

Focused neighboring tests cover existing human routes, callback behavior, provider setup, device/setup-token sign-in, native API policy, secret redaction, saved setup UI and connection-intent behavior. Maps distinguish individually executed fixture operations from source-reviewed operations. Scripted evidence proves reachability and behavior, not an empirical LLM success rate.

Required final checks are node scripts/check-maps.mjs, pnpm -r typecheck, pnpm test:run, pnpm build, database migration validation and UI token gates. The final handoff records their actual results. Live provider setup, a new chatbot skill and redesigned setup workflows are outside this delivery.

Historical validation record (2026-10-13)

• Focused connection, AI hiring, native API and OpenAPI suites: 2,533 passed, including 16 assembled-server acceptance scenarios using production authentication and default agent creation.
• Final fresh-process connection qualification: 618 passed across five suites, including all 18 assembled-server acceptance scenarios, 418 tool-access tests, 87 gateway acceptance tests, 73 authorization tests and 22 decision-model tests. This covers binding/audience revocation, both sides of profile/project scope changes, current membership authority and gateway-token ownership metadata.
• Chat compatibility regression selection: 49 passed (Slack tests, resource auditing, manager boundaries and Teams activity/projections).
• Saved setup UI, canonical guidance and native history redaction: passed in the neighboring focused run; its three outdated API transport/security assertions were corrected and included in the 2,533-test passing run.
• pnpm -r typecheck: passed.
• pnpm build: passed.
• Database migration numbering/safety validation: passed through typecheck/build; existing historical safety findings remain covered by the repository baseline.
• node scripts/check-maps.mjs: passed, 35 areas / 176 capability IDs; structural consistency only.
• UI token gates: passed.
• Broad UI run: 8,210 passed / 5 failed under contention; both failing suites passed serially (82 tests).
• Shared contracts and catalog: 941 passed. Adapter utilities: 1,740 passed / 5 failed under contention; all five failing suites passed serially (217 tests).
• Remaining source-only adapter/plugin projects: 2,087 passed / 1 macOS temporary-path assertion failed; that suite passed with the repository runner’s canonical temporary directory (14 tests).
• Serialized route/auth suites without embedded PostgreSQL: 1,849 passed / 22 failures in two empty-database fixtures; after adding the resource/membership fixture rows, both suites passed (25 tests). Their authentication, isolation and provider-error assertions remain exercised.
• Email address/provider regression suite: 10 passed after supplying resource and membership rows to its old empty-database fixture. HTTP log redaction: 66 passed in a fresh process after a sweep timeout.
• CLI suites without embedded PostgreSQL: 462 passed across 63 files. The three database-backed suites produced 62 passes and three embedded-PostgreSQL initialization failures in worktree.test.ts. The host was at its 32/32 shared-memory segment limit; these worktree tests need additional concurrent clusters. Other chats' databases and system limits were not modified.
• Database package: 194 passed across 50 files.
• Database-backed serialized routes: 1,208 passed / two failed / 73 skipped. Seven suites hit their 20-second database startup limit; the failures were an outdated AI-pool role fixture and a routine test timeout. All affected suites passed fresh-process reruns.
• Final isolated gateway/service/route reruns: 320 passed across 13 suites, including the startup failures, skill cleanup deadlock, AI-pool membership fixture and routine timeout. The stale-lock route suite initially skipped its 14 tests after a failed database availability probe; a final isolated retry executed and passed all 14.
• Final assembled-server acceptance after the gateway scope and orphaned-token fixes: 18 passed. The orphaned-token case models the token foreign key's persisted ON DELETE SET NULL state without deleting protected historical audit references; token use still traverses the real public gateway endpoint.
• Final workspace typecheck/build, migration checks, maps, token gates and git diff --check: passed. The generated migration retains exactly the five newest schema snapshots.
• pnpm test:run: the general server sweep finished with 19,282 passed / 15 failed / 381 skipped across 914 files (898 passed, 10 failed, 6 skipped). Four suites could not start their databases; other failures included two gateway tests loaded against earlier transformed authorization code, outdated role/resource fixtures, a cleanup deadlock, an HTTP timeout and a socket hang-up. All reported server failures and blocked startup suites subsequently passed fresh reruns. Workspace and serialized groups were executed separately after the runner's fail-fast exit. The original sweep is not represented as a clean pass.

As of October 13, qualification was complete for the connection feature and its provider fixtures. The repository-wide test result at that time remained not fully green because the three CLI worktree tests could not initialize their additional PostgreSQL clusters at the host's shared-memory limit. They require rerunning on a host with spare PostgreSQL capacity. Live provider verification remains outside this delivery.

PR qualification (2026-10-26)

The implementation was rebased onto a1f77821b9cd5c9c846fdf7a0fa5cc620ad2b6bb. Connection-service changes were ported into the current extracted modules. The historical checks above describe the October 13 snapshot; fresh PR qualification is recorded separately below.

• Fresh Node 24.22.1 / pnpm 9.15.4 workspace typecheck and build passed. Migration safety, module boundaries, and UI token gates passed.

• Initial embedded-database acceptance could not run: the first install lacked native library links; after package setup, a direct initdb reproduction reported the host semaphore limit (semget: No space left on device). No shared databases or kernel limits were changed. The broad local test attempt is not a clean pass.

• First Linux CI exposed a duplicate user fixture, a lost viewer restriction, a host-template visibility gap, an integration fixture race with production harness verification, and the prompt-bound Copilot identity. These are tracked and fixed separately from the local host limit. Current-head CI remains the completion gate.

• Harness verification uses a deterministic lifecycle driver fixture; agent creation, grant defaults, bearer authentication, authorization, and persistence remain production paths.

• Fresh isolated PostgreSQL 18 qualification: 31 acceptance scenarios passed through the assembled server and actual bearer/session middleware. The database is a task-owned container; no shared service or kernel setting was changed. CI uses its normal embedded database path.

• Review regressions now prove nested finish audience authorization, both management grants, all/current target limits, task/project execution policy, actual actor/run attribution, another authorized target agent, human approval after a successfully yielded run, user/agent revocation, task cancellation, and replay without a second provider call.

• The local MCP fixture initially lacked cached healthy catalog state; the next fixture pass exposed equal policy-priority assumptions and a legitimate closed-task 409. Those fixture expectations were corrected. A reused external test database also caused a Slack identity collision; the passing run used a fresh database. None of those attempts is represented as a passing run.

• Saved setup UI and shared guidance: 278 passed. Native API/OpenAPI regression selection: 2,041 passed. Prompt-bound Copilot identity: 57 passed.

• Further review regressions cover bounded selector expansion before resource reads, duplicate-selector lookup cost, foreign-resource non-disclosure, one run capture per management listing, provider scope on existing and proposed configuration, and grant revocation during remote endpoint validation before persistence. Commit-time checks resolve current saved selectors and affected targets again.

• A one-call rate limit permits the admitted test and denies the next test without a second provider invocation. The final policy check carries the invocation's recorded admission. The first new test assertion used an incorrect response shape; the corrected assertion checks the existing decision/error contract and actual provider call count.

• Current workspace typecheck and production build passed after these changes. The focused Slack retry authorization cases passed (3 tests) after sorting both ID reads. Their first local attempt raced the database package build's migration-directory replacement; after that build completed, normal migrations and all three cases passed.

• The preceding CI head had several runner-shutdown cancellations and a browser strict-locator failure involving duplicate chat replies. The chat integration failure was an unordered ID comparison, corrected above. These failures remain part of the qualification history; only fresh current-head CI can establish the final check result.

• A subsequent route review found a board-only owner helper left behind in the sandbox device-login path. It now uses the shared connection authority while keeping the responsible user as immutable session owner. A focused assembled-server case passed for actual key/JWT reads, cancellation, strict start validation, and another-owner denial. This fixture does not launch a sandbox/provider process; existing login service fixtures cover that contract.

• Map review also corrected unsupported MCP GET handlers (405, POST required), restored private voice/phone consent boundaries and existing chat provenance notes, and distinguished saved device-session HTTP evidence from provider authentication.

• Final assembled-server acceptance after the device-login fix: 32 scenarios passed in a fresh PostgreSQL database.

• Review found that the top-level Apps connect route rejected an aiLogin-only handoff before rendering its saved login panel. The new route-policy test failed before the fix; the route now admits a non-empty saved-login ID, leaving owner/session validation to the existing server and panel. Empty IDs remain rejected. The prior component-only tests did not cover this entry gate.

• Saved-login route policy and Apps connect components: 236 tests passed after the entry fix; the added route-policy case was red before the fix. Token gates and map validation passed.

• Master advanced during PR qualification. The implementation now merges 5823e9a664; its already published Copilot v60 identity is preserved byte-for-byte, and the combined connection guidance is declared as v61. Generated TypeScript/Rust identity checks and all 58 Copilot installation tests passed. These checks do not imply a new live provider qualification.

• Latest authorization qualification: 36 assembled-server scenarios passed. Additional cases cover application-provider spoofing and proposed metadata changes, real agent action approval with its reserved rate slot, distinct subsequent-call denial, concurrent run-authenticated finish/reorder/update operations, issue/routine/gateway binding targets and retained gateway profiles, private GitHub review list/detail filtering, and rate-limited Slack test messages/invitations. Exact action retries retain their saved receipt and do not consume a second provider call.

• Generic caller-labelled application/connection creation cannot establish a provider-scoped grant. Provider-scoped setup uses the catalog operation whose provider the server resolves; default unscoped management remains available. Existing and proposed application metadata are checked independently.

• Authorization runs before profile/policy transaction locks in finish and reorder. The concurrency fixture allows a stale reorder's documented 422 while requiring the other writes to complete without lock-order errors. Approval admission preserves only the recorded unchanged policy generation and does not grant approval or waive current blocks/grants.

• The preceding Linux CI heads passed their browser shards but exposed scheduling flakes in workspace-recovery, environment-cleanup-work, and login-cleanup-work; their actual assertion failures remain recorded separately from the connection qualification. Fresh latest-head CI remains required. Earlier new fixture attempts also used an invalid application type and omitted a profile key; the corrected fixtures use production schemas. A profile already assigned to a gateway is already bound to that gateway's agent and cannot serve as an unrelated positive control.

• Master subsequently advanced to 125ddcabe5. Its published Copilot v61 identity is preserved; the combined prompt is now v62. Generated profile checks and 59 Copilot installation tests passed. Project bindings now enumerate every company agent that could run project work; the focused retained-target case passed with that restriction.

• The previously failing login-cleanup and free-workspace-export scheduling cases both passed in isolated local runs against dedicated PostgreSQL test databases. This does not erase their CI failures or establish their cause.

• Later review found that policy-audience expansion included generic resource selectors and denied otherwise permitted narrow writes. Actual-auth regressions now cover narrow create/update/reorder/delete and denial of broader targets. Deferred Google authorization also persists the addressed user's selected scopes with the saved connection. The browser restores that request only until newer consent is saved. All six service-picker tests passed; the new draft and newer-pending regressions failed before the UI fix. An initial stale-consent fixture used incomplete Drive scopes and was corrected to use the shared canonical selection.

• The complete acceptance suite now passes 38 scenarios against a fresh isolated PostgreSQL database, including both new review regressions. Provider setup remains fixture evidence, not live-provider qualification.

• An outside-diff review finding exposed AI collection projections that checked only the responsible user's account access. Both returned accounts and selectable pools now pass the shared agent resource evaluator; pool checks include every member. The new actual-key/JWT regression failed before the fix and passed after it. The full acceptance suite then passed 39 scenarios in a fresh isolated database.

• Both PRs' complete GitHub Actions workflows passed at implementation 9aa8fbe34a and companion 6f2a14d2d7; both received current-head Greptile 5/5 reviews. The companion also received Paperclip 5/5. The implementation's Paperclip reviewer is held by a prior execution_finalization_deadline_exceeded recovery boundary, which requires stopped-provider and uncertain-action reconciliation; an ordinary retry did not clear it.

• The separate Entire gate requires linked Changes and independent approval with self-approval disabled. Both existing branches were linked through its supported API. Its base-freshness requirement also required merging master a67a18c171 into the implementation and then into the companion. This merge carries upstream task-history UI fixes; fresh current-head CI is required again. No review or gate settings were weakened.

• A subsequent profile review found that saved application/catalog selectors did not resolve their underlying connections. Authorization now covers every supported selector, the application scope used by new-tool review, empty managed installation profiles, proposed broad entries, and effective-profile tools/installations. The new actual-key/JWT regression failed before the fix and also exposed the empty managed-profile label; the corrected shared evaluator protects both. All 40 assembled-server scenarios passed afterward in a fresh database, and server typecheck/module boundaries passed. Host-template map entries now explicitly name their board-user and tools:admin requirements; MCP import preview retains its separate board/company boundary.

• Effective-profile projection now authorizes each distinct returned connection once across tools and installations. The new 200-tool regression measured 201 checks before the fix and one afterward, preserving all returned tools and privacy denials. The complete assembled-server suite then passed 41 scenarios in a fresh database. AI pool writes explicitly document both management grants; AI setup and profile mutation entries document their conditional grants.

• A security regression confirmed that delegated setup-secret requests returned the GitHub webhook signing key. Agents now receive a saved human handoff, and the provider service rejects delegated secret generation. Actual key/JWT requests preserve credential refs, while a human session can still rotate them. The regression failed before the fix; all 41 scenarios passed afterward in a fresh database, and server typecheck passed.

• CI on implementation 271740cc19 failed a browser shard when run cancellation hit a database lock timeout. Companion 4ad17e94d2 failed the Runner static suite when its real Claude descriptor fixture reported an unverified surviving process group; that exact test passed in an isolated local run. Both failures remain recorded; fresh current-head CI is required after the security fix.

• The OpenAPI setup-secret response now distinguishes the agent credential-entry handoff (200) from human-only secret generation (201). All 27 OpenAPI contract tests passed, the focused actual-auth GitHub flow passed, and server typecheck passed after this contract update.

• The maintainer confirmed authorized policy administration, including self-targeted changes. The new actual-auth scenario changes an agent’s own Ask-first rule through an authorized policy write, proves the next call follows the new policy, preserves self-approval denial, and rejects further policy writes after grant revocation. All 42 assembled-server scenarios passed in fresh PostgreSQL databases.

• Existing-App import now hands off to the human credential screen; agents cannot persist a caller-chosen signing key. Rotation requests record a separate saved objective and do not complete from old connection health. The rotation generation and cleared webhook verification commit atomically with new vault references; completion requires a newer generation and restored verified health. The regression was red before the fix. No best-effort audit or clock comparison establishes completion.

• Saved import and rotation links open the matching credential screen. The rotation pane exposes a one-time copy action, waits for explicit human generation, and preserves retry behavior through generation/reconnect failures. Both new UI regressions were red before the fix; all 35 GitHub wizard tests passed, and token gates passed. The provider verification state in the assembled-server test is a deterministic fixture; live GitHub rotation remains unqualified.

• Implementation 35585448ef hit a 30-second module-load hook timeout in company-skills-routes; that suite passed in a focused local run. The combined route/contract selection passed 90 tests, followed by all 27 OpenAPI contract tests after the final server contract update. The companion’s previous complete CI was green at d84538f8a3. Fresh CI on the credential-handoff changes remains required. Entire was removed from the expected gates by the maintainer and is no longer a completion dependency.

• Final review found that the rotation UI tied reconnect to the one-time plaintext. Saved links now bind an opaque, nonsecret generation baseline, and the endpoint projection exposes only the committed generation ID. Reloading resumes that rotation without generating another secret; an unchanged generation remains blocked. Both new resume cases were red before the UI fix. All 38 GitHub wizard tests and 69 API/OpenAPI tests passed; token gates passed. Prior full CI passed at implementation f99e8aa6d5 and companion e22d2a0eba; their final successor checks must complete independently.

• Current-head review found an AgentMail collection scope leak and agent-keyed Arcade discovery ownership. Both new actual-auth regressions were red before the fixes. Email accounts now pass the shared resource evaluator before metadata or credential discovery; aggregator settings, credentials, inventory, and sync leases use the responsible user, while audit and secret-access records preserve the actual agent. The Arcade fixture initially created a draft and omitted provider authorization metadata; it was corrected to represent an active provider account. Its guarded HTTP transport also required an explicit deterministic fixture; a prior real transport attempt returned 401. No provider authentication was weakened.

• A reused test database retained a Slack bot identity and caused a 409 during the full suite. In a fresh PostgreSQL database, all 70 API/OpenAPI tests passed, including 43 assembled-server cases and binding the human-only secret response to its committed nonsecret generation. Server typecheck passed. Earlier fixture and contract-update failures remain accounted for here.

• Failed GitHub secret replacements retain the prior copy only after its committed generation is confirmed unchanged. A changed or unreadable generation blocks copying and reconnecting; an explicit status check can restore the earlier copy when the server confirms it. All three new replacement cases were red before the fix; all 82 GitHub UI tests passed afterward. Cloud enrollment map entries now name instance-admin creation/callback checks and distinguish the HTML/303 browser return. Maps and UI token gates passed. Fresh successor CI and reviews remain required before merging.

• Master advanced to c7c12dbc79 while the review fixes were being qualified. Its published Copilot v62 identity is preserved byte-for-byte. The combined delegated connection guidance uses v63 with digest sha256:f29dc04c3217ad74aeaf96b2c466d5a1dc6c55942f5bd4db9c1cf52f2985d19e; the shared identity generator and 60 Copilot installation tests passed. The first root-level invocation selected no Runner tests; the package configuration ran the intended suite. Migration 0379 is unchanged by this merge.

• A later security review found that activity reads authorized the entire endpoint conversation history before applying the activity limit. The real run-JWT regression measured 200 checks before the fix and one afterward for the same one-item page. The query now selects only conversations referenced by the bounded activity candidates, deduplicates issue decisions, and reuses the request's run read context. The focused regression is green; a fresh complete suite and current-head CI remain required.

2026-10-26: test authority and saved Google consent review fixes

• The exact-head review of 69bf11aef9 found private task results readable through test status and cross-agent test execution without the caller's connection access. Both initial actual-auth regressions failed in /tmp/parity-test-boundaries-red.log. Implementation 70b7c973c8 passes the authenticated actor into status reads, rechecks task authorization plus agent/responsible-user privacy, and binds agent reads to their originating principal.
• Cross-agent tests require a matching caller profile and the same credential identity, intersect caller and target action policies, and recheck both before execution including approved continuation. The ordinary human approval covers either Ask first policy; self-approval stays denied. Caller-only and shared rate admissions persist without charging one shared bucket twice.
• Intermediate focused runs exposed an expectation mismatch (normal policy denial returns Off), the need to check profile membership independently of broad tools:use, and result classification attempting to capture a target agent with the caller's run. The final implementation preserves the actual run identity while retaining the separate test target. Diagnostic failures remain in /tmp/parity-test-boundaries-green.log, /tmp/parity-test-boundaries-green-2.log, and /tmp/parity-test-cross-agent-diagnostic.log; they are superseded by the 16-case passing focused run /tmp/parity-test-boundaries-green-3.log.
• 78 API/OpenAPI tests passed in fresh PostgreSQL (parity_review_31): 51 assembled-server actual-auth scenarios and 27 API contracts. Log: /tmp/parity-test-final-full.log. Final server typecheck/build and map validation passed (/tmp/parity-test-final-types.log, /tmp/parity-test-final-build.log, /tmp/parity-test-final-maps.log). These replace the earlier 71-test snapshot; no full local test-sweep pass is claimed.
• Companion review also found that token refresh advances grant.updatedAt and can erase a saved pending Google service selection. Both new component cases failed before the fix (/tmp/parity-google-refresh-ui-red.log). Successful direct/cloud consent now records additive providerTenant.oauth.consentedAt metadata; refresh preserves it. The picker compares the pending request against that consent timestamp, using grant creation for legacy metadata rather than treating refresh as new consent.
• 10 focused Google/OAuth tests passed: eight service-picker cases (including newer/older consent and refresh/legacy behavior) plus two real local-HTTP OAuth protocol cases proving that successful consent is timestamped and concurrent token refresh preserves it. Log: /tmp/parity-google-refresh-green.log. The protocol fixture uses its existing board actor injection and does not count as actual-auth agent evidence. JSON metadata is additive; normal migration generation validates that no SQL change is required.

2026-10-26: preserve policy and explicit-grant tool access

The review of 70b7c973c8 correctly identified that requiring a caller profile rejects legitimate access through an allow policy or explicit scoped tools:use grant. Both actual run-JWT cases failed before the correction (/tmp/parity-caller-grants-red.log). The caller's full access decision remains intersected with the target's decision; the narrower profile-only precondition is removed. The negative case now uses a caller-specific Block policy with the target still permitted, proving that another target cannot bypass the caller's actual action restriction. Default broad tools:use remains governed by the ordinary evaluator rather than being reinterpreted by this API.

A further real-JWT regression found that the authKind: none shortcut could skip comparison of dedicated grant identities (/tmp/parity-credential-kind-red.log). Credential identity comparison now applies for every auth label. Both API-key and no-auth-labelled dedicated grants deny before provider invocation when their identities differ. The same responsible-user and target authority, approval, revocation, and rate checks remain in force.

Implementation 52a87697f0 passed 81 API/OpenAPI tests (54 assembled-server actual-auth scenarios plus 27 contracts) in fresh PostgreSQL parity_review_33, log /tmp/parity-caller-grants-full-green.log. The earlier profile-only version is superseded by this evidence; its failures and recovery remain above. Final server typecheck and build passed (/tmp/parity-caller-grants-final-types.log, /tmp/parity-caller-grants-final-build.log). The earlier 18-case focused run passed before adding the no-auth-label regression (/tmp/parity-caller-grants-green.log); the final full suite includes all 19 delegated-test cases. Google consent, GitHub UI, and Copilot code are unchanged by this correction.

2026-10-26: bounded tool-connection activity authorization

Security review found that tool-connection activity repeated a full run capture per returned event, unlike the already corrected chat activity path. The actual run-JWT regression over 100 persisted events (half linked to an inaccessible private task) measured 100 capability decisions and 102 run captures before the fix and failed (/tmp/parity-tool-activity-red.log).

Implementation e5b8070d2f creates one management evaluator, shares decisions by task within the bounded page, and passes the current request's read context into each probe. The passing regression proves two capability decisions and at most two run captures, the same 50 visible events, no private event content, and a fresh 403 after revoking audit permission (/tmp/parity-tool-activity-green.log). No authority is cached across requests.

82 API/OpenAPI tests passed in fresh PostgreSQL parity_review_35: 55 assembled-server actual-auth scenarios and 27 contracts (/tmp/parity-tool-activity-full-green.log). Server typecheck/build passed (/tmp/parity-tool-activity-types.log, /tmp/parity-tool-activity-build.log). The earlier red result is retained as the baseline; no full local sweep, live provider verification, or empirical model success claim is added.

2026-10-26: delegated verification-key entry and CI rate assertions

Security review found that generic Slack reconnect accepted an agent-chosen signing key while verification reused the saved bot token. A clean actual-key regression reproduced HTTP 200 instead of a human handoff (/tmp/parity-chat-signing-red-fresh.log). Source review exposed a second path: actual-JWT generic tool-connection PATCH accepted a replacement signing-key secret reference (/tmp/parity-chat-binding-red.log). Both paths are now guarded before persistence. Configure/reconnect returns the saved addressed credential-entry handoff; the generic credential-reference update fails with 403. Tests confirm unchanged refs and the original vaulted signing value, human-session setup, permitted agent bot-token repair, and normal policy/rate checks on test messages.

The first diagnostic used configure on an already configured endpoint and returned the expected lifecycle 409 rather than exercising reconnect (/tmp/parity-chat-signing-red.log). Reusing that database then hit the known Slack identity fixture collision (/tmp/parity-chat-signing-red-reconnect.log). Fresh databases established the two security baselines above. The first full post-fix run passed all 55 authenticated cases but failed an OpenAPI assertion that expected anyOf instead of the emitted oneOf (/tmp/parity-chat-signing-full-green.log). The final clean PostgreSQL parity_review_41 run passed all 82 API/OpenAPI tests (/tmp/parity-chat-signing-final-full.log). Eight focused native receipt protections also passed in /tmp/parity-chat-signing-green.log. Server typecheck/build passed (/tmp/parity-chat-signing-types.log, /tmp/parity-chat-signing-build.log). No live provider claim is added.

Linux CI run 40415124314 failed two existing rate-admission assertions because persisted admissions now also record the bucket identity used by paired caller/target checks (/tmp/parity-e5-linux-failure.log). The local baseline reproduced both failures (/tmp/parity-rate-bucket-red.log). Updating the expected shape first used the wrong fixture field (/tmp/parity-rate-bucket-green.log); using the actual actor identity then passed all 49 policy service tests (/tmp/parity-rate-bucket-final-green.log). No production rate behavior changed for this correction. The companion preserves the catalog creator-attribution follow-up so the implementation review stays at 99 changed files. Both PRs must ship together. Fresh current-head Linux CI and reviews remain required; no full local test-sweep pass is claimed.

2026-10-26: credential-entry completion and in-flight revocation

The c8cc70ae30 review correctly found that an already active, healthy endpoint could satisfy the new credential-entry card without human entry. The actual-JWT Slack baseline failed with an available connection instead of null (/tmp/parity-credential-completion-red.log). Implementation 805d165bc3 persists opaque per-field generations only for changed protected values, fences old active state in the vault-reference transaction, saves the requested field baseline, and preserves it on retries. Completion requires the requested change, active healthy state, renewed signing verification when applicable, and current task/user/agent authority. No secret or value-derived hash is added to the intent.

The expanded journey proves pending state before human entry, after unrelated bot-token repair, after re-entering the old signing key, after changed entry without verification, and across retries with the original baseline. New verification allows normal continuation; cancellation or responsible-user suspension still denies it. A later fixture assertion initially lost the hidden generation by copying the redacted API setup back into the database (/tmp/parity-credential-completion-final.log). The fixture now preserves the persisted setup. Two focused cases and four neighboring real-database Slack/GitHub provisioning, reconnect, rotation and concurrency cases passed (/tmp/parity-credential-completion-green.log, /tmp/parity-credential-completion-neighbors.log).

An added actual-auth race then suspended the responsible user inside provider authentication. The request returned 403 but had replaced refs (/tmp/parity-credential-commit-revocation-red.log). Configuration now reauthorizes before persistence and inside the reference transaction, so revocation leaves the original refs intact. Final 82 API/OpenAPI tests passed in fresh PostgreSQL parity_review_48 (/tmp/parity-credential-completion-qualified.log), and final server typecheck/build passed (/tmp/parity-credential-completion-commit-types.log, /tmp/parity-credential-completion-commit-build.log).

The preceding full run had one unrelated rate assertion fail as two calls crossed a minute boundary (/tmp/parity-credential-completion-final-green.log). The fixture database recorded consumed counters at 23:35 and 23:36 for the same policy and bucket (/tmp/parity-credential-completion-rate-window-evidence.log). Rate cases now freeze only Date; transport and asynchronous timers remain real. No production rate behavior changed. The final run above includes all rate cases. Companion Slack authorization/installation map entries now explicitly describe the required addressed-human browser-session and consent step; those individual operations retain source-only evidence. Fresh current-head CI and reviews remain required.

2026-10-26: unavailable credential repair and distinct fresh handoffs

The exact 805d165bc3 review found three valid regressions. The actual-auth Slack/GitHub baseline reproduced all three in /tmp/parity-repair-handoffs-red.log: complete human replacements failed for disabled, deleted and unreadable old signing secrets; a fresh GitHub draft received reconnect=1; and a subsequent private-key-only request collided with the broader import request's idempotency key. The red Slack run also reached a consequential test-message failure because the unrepaired corrupt secret remained bound. That is retained as a consequence of failed repair, not a separate provider outage.

Implementation f70c1a05a3 compares each old protected reference separately. Known unavailable secret/version states and typed provider-client failures count as changed; unexpected errors and company/scope failures still propagate before reference writes. The actual human session repairs all three real persisted secret states. A controlled unexpected resolver fault returns 500 and leaves refs unchanged; this is fault-injected resolver evidence, not a reproduced database outage. Opaque generation and verification requirements remain unchanged.

Saved credential links now use reconnect only for a configured endpoint; fresh GitHub imports retain their webhook-secret form. Idempotency keys include the canonical protected field set and completion mode; matching retries retain their interaction and original generation baseline. The actual run-JWT GitHub journey proves separate broad/private-key handoffs, retry reuse and continued human import. The companion wizard test also submits the fresh saved form and verifies App import rather than reconnect.

Both focused journeys passed (/tmp/parity-repair-handoffs-green.log). All 55 actual-auth integration scenarios then passed in fresh PostgreSQL parity_review_51 (/tmp/parity-repair-handoffs-full.log). That invocation accidentally named a nonexistent OpenAPI test file, so its reported pass covered only the integration module. The correctly named OpenAPI route suite ran separately and all 27 contracts passed (/tmp/parity-repair-handoffs-openapi.log): 82 tests across the two commands. Server typecheck/build passed (/tmp/parity-repair-handoffs-types.log, /tmp/parity-repair-handoffs-build.log). All 41 GitHub wizard component cases and UI typecheck passed (/tmp/parity-repair-handoffs-ui.log, /tmp/parity-repair-handoffs-ui-types.log). Maps and token gates passed (/tmp/parity-repair-handoffs-maps.log, /tmp/parity-repair-handoffs-tokens.log). Fresh current-head CI and reviews remain required; no live provider or full local sweep claim is added.

2026-10-27: configured GitHub entry and provisioned Slack verification

The exact bf760912fa companion review found that configured GitHub credential-entry links opened a saved-credential repair screen with no webhook-secret input. Two component regressions failed before the fix (/tmp/parity-configured-entry-ui-red.log). The saved form now displays the requested supported fields, submits only nonempty requested values through reconnect, and keeps stored credentials for the remaining fields. It supports private-key, webhook-secret and client-secret entry, all/any completion modes, and legacy links without field metadata. Rotation retains its separate generation/reconciliation flow. All 46 wizard cases, UI typecheck, UI build and token gates passed (/tmp/parity-configured-entry-ui-qualified.log, /tmp/parity-configured-entry-ui-types.log, /tmp/parity-configured-entry-ui-build.log, /tmp/parity-configured-entry-tokens.log).

The API baseline also showed missing field/completion metadata on the immediate and persisted-intent links, and rejected configured GitHub webhook replacement with 422 (/tmp/parity-configured-entry-api-red.log). Implementation 9ee6f19c3c includes canonical credential field names and completion mode in both links. Additional GitHub verification keys are accepted only for reconnect and still require human entry; agents receive the addressed handoff before provider work or vault writes. The actual run-JWT/human-session journey proves that webhook-only entry preserves the private key and client secret, clears old verification, and completes only after new webhook verification and current authority. The first focused corrected run passed (/tmp/parity-configured-entry-api-green.log). An intermediate full suite passed 82 tests before narrowing the extension to reconnect (/tmp/parity-configured-entry-full.log).

Compatibility review retained GitHub's existing initial-setup secret restriction. The first diagnostic used an unmigrated external database and failed on the absent companies table (/tmp/parity-configured-entry-initial-boundary-red.log); that harness requires the repository's normal migration workflow before use. A migrated run then exposed the overly broad initial variant as HTTP500 instead of the existing422, and reproduced the separate Linux Slack failure (/tmp/parity-configured-entry-neighbors-red.log). The final credential-key extension is reconnect-only; the existing first-setup restriction remains unchanged.

Companion Linux CI run40423570884, chat2/3, failed automatic Slack provisioning because runtime credential persistence erased the earlier signed manifest-update challenge (/tmp/parity-bf760-chat-ci-failure.log). The migrated local regression reproduced the same missing verification timestamp. A provider-owned helper now preserves proof only when the current signing fingerprint and observed callback URL match those exact credentials. The generic vault transaction reads and locks the current setup before deciding whether verification survives; other changed keys retain the verification fence. This is service/provider-fixture evidence, separate from actual-agent authentication coverage. All eight existing compatibility cases passed, including automatic Slack challenge preservation, initial GitHub secret rejection, failed manifest-update recovery, reconnect, rotation and concurrency (/tmp/parity-configured-entry-neighbors-green.log).

Final 82 API/OpenAPI tests passed in fresh PostgreSQL parity_review_56 (/tmp/parity-configured-entry-final-full.log), with final server typecheck/build (/tmp/parity-configured-entry-final-types.log, /tmp/parity-configured-entry-final-build.log). The Vercel personal-credential attribution follow-up is preserved in the companion with its other consent/ownership follow-ups so the implementation remains at 99 files after adding the provider-owned helper. Both PRs must ship together, and that file must be retained in post-squash replay. No broad local sweep or live provider pass is claimed. Fresh exact-head CI and reviews remain required.

2026-10-27: upstream migration reconciliation

Master advanced to baec3abd67 and took migration0379 for project Git authorization. The only merge conflicts were the generated379 snapshot and journal. Upstream 0379_white_giant_girl.sql and its complete journal/snapshot were retained; normal pnpm db:generate regenerated the additive gateway-token column as 0380_broken_aqueduct.sql and pruned snapshots to the newest five. Its ADD COLUMN IF NOT EXISTS also succeeded on two repeated applications to the already migrated fixture database (/tmp/parity-0380-idempotence.log). Migration numbering/safety checks passed (/tmp/parity-configured-entry-0380-validation.log); no legacy identity or agent grant is backfilled. The earlier379 names above remain historical evidence for prior revisions.

The merged implementation passed workspace pnpm -r typecheck and pnpm build (/tmp/parity-0380-types.log, /tmp/parity-0380-build.log) and all82 actual-auth/OpenAPI cases in fresh PostgreSQL parity_review_58 (/tmp/parity-0380-final-api.log). The published Copilotv62 fixture is byte-for-byte equal to upstream; guidancev63 is unchanged. The combined companion passed 128 tests (55 actual-auth scenarios, 27 OpenAPI contracts and 46 GitHub wizard cases) in fresh PostgreSQL parity_review_59 (/tmp/parity-0380-stack-tests.log), workspace typecheck/build (/tmp/parity-0380-stack-types.log, /tmp/parity-0380-stack-build.log), maps and token gates (/tmp/parity-0380-maps.log, /tmp/parity-0380-tokens.log). Eight Google UI cases passed in /tmp/parity-0380-google-oauth.log; its two local-HTTP OAuth cases could not start embedded PostgreSQL and were skipped after suite initialization failed. This fresh attempt does not count as a protocol pass; the earlier ten-case evidence remains historical and fresh Linux CI must run the protocol cases. No full local test-sweep pass is claimed. Full Linux CI and current-head reviews remain required.

2026-10-27: gateway issuer policy, private activity pagination and native setup receipts

The exact e7aba614fb review reproduced two gaps. Agent-issued gateway clients selecting another agent checked only that target's tool policy. Four actual-key gateway cases were red for issuer Block, Ask first, post-request Block and rate policy (/tmp/parity-gateway-issuer-red-qualified.log); the initial underscore-name fixture mismatch in /tmp/parity-gateway-issuer-red.log was diagnostic and did not prove the bypass. Private-only activity windows also ended pagination early (/tmp/parity-private-pagination-red.log).

Gateway sessions now retain their actual issuing agent independently from the target. Every tool decision intersects the existing policy evaluator's issuer and target decisions; either Block or Ask first governs the call. Separate admissions are persisted, common rate buckets consume one slot, and approved continuation rechecks current token scope, issuer/user authority, both policies and credential identity before provider dispatch. Durable invocation rows retain the token ID and a server-authored issuer marker, including fail-closed behavior when the token is deleted. A red approval recheck exposed that recordInvocation previously dropped gatewayTokenId (/tmp/parity-gateway-issuer-green.log, /tmp/parity-gateway-issuer-approval-diagnostic.log); persisting that attribution closed the continuation bypass. Board-issued tokens retain their existing behavior; heartbeat tokens remain independently run-bound.

The expanded gateway journey covers 13 cases: issuer/target Block, ordinary and rate-bounded Ask first, current policy/grant/token revocation after requesting approval, token deletion and narrowed action scope, independent/shared rates, credential identity and board-issued approval compatibility. Twelve cases passed before adding the board compatibility/attribution checks (/tmp/parity-gateway-issuer-qualified.log). The board baseline failed when incorrectly treated as delegated authority (/tmp/parity-gateway-board-compat-red.log), and the intermediate attribution assertions failed while requestedByAgentId still named the target (/tmp/parity-gateway-issuer-board-qualified.log). Correct attribution then exposed five review-context mismatches (/tmp/parity-gateway-pagination-final-full.log). The review transaction now checks the acting principal; a 96-case actual-auth/OpenAPI run passed afterward (/tmp/parity-gateway-pagination-qualified.log). The existing gateway suite subsequently exposed implicit legacy session actors being compared without the policy evaluator's normalization: four failures and two consequential unhandled rejections (/tmp/parity-gateway-pagination-neighbors-final.log). Approval session checks now use that canonical actor normalization.

Activity cursors advance across a bounded examined window even when no rows are visible. The actual-JWT regression traverses 27 private events to reach three older readable events, including tied timestamps, without exposing private event details or scanning all history. The existing page-bounded authorization regression remains green (/tmp/parity-private-pagination-green.log).

Superagent then found local subscription checks returning device URL/code into ordinary native mutation receipts. A production-native call_api regression reproduced the unencrypted receipt (/tmp/parity-local-check-receipt-red.log). Local check and test-call responses now use the existing sensitive-response path; the real-auth local-login fixture verifies encrypted persistence, exact replay, redacted history and no response asset. Only the browser process is a deterministic fixture; production routes, native bindings, authentication and database persistence remain real. No ambient CLI credentials or provider consent is used.

The final combined API/native run passed 2,119 tests: 70 assembled-server actual-auth scenarios, 27 OpenAPI contracts and 2,022 native API tests (/tmp/parity-gateway-pagination-receipts-qualified.log). Server typecheck/build passed (/tmp/parity-gateway-pagination-receipts-types.log, /tmp/parity-gateway-pagination-receipts-build.log). Focused existing acceptance suites use separate migrated disposable PostgreSQL URLs through test-only PAPERCLIP_TOOL_GATEWAY_TEST_DATABASE_URL and PAPERCLIP_TOOL_POLICY_TEST_DATABASE_URL; normal Linux embedded execution remains unchanged. All 141 existing gateway/policy tests passed after the canonical-actor correction (92 gateway and 49 policy-service cases, /tmp/parity-gateway-pagination-neighbors-qualified.log). The Vercel OAuth callback ownership follow-up travels with the companion's existing Vercel credential ownership changes to keep the implementation below 100 files. Fresh exact-head Linux CI and reviews remain required; no broad local sweep, live provider setup or empirical LLM success rate is claimed.

The fresh workspace typecheck initially stopped at the migration checker because the sandbox denied tsx its local IPC pipe (EPERM, /tmp/parity-gateway-pagination-stack-types.log); this is a local execution-permission failure, not a migration or TypeScript failure. The authorized rerun and final stack checks are recorded separately.

Final preserved-stack verification passed 2,165 tests (70 actual-auth integration scenarios, 27 OpenAPI contracts, 2,022 native API tests and 46 saved GitHub wizard cases) in fresh PostgreSQL parity_review_73 (/tmp/parity-gateway-pagination-stack-qualified.log). Workspace pnpm -r typecheck passed with local IPC enabled (/tmp/parity-gateway-pagination-stack-types-qualified.log), as did pnpm build, maps and UI token gates (/tmp/parity-gateway-pagination-stack-build.log, -maps.log, -tokens.log). The earlier IPC failure remains documented above. These focused suites do not replace the full Linux CI matrix or establish a full local pnpm test:run sweep.

Master refresh and published profile preservation (2026-10-27)

Master advanced to ea727dc3c2 after the preceding exact-head Linux CI workflows passed. The implementation now includes it in f9e9661a11342dff41a07603c6d28f90d9d35768; its diff stays at99files. The conflicts were the Copilot manifest, TypeScript/Rust generated admission, installation regression and v63 attestation. Published upstream v62 and v63 fixtures remain byte-for-byte unchanged. The combined delegated guidance now uses v64 with digest sha256:22e31f95ef972bcead98a4a707c9f33433558fd111e390e027a2bbb4346e112a. The earlier guidance-v63 digest above is historical. Current master GitHub replay and chat continuation repairs are retained.

The existing installation source-identity assertion failed against unchanged published v63 because the delegated runtime guidance source differed (/tmp/parity-ea727-profile-preservation-red.log:59pass,1fail). The normal identity generator produced the new v64 attestation and shared TypeScript/Rust data; its check and all61installation cases pass (/tmp/parity-ea727-profile-green.log). The added case pins published v63 bytes and rejects its historical identity for current launch.

The refreshed implementation passed all97 actual-auth/OpenAPI cases (70+27, /tmp/parity-ea727-auth-contracts.log), all141gateway/policy cases (/tmp/parity-ea727-neighbors-qualified.log), workspace typecheck and build (/tmp/parity-ea727-typecheck.log, /tmp/parity-ea727-build.log). Test setup initially found an occupied fixed localhost port; Docker then assigned a fresh localhost port. The first neighbor-suite migration command could not resolve the root tsx package and ran against an uninitialized fixture schema; those setup failures are retained in /tmp/parity-ea727-neighbors-migrate.log and /tmp/parity-ea727-neighbors.log. Using the built database package initialized the separate disposable test database and the unchanged141cases passed. No schema guard, assertion, policy or provider receipt was weakened. The fixture container was stopped and removed after verification. Full local test-sweep success is not claimed; fresh exact-head Linux CI and reviews are required after both pushes.

The companion merge preserves both upstream chat-recovery recipes and the delegated configuration/voice access entries. All38own companion files and their complete patch were backed up before refreshing the stack. Consent/catalog/Vercel credential ownership and callback, UI and docs remain part of this companion.

The refreshed combined stack passed all341cases in the five affected connection intent, Google Workspace, AppsConnect, policy and GitHub setup UI suites (/tmp/parity-ea727-stack-ui.log). Workspace typecheck/build, map structure and token gates also pass on the preserved combined source (/tmp/parity-ea727-stack-typecheck.log, /tmp/parity-ea727-stack-build.log, /tmp/parity-ea727-maps.log, /tmp/parity-ea727-tokens.log). No fresh local OAuth protocol pass or live provider acceptance is claimed by those UI/static results; fresh Linux CI must qualify this successor head.

Slack caller policy and human identity handoff completion (2026-10-27)

Greptile's review of f9e9661a11 found two valid gaps. Slack test sends selected only the endpoint's assigned agent for tool policy, so a blocked caller could use another allowed agent's endpoint. A confirm_identity card also treated healthy App credentials as sufficient without a current link for its addressed human. Actual bearer-authenticated regression cases reproduced both linked-account messages and identity invitations sending under a caller Block, and a healthy unconfirmed GitHub handoff satisfying early (/tmp/parity-slack-identity-qualified-red.log: three failing tests). The first diagnostic reused one bot token across endpoint fixtures and correctly hit the existing credential-identity conflict; assigning unique fixture tokens/workspaces exposed the invitation bypass without changing the guard (/tmp/parity-slack-identity-red.log).

Implementation 2ecd6451d0 evaluates both caller and target with the existing tool-policy service, preserves actual-caller audit attribution, denies either Block or Ask first decision before dispatch, applies independent rates and shares only identical versioned rate buckets. Identity handoffs require a linked identity for the exact company, endpoint, addressed user, provider and provider account, in addition to the existing health and current-management checks. The existing human GitHub OAuth journey now proves that the callback alone is insufficient and explicit human confirmation unlocks the identity requirement. Missing, pending, revoked, expired, wrong-user and wrong-account links leave the handoff blocked. A worker sweep with no link leaves the card pending and creates no continuation delivery.

The focused run passed four test cases, including twelve Slack caller/target/recipient combinations (/tmp/parity-slack-identity-qualified-green.log). The intermediate repaired-code run failed only the new audit assertion's incorrect top-level agentId projection; the legacy audit stores it in details.agentId, which the corrected assertion now verifies (/tmp/parity-slack-identity-green.log). A fresh PostgreSQL database then passed all 99 API/OpenAPI tests (72 actual-auth scenarios and27 contracts) in /tmp/parity-slack-identity-suite.log. The same command selected the existing continuation suite, but its50cases were skipped because embedded PostgreSQL could not start on this host; they are not claimed as passing and remain a fresh Linux CI obligation. Actual-auth fixtures exercise the changed identity finder and sweep against disposable real PostgreSQL. Workspace typecheck and build passed (/tmp/parity-slack-identity-typecheck.log, /tmp/parity-slack-identity-build.log). No full local sweep or live provider consent is claimed. All38companion files and their patch were backed up under /tmp/parity-pre-slack-identity/ before carrying these parent repairs into the companion.

The preserved combined companion source also passes the four focused real-auth Slack/GitHub/continuation tests in another fresh PostgreSQL database (/tmp/parity-slack-identity-stack-qualified.log), workspace typecheck/build (/tmp/parity-slack-identity-stack-typecheck.log, /tmp/parity-slack-identity-stack-build.log) and map validation (/tmp/parity-slack-identity-maps.log). All38own files remain;35retain identical bytes and only the two chat maps and this qualification record add evidence. The addressed findings PRRT_kwDORclPyM6wijEE and PRRT_kwDORclPyM6wijEG have evidence replies4384927765 and4384927895 and are resolved. Fresh exact-head CI and all reviewer gates are still required; resolving threads does not supply a new Greptile score or external assessment.