Commit Graph
5182 Commits
Author SHA1 Message Date
DottaandPaperclip ea6c8eb5e1 fix: preserve fresh Kubernetes defaults and retire failed setup preparation
Keep unresolved Kubernetes targets on legacy execution and remove only owned pre-handoff staging roots.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 17:19:19 -05:00
DottaandPaperclip 1173a859ba Merge master and preserve the repository lockfile policy
Retain both runner and incoming creator/render controls; preserve generated build-lock evidence separately.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 17:08:57 -05:00
e0f30a4c71 feat(apps): collapse provider connections behind an "N connections" toggle (#16097)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - The Apps page shows one card for each provider. Each card lists the
connections for that provider.
> - Some providers have many connections. For example, a team can have
five OpenAI accounts.
> - Each connection uses a full row. Thus, the page becomes long and
cluttered.
> - This pull request puts the connection list behind a "N connections"
row with a chevron. The user clicks the row to show or hide the list.
> - The benefit is a shorter Apps page. Connections that need action
stay visible.

## Linked Issues or Issue Description

**Subsystem affected**
UI: the Apps page (`ui/src/pages/apps/Browse.tsx`), the `ConnectorCard`
component.

**Problem or motivation**
A provider card shows every connection as a full row. When a provider
has many accounts, the card is very tall. The page is hard to scan.

**Proposed solution**
When a card has two or more connections, show a "N connections" row with
a chevron below the card header. A click on the row opens or closes the
list. The list is closed when all connections are healthy. The list is
open when a connection needs attention or setup. The row also shows the
count, for example "· 1 needs attention". The list is open while a
search is active. A card with one connection does not show the row.

**Alternatives considered**
- Always show the list. This is the current behavior, and it causes the
clutter.
- Show the toggle for one connection too. This adds a click and gives no
benefit.
- Always close the list. This can hide an account that needs
reconnection, so we did not use it.

## What Changed

- `ConnectorCard` counts native connections, gateway-managed accounts
(Composio, Arcade, Executor), and chat or bot endpoints.
- When the count is two or more, the card wraps the list in the existing
`Collapsible` component. The trigger row shows the count and a chevron
that turns when the list opens.
- The list opens by default when one or more connections need attention
or setup. The trigger row shows how many need attention.
- The `Browse` page sends `defaultExpanded` and the current trimmed
search query while a search is active. A new search opens the list
again, even after the user closed it.
- The upstream account state logic moved into the `upstreamAccountState`
helper. The list render and the attention count use the same helper. The
behavior did not change.
- The attention count and Finish setup action share one predicate. A
verifying endpoint stays visible until setup is complete. Four
regression cases cover provider setup, identity linking, missing setup
metadata, and completed setup.
- New tests in `Browse.test.tsx` cover: open and close with the toggle,
search opens the list, one connection stays inline, and the list opens
when an account needs attention.
- New review story:
`ui/storybook/stories/connection-setup/apps-connection-count-toggle.stories.tsx`
("Apps, channels, and extensions / Connection setup / Connection count
toggle"). It includes production component fixtures for collapsed,
expanded, needs-attention, search-match, single-connection,
page-overview, and unfinished-chat-setup states. The original six story
IDs are retained; the unfinished chat setup fixture adds one ID.

## Verification

- `pnpm exec vitest run ui/src/pages/apps/Browse.test.tsx`: all 84 tests
pass. The new test closes an active search result, changes the query,
then returns to the first query. It fails before the search-reset fix
and passes after it.
- `node scripts/storybook-catalog.mjs --check`: passes (265 story files,
2,520 stories). Story annotations describe the production components,
fixture boundary, and covered capabilities.
- `pnpm check:token-gates`: passes.
- Full repository typecheck and build passed after the master merge. The
final UI typecheck passes after the setup fix. Final full build and
Storybook build pass on `d4c923d3ce0`. The built index retains all six
prior story IDs and adds the unfinished-chat-setup ID. Chromium checks
pass for all seven states, including the setup action and toggle
behavior. All 54 successful CI checks pass on this head, with two
intentional skips, including all general and serialized test shards,
E2E, typecheck, and build. The fresh Apex review is 5/5 on this head
with no unresolved findings. The separate, unsharded local `pnpm
test:run` invocation has not completed; complete suite verification
comes from CI.
- The stories use local account fixtures and stub navigation. They do
not prove a live provider connection or persistence.

## Risks

- Low risk. The change is UI only, with no API or data change.
- Behavior change: users must click to see the connections on a healthy
card with two or more connections. Cards with a problem stay open, so a
broken connection is not hidden.

## Model Used

- Anthropic Claude Opus 5.5 (`claude-opus-5-5`), used in Claude Code
with tool use (shell, file edit, test runs).

OpenAI GPT-6 (`gpt-6`) through Codex assisted conflict resolution,
regression tests, and repository verification. This session does not
expose an exact context-window size.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Devin Foley <139239+devinfoley@users.noreply.github.com>
Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 14:57:48 -07:00
ba4fac585d feat(agents): show who created an agent in shared companies (#16055)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - A company in Paperclip can have more than one human member, and each
member can create agents
> - The app does not record which person created an agent
> - When two or more people share a company, members cannot see who
added an agent or who to ask about it
> - This pull request records the creator of each agent and shows the
creator on the agent Overview tab
> - The benefit is clear ownership of agents in shared companies, with
no change for single-user companies

## Linked Issues or Issue Description

No public issue exists. This description follows `feature_request.yml`.

**Subsystem affected**

Agents: the agent data model, the agent create path on the server, and
the agent Overview tab in the board UI.

**Problem or motivation**

Paperclip does not record which human user created an agent. When more
than one human user works in a company, the agent page does not tell
members who created the agent.

**Proposed solution**

Record the user ID of the creator when a human creates an agent. Show
"Created by <name>" on the Identity card of the agent Overview tab. Show
this row only when the company has two or more human members. Do not
count the synthetic local Board principal as a human member. Do not show
the local Board as a creator.

**Alternatives considered**

Count human users across the full instance. We did not do this. An
instance-wide count tells a member of one company that other companies
have users. The creator is always a member of the agent's company, so
the company count is sufficient.

**Roadmap alignment**

`ROADMAP.md` has no item for agent ownership. This change is small and
additive.

## What Changed

- Add the nullable column `agents.created_by_user_id`
(`packages/db/src/schema/agents.ts`, migration `0343_new_mentor.sql`).
- Set the column in the single agent insert path
(`server/src/modules/agent-lifecycle/adapters/records.ts`). The value
comes from the authenticated user actor. The server ignores a creator
value in the request body. Agents that agents or the system create keep
`null`.
- Backfill existing agents in the migration. The backfill uses the
earliest `agent.created` or `agent.hire_created` activity row that a
user actor wrote in the same company.
- Add `createdByUserId` to the shared `Agent` type
(`packages/shared/src/types/agent.ts`).
- Add `ui/src/lib/agent-creator.ts`. It decides if the UI shows the
creator row and it resolves the creator name. If the creator left the
company, the row shows "Former member".
- Add the "Created by" row to the Identity card in
`ui/src/pages/AgentDetail.tsx`. If the company user directory request
fails, the row shows "Could not load creator". The row does not
disappear silently.
- Add the Storybook story `Pages/Agent Detail → Shared Company Shows
Creator`.
- Document the column in `doc/SPEC-implementation.md` §7.2.

## Verification

- `pnpm --filter @paperclipai/db typecheck` passes. This includes the
migration numbering and migration safety checks.
- `pnpm --filter @paperclipai/shared typecheck` passes.
- `ui`: `tsc --noEmit` passes.
- `server`: `vitest run
src/modules/agent-lifecycle/__tests__/lifecycle.test.ts` passes (49/49).
Two new tests:
- The server records the creator from the actor and ignores a creator
value in the request body.
- The backfill takes the earliest user activity row. It skips agent
actors and rows from other companies.
- `server`: `vitest run src/__tests__/built-in-agents.test.ts` passes
(40/40). A new test checks that a built-in agent enabled by a human
records that human, and that automatic provisioning stays unattributed.
The gated (pending-approval) provisioning test also asserts the creator.
`src/__tests__/built-in-agent-routes.test.ts` also passes.
- `ui`: `vitest run src/lib/agent-creator.test.ts
src/pages/AgentOverview.test.tsx` passes (10/10). The tests cover these
cases: the row shows with two or more humans, the row stays hidden with
one human plus the Board, the UI never shows the Board as the creator,
the row shows an error when the directory request fails, and the row
stays hidden (no error) for agents with no creator or the Board as
creator. The last case fails without the fix.
- The current Storybook catalog uses source annotations and generated
indexes. `node scripts/storybook-catalog.mjs --check` passes (264 story
files, 2,514 stories). The merge keeps the authored catalog deletion
from master.
- `pnpm check:token-gates` is clean.
- Screenshots from the Storybook story (fake data: two human members,
Alice Admin and Bob Builder, plus the local Board). The red "Could not
load public key" text is a Storybook artifact: the story has no fixture
for the public key request. The existing `Dashboard` story shows the
same text.

  **Two or more human members: the Identity card shows "Created by".**

![Identity card with the Created by
row](https://raw.githubusercontent.com/paperclipai/paperclip/9b62bd2ea6cf984ce6745f08cc45f44ddf00fb51/pr-16055/identity-created-by.png)

  **One human member plus the local Board: the row stays hidden.**

![Identity card without the Created by
row](https://raw.githubusercontent.com/paperclipai/paperclip/9b62bd2ea6cf984ce6745f08cc45f44ddf00fb51/pr-16055/identity-single-human.png)

Full Overview tab:
[overview-created-by.png](https://raw.githubusercontent.com/paperclipai/paperclip/9b62bd2ea6cf984ce6745f08cc45f44ddf00fb51/pr-16055/overview-created-by.png).
The images are on the separate branch `pr-assets/agent-created-by`. They
are not in this PR and do not go to `master`.
- Manual check: open Storybook at `Pages/Agent Detail → Shared Company
Shows Creator`. The Identity card shows "Created by Alice Admin". The
`Dashboard` story has one human, so it does not show the row.
- Final focused verification on
`5a02350cf16050a3cf3cb3f8dc061fe61758c60d`: all 99 tests pass across the
two UI suites, built-in-agent suite, and lifecycle suite. The backfill
test applies the complete migration twice. The migration uses `ADD
COLUMN IF NOT EXISTS` and preserves the company-scoped backfill.
Migration numbering and token checks pass.
- Full repository typecheck, build, and Storybook build pass. The
generated creator story ID is present. A Chromium check renders the
production agent page fixture and verifies the creator row and Alice
Admin name. Map checks and their 21 tests pass. A fresh Apex review is
5/5 on the current head with no unresolved findings. All 54 successful
CI checks pass on this head, with two intentional skips, including all
general and serialized test shards, E2E, typecheck, and build. The
workspaces-b job passed after rerunning a runner shutdown; no source
change was needed. The separate, unsharded local `pnpm test:run`
invocation has not completed; complete suite verification comes from CI.

## Risks

- Migration: the migration adds one nullable column and runs one
`UPDATE` on `agents` with a correlated subquery on `activity_log`. On an
instance with a very large activity log, the backfill can take some
time. The migration does not lock other tables and does not delete data.
- Backfill accuracy: agents with no user-authored create activity row
keep `null`. The UI then does not show a creator. This is the same as
the current behavior.
- Privacy: the row shows only names from the company user directory, and
only to users who can already see that directory.
- Low risk for single-user companies: the UI does not change for them.

> For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and
discuss it in `#dev` before opening the PR. Feature PRs that overlap
with planned core work may need to be redirected — check the roadmap
first. See `CONTRIBUTING.md`.

## Model Used

- Provider: Anthropic, Claude Opus 5.5 (model ID `claude-opus-5-5`), run
as a coding agent through Claude Code with tool use (shell, file edit,
and test execution), standard context window.

OpenAI GPT-6 (`gpt-6`) through Codex assisted conflict resolution,
regression tests, and repository verification. This session does not
expose an exact context-window size.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Amy (Opus) <noreply@anthropic.com>
Co-authored-by: Paperclip <noreply@paperclip.ing>
Co-authored-by: devinfoley <139239+devinfoley@users.noreply.github.com>
2026-10-13 14:57:41 -07:00
DottaandPaperclip 2902b72c33 Merge current master into Codex runner defaults
Preserve cancelled-lock semantics and complete the merged dependency lock.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 16:55:15 -05:00
DottaandPaperclip 2238831ecd test(voice): qualify Speko task conversations and Storybook surfaces (#15729)
Third PR: depends on #15728 and #15727. The user has reviewed and
authorized merging this experimental feature stack.

## Thinking Path

> - Paperclip manages agent work through tasks and governed connections.
> - Chat connections already bind external conversations to those tasks.
> - Speko handles voice and telephony, while the selected Paperclip
agent does the work.
> - A call needs durable session authority, ordered follow-ups, and safe
result delivery.
> - This PR adds repeatable qualification for the Speko voice task
integration.
> - This PR depends on #15728, which depends on #15727. Speko stays
experimental.

## Linked Issues or Issue Description

**Problem or motivation**

Phone and browser voice conversations cannot use the chat connection
task lifecycle. A separate voice runtime is needed to preserve task
authority, retries, and reply history.

**Proposed solution**

Add company-scoped voice sessions, signed callbacks, durable replies,
inbound intake, and an agent-facing outbound-call tool. Reuse existing
tasks, queues, secrets, and publications.

**Roadmap alignment**

This extends the experimental chat connector entry points under Agent
Chat and Connected Apps. The project owner requested this feature.

Refs #11418 for the original provider catalog proposal. This
implementation uses the newer chat connection infrastructure rather than
an MCP catalog-only integration. Refs #15721 for remote OpenCode
startup.

## What Changed

- Add a real Paperclip server/database E2E fixture that stubs only
external Speko transport and the execution provider.
- Add authenticated multi-user and cross-company qualification journeys.
- Add Storybook interaction, accessibility, responsive, and visual-suite
integration.
- Add an E01–E16 runbook, component-to-story inventory, and current
redacted qualification report.
- Keep historical private call traces out of the PR. Provider proof
tools are opt-in.

## Verification

- All 21 standalone proof tests and browser client/server syntax checks
pass. They cover signatures, redaction, cleanup retry, final audio
saves, bounded report transport and late server write ordering. No live
calls were placed.
- All 27 focused UI/controller regressions, UI typecheck, token gates,
and 28 map/catalog structural tests pass. The shared connection cache
test covers pause/resume invalidation during the 30-second fresh period.
- Storybook builds 157 Speko production-component stories. The complete
prior 156-story set passed all 624 checks on UI source 249cbc616a. After
the final cache repair, all 152 affected page/launcher checks passed
across both themes, 390/1200 widths and reduced motion. Real microphone
access and external provider requests are blocked.
- Hosted Storybook origin isolation and representative narrow-screen
stories pass. Provider requests remain blocked.
- Source annotations follow the current generated-catalog contract. No
generated catalog or lockfile is included. Three inherited
GitHub-heading tests passed after master reconciliation.
- Commit 905bc5da5d has 55 passing checks,
including required verify/E2E gates, and a fresh Greptile 5/5 review
with zero unresolved findings. Local fixture success does not establish
provider or spoken-playback acceptance.
- The separate integrated browser run passed two journeys and failed
browser answer retrieval. Real browser/telephone playback and timing
acceptance remain outstanding. See the dated qualification report and
E01–E16 runbook. Speko stays experimental.

## Risks

- Voice sessions add migrations and provider-dependent lifecycle
behavior. Migrations preserve existing chat and AI transports.
- Callback origins must be reachable HTTPS. Provider keys and signing
secrets remain vaulted.
- Unverified callers receive task-scoped low-trust authority. Caller ID
does not grant private task access.
- Outbound telephony incurs provider charges. Provider acceptance is not
proof that the caller heard an answer.
- Keep the feature behind the existing experimental chat setting until
the real browser, inbound, outbound, and delayed-result acceptance
matrix passes.

## Model Used

OpenAI Codex, GPT-6, with tool use and code execution. The exact serving
model ID and context window are not exposed in this session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [ ] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 16:54:41 -05:00
a64969b288 fix(server): attribute legacy runs stopped by controller lease loss (#16084)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - The heartbeat runner executes legacy agent runs. A controller lease
watchdog keeps durable ownership of each legacy run.
> - When the watchdog loses the lease, it aborts the adapter. The abort
reason was a plain `Error`, and nothing recorded why the run stopped.
> - Completion then saved the cancellation as source `unknown`. Sentry
got an unexpected cancel that it could not tell apart from other
unrecorded stops.
> - We saw this on a sandboxed Grok run. The system cancelled it after
about 22 minutes with `cancellationSource: unknown`. Workspace copy-back
then failed. Every `cancelRun` path records a stop request, so an
unrecorded stop this late points to the lease watchdog.
> - This pull request records a lease loss as its own cancellation
source, with a closed cause label.
> - The benefit is that the next event shows whether the lease loss
caused the stop, and which renewal failure caused it. That is the
missing fact to fix the root cause.

## Linked Issues or Issue Description

Refs #15790
Refs #15920

**What happened?**
A legacy sandbox run was stopped by the system while it was working. The
run record and the Sentry diagnostics show `cancellationSource:
unknown`, with no initiator. The controller lease watchdog aborts the
adapter with a plain `Error("Legacy controller lease lost")`. Completion
does not read the abort reason, so it records the stop as `unknown`.

**Expected behavior**
When the host stops its own adapter because it lost the controller
lease, the run records that cause. Diagnostics name the cause with a
closed label. A stop that a user or the control plane requested earlier
keeps its recorded source.

**Steps to reproduce**
1. Start a legacy run that has a controller lease.
2. Make lease renewal fail: the renewal query errors, the update matches
no row, or the lease deadline passes.
3. Let the adapter return its cancelled result.
4. Read `resultJson.cancellation` on the run. Before this change,
`source` is `unknown`.

**Agent adapter(s) involved**
Not adapter-specific (core bug). We saw it with `grok_local` in a
sandbox.

**Additional context**
This change adds diagnostics. It does not prevent the lease loss. #15920
retries a transient copy-back failure. It does not help here, because
the stopped sandbox rejects every retry.

## What Changed

- `legacy-controller-lease.ts`: The watchdog aborts with a new
`LegacyControllerLeaseLostError`. The error carries a closed cause:
`renewal_rejected`, `renewal_deadline`, or `renewal_error`.
- `run-cancellation.ts`: Add the `controller_lease` cancellation source.
Add `controllerLeaseLossCancellation()` and
`readControllerLeaseLossCause()`. The reader accepts only the
server-written reason text.
- `heartbeat/run-completion.ts`: When the outcome is `cancelled` and the
abort reason is a lease loss, record a `controller_lease` cancellation
(`expected: false`). This covers both an adapter that returns a
cancelled result (`completeRun`) and one that throws after the abort,
for example through `signal.throwIfAborted()` (`failRun`). A stop
request recorded earlier still takes precedence.
- `run-failure-diagnostics.ts`: Add `controllerLeaseLossCause` to the
execution diagnostics. Only the closed label goes to Sentry, never the
reason text.
- `heartbeat/run-state.ts`: preserve `controller_lease` in the bounded
SQL projection when saved results exceed 64 KB. A database regression
verifies the default run-detail read.
- `canContinueCancelledRun` stays unchanged. It does not accept
`controller_lease`, so a lease loss does not authorize automatic
continuation.
- `doc/run-log-events.md`: Document the new source and cause labels.
- Tests: unit tests for the cause on each watchdog path, completion
tests that record the source when the adapter returns and when it throws
the abort reason (both fail without the change), tests that a recorded
stop request takes precedence, and a test that the Sentry report
contains the closed label and not the reason text.

## Verification

- `cd server && npx vitest run src/services/run-cancellation.test.ts
src/services/legacy-controller-lease.test.ts
src/services/__tests__/run-failure-report.test.ts
src/services/heartbeat/run-completion.test.ts`: 238 passed, including
the embedded Postgres suites.
- I reverted only `run-completion.ts` and ran the new completion test.
It failed with `source: "unknown"`. With the change, it records
`controller_lease`.
- I removed only the `failRun` attribution and ran the new thrown-error
test. It failed without the `controller_lease` record, and passes with
it.
- Final full repository `pnpm -r typecheck` and `pnpm build` pass.

- Final local regression verification: all 247 tests pass across
run-state, cancellation, watchdog, failure reporting, and completion
suites. The large-result test fails before the SQL allowlist change. All
latest-head CI checks pass (54 successes and two intentional skips).
Fresh Apex is 5/5 on `708856c568d07d7b446a4a4af2edc6d9eec7d155` with no
unresolved findings.

## Risks

- Low risk. The change adds a new source value to server-owned JSON. Old
rows keep their values. The readers accept the new value, and no UI code
switches on this field.
- A lease-loss cancel stays `expected: false`, so it is still reported
as unexpected, as before. Now it has a more specific source.
- The Sentry payload gets one new closed label
(`controllerLeaseLossCause`). It does not include reason text or IDs.

> For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and
discuss it in `#dev` before opening the PR. Feature PRs that overlap
with planned core work may need to be redirected — check the roadmap
first. See `CONTRIBUTING.md`.

## Model Used

- Anthropic Claude Opus 5.5 (`claude-opus-5-5`) in Claude Code, with
tool use (shell, file edits, test runs).

OpenAI GPT-6 (`gpt-6`) through Codex added the large-result regression
and SQL projection fix, with shell, file-edit, and test tools. The exact
context-window size is not exposed in this session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: devinfoley <139239+devinfoley@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 14:50:40 -07:00
DottaandPaperclip 8d65fd7fc3 test: stabilize company seeds and diagnose durable progress failures
Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 16:43:27 -05:00
DottaandPaperclip edcfcaf3f6 fix(ui): leave hidden task source defaults to the server (#16220)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - The task dialog sends project and workspace choices to the control
plane.
> - Hidden workspace controls must leave automatic source choices to the
server.
> - The dialog still sent its computed source pointer while those
controls were hidden.
> - This bypassed the implicit default branch added in #16095 and saved
an untyped source choice.
> - This pull request omits that automatic pointer and preserves
explicit launch context.
> - The benefit is that fresh tasks can use the server's safe isolated
default source path.

## Linked Issues or Issue Description

Refs #16095. A search found no open duplicate for the hidden-selector
payload bug.

**What happened?**

A fresh task created through the board with a project and hidden
isolation controls failed setup with “Task workspace access is no longer
available.” The dialog sent `projectWorkspaceId` even though the user
had not selected a source. The saved task had no workspace-selection
provenance. No provider turn started.

**Expected behavior**

Omit automatic or restored draft source pointers when the selector is
hidden. Let the server select and record the project default. Preserve
explicit source and execution-workspace context supplied by a launch
action.

**Steps to reproduce**

Hide `workspaces.isolation` through the existing operator setting. Use a
project with a default Git source and isolated workspace policy. Create
a fresh task from the board. Inspect the creation payload: the hidden
automatic source must be omitted. The server must then apply its
existing default source contract. A restricted shared source must remain
protected.

**Paperclip version or commit**

Observed on Core `c7f4b74111d16f0b57112fa6d0b6a59c2d63bfe8`, which
includes #16095.

**Deployment mode**

Authenticated staging Cloud instance with a configured remote runner
provider and operator-hidden workspace controls.

## What Changed

- Omit the automatic `projectWorkspaceId` while isolation controls are
hidden.
- Keep explicit same-project launch source context, including reused
workspaces and subtasks.
- Add a fresh-default payload regression and strengthen stale-draft and
explicit-context controls.
- Keep server authorization, trust checks, source fallback rules,
visible selectors, and stored old tasks unchanged.

## Verification

- Before the repair, the hidden fresh/default and restored-source
regressions failed: 2 failed, 3 passed, 79 other cases filtered.
- Final rebased source: `pnpm exec vitest run --project @paperclipai/ui
ui/src/components/NewIssueDialog.test.tsx
ui/src/lib/project-workspace-defaults.test.ts` passed all 87 cases.
- `pnpm --filter @paperclipai/ui typecheck` passed.
- `pnpm --filter @paperclipai/ui build` passed.
- `pnpm check:token-gates` passed.
- Initial UI typecheck failed because this new checkout had not built
the plugin SDK. Building that dependency and repeating the unchanged
check passed. The failed attempt remains separate from the source
regression.
- Full repository typecheck, full repository tests, and full repository
build have not been run locally for this two-file UI patch. Complete
latest-head CI passed with 55 successful checks and two intentional
skips. This includes the full repository typecheck, build,
general/serialized tests and all eight browser shards. Fresh Apex is 5/5
on `f992823480311691469c6797d5cdff26d76899a2`, with no unresolved
findings or recommendations.
- No live recovery pass is claimed. The deployed baseline failed before
provider startup. A fresh same-project task must pass after this patch
is deployed. Existing tasks with untyped source pointers need a separate
authorized recovery path.
- The old Storybook maps were reviewed at the baseline, then master
removed them. The rebase preserves that removal. The final Storybook
structural check covers 262 files and 2,485 story IDs. No new Storybook
browser, play, render, or visual proof is claimed.

## Risks

- Hidden restored draft source choices are intentionally ignored.
Explicit same-project launch defaults remain in the request and have
controls for normal tasks and subtasks.
- Visible workspace choices retain their existing behavior.
- This patch fixes one creation path. It does not recover old tasks,
relax private source restrictions, or establish a performance fix for
slow historical runs.
- No data model, endpoint, permission, runner, or Observability changes.

## Model Used

OpenAI GPT-6 through Codex, with code and browser tools. The exact
served model identifier and context-window size are not exposed in this
session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 14:26:56 -07:00
DottaandPaperclip 22d05644f4 feat(ui): add Speko voice setup, task calls, and Storybook coverage (#15728)
Runtime #15727 is merged. This PR adds the UI. Qualification follows in
#15729.

## Thinking Path

> - Paperclip manages agent work through tasks and governed connections.
> - Chat connections already bind external conversations to those tasks.
> - Speko handles voice and telephony, while the selected Paperclip
agent does the work.
> - A call needs durable session authority, ordered follow-ups, and safe
result delivery.
> - This PR adds the Speko setup and call controls to the existing Apps
and task UI.
> - This PR depends on #15727. The qualification suite follows
separately. Speko stays experimental.

## Linked Issues or Issue Description

**Problem or motivation**

Phone and browser voice conversations cannot use the chat connection
task lifecycle. A separate voice runtime is needed to preserve task
authority, retries, and reply history.

**Proposed solution**

Add company-scoped voice sessions, signed callbacks, durable replies,
inbound intake, and an agent-facing outbound-call tool. Reuse existing
tasks, queues, secrets, and publications.

**Roadmap alignment**

This extends the experimental chat connector entry points under Agent
Chat and Connected Apps. The project owner requested this feature.

Refs #11418 for the original provider catalog proposal. This
implementation uses the newer chat connection infrastructure rather than
an MCP catalog-only integration. Refs #15721 for remote OpenCode
startup.

## What Changed

- Add the Speko Apps catalog entry, provider artwork, and browser SDK.
- Reuse existing agents in setup. Keep the optional Company Phone Agent
in the catalog, with connection instructions available to any assigned
agent.
- Add task voice controls, transcripts, phone callbacks, inbound-line
settings, and call Activity entries.
- Surface retryable connection and incoming-task inventory failures,
preserve active call controls and cached tasks, restore keyboard focus
after recovery, and bound notification polling so a stuck request cannot
hide later results.
- Put Save & exit and Connect Speko in the credential step’s shared
footer.
- Add deterministic production-component Storybook fixtures for setup,
lifecycle, failures, permissions, and phone surfaces.
- Include voice components in the design guide. Stories never request a
real microphone or place calls.

## Verification

- All 27 focused UI/controller regressions, UI typecheck, token gates,
and 28 map/catalog structural tests pass. The shared connection cache
test covers pause/resume invalidation during the 30-second fresh period.
- Storybook builds 157 Speko production-component stories. The complete
prior 156-story set passed all 624 checks on UI source 249cbc616a. After
the final cache repair, all 152 affected page/launcher checks passed
across both themes, 390/1200 widths and reduced motion. Real microphone
access and external provider requests are blocked.
- Source annotations follow the current generated-catalog contract. No
generated catalog or lockfile is included. Three inherited
GitHub-heading tests passed after master reconciliation.
- Latest-head CI and Greptile review must pass before merge. Local
fixture success does not establish provider or spoken-playback
acceptance.
- The separate integrated browser run passed two journeys and failed
browser answer retrieval. Real browser/telephone playback and timing
acceptance remain outstanding. See the dated qualification report and
E01–E16 runbook. Speko stays experimental.

## Risks

- Voice sessions add migrations and provider-dependent lifecycle
behavior. Migrations preserve existing chat and AI transports.
- Callback origins must be reachable HTTPS. Provider keys and signing
secrets remain vaulted.
- Unverified callers receive task-scoped low-trust authority. Caller ID
does not grant private task access.
- Outbound telephony incurs provider charges. Provider acceptance is not
proof that the caller heard an answer.
- Keep the feature behind the existing experimental chat setting until
the real browser, inbound, outbound, and delayed-result acceptance
matrix passes.

## Model Used

OpenAI Codex, GPT-6, with tool use and code execution. The exact serving
model ID and context window are not exposed in this session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [ ] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 16:26:38 -05:00
Harjoth KharaandClaude Opus 5 be3e614d61 fix(workspace-runtime): keep the real readiness failure when the deadline-clamped probe aborts (#11575)
## Thinking Path

> - Paperclip manages AI agents and the services they use for work.
> - An agent can wait for a workspace service to become ready.
> - Each readiness probe has a time limit.
> - A final probe can expire and hide an earlier HTTP failure.
> - This pull request keeps that observed failure in the reported error.
> - Operators can then see why the service was not ready.

## Linked Issues or Issue Description

Refs #11525. Related: #11494.

**What happened?**

A deadline-limited final readiness probe replaced an observed HTTP 503
with an abort message.

**Expected behavior**

Keep an earlier service failure when only the readiness deadline aborts
the last probe. Report normal connection failures and probe timeouts as
before.

**Steps to reproduce**

Return HTTP 503 from the first probe. Leave one millisecond in the
readiness budget. Abort the last probe. The reported error must still
contain HTTP 503.

## What Changed

- Track whether a readiness probe observed a service failure.
- Preserve that observation when the final probe expires at the
readiness deadline.
- Add a deterministic regression with an injected clock.
- Keep probe scheduling, request count and timeout limits unchanged.

## Verification

- Author verification: the readiness suite passed all nine tests; server
typecheck passed. The regression failed before the fix and passed after
it.
- The later task review recorded 172 passing workspace tests and seven
additional readiness checks. Historical author baseline failures are not
claimed as passing local runs.
- Latest head `936a374a08d0e74d87d588ba034f674388e8d508`: CI passed with
54 successful checks and two intentional skips. Fresh Apex review is 5/5
with no unresolved findings or recommendations.
- A test merge with current master is clean.

## Risks

- Error text changes when a service first fails and then hangs. The
earlier observed failure is retained.
- A hang without a prior service failure still reports the abort.
- No data model, API or permission change.

## Model Used

Anthropic Claude Opus 5 (`claude-opus-5`) authored the fix through
Claude Code with reasoning, file editing and test tools. OpenAI GPT-5.6
assisted the original diagnosis. OpenAI GPT-6 (`gpt-6`) through Codex
assisted this final review and PR preparation with repository and
terminal tools. This session does not expose an exact context-window
size.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
canary/v2026.1013.0-canary.16
2026-10-13 14:25:09 -07:00
DottaandPaperclip 473c80d13f Automatically import and update project repository skills (#16066)
Automatically import skills from new GitHub project repositories and update enabled sources in the background. Preserve project-derived access, saved selections, immutable execution versions and explicit pins; add legacy adoption, refresh and connection repair in Sources.

Include durable scheduling and bounded work credits, production Storybook journeys, real GitHub-to-routine acceptance receipts and final-head CI/security/Greptile qualification.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 16:11:43 -05:00
Devin FoleyandPaperclip de335b42d4 Expose signed routine wake deadlines during idle sleep checks
Expose signed routine wake deadlines during idle sleep checks

Report the earliest eligible routine deadline to an authenticated host scheduler, while preserving local execution, owned sleep leases and conservative blocking for unsupported work.

Verified with focused tests, typecheck, build, all required CI checks and Apex 5/5.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 14:09:16 -07:00
DottaandPaperclip d68f1facf0 Merge master Storybook source annotations and preserve Codex qualification
Retain all authored story identities and fixture boundaries under the generated-index contract. Record literal candidate checks, managed model failure and pending package/staging evidence. Native execution, selection, setup, onboarding, credentials, migrations and packaging retain their qualified source.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 16:02:15 -05:00
DottaandPaperclip 7eea9d8214 fix(github): use bot names in review summaries (#16212)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - A GitHub bot can send a pull request to an agent and publish its
review.
> - Each bot has its own GitHub App identity, but every summary
currently starts with "Paperclip Review".
> - A generic heading makes it harder to identify reviewers when several
bots review the same pull request.
> - This pull request uses the bot display name in review summary
headings.
> - Users can identify each reviewer while required checks keep their
existing name.

## Linked Issues or Issue Description

**What existing behavior does this improve?**

The heading of a GitHub bot's published pull request review summary.

**Current behavior**

Every summary uses "Paperclip Review", regardless of the bot's name. The
check also uses "Paperclip Review" and must keep that name for existing
branch rules.

**Proposed behavior**

Complete and incomplete review summary headings use the GitHub bot
display name. The heading falls back to the bot login, then the assigned
agent name, when old connections have no display name. Separate GitHub
Apps keep independent checks with the same name.

**Reason and benefit**

Readers can identify each bot's review. A regression test confirms that
publishing a review does not update a check owned by another App or
endpoint.

**Breaking changes**

The summary heading changes. Consumers that parse the old heading must
accept bot names. No API, prompt configuration, database schema, or
check name changes are included.

No duplicate PR was found in the GitHub bot title search. ROADMAP.md
does not contain a duplicate of this change.

## What Changed

- Use the bot display name in complete and incomplete review headings.
- Escape Markdown in names and fall back to the bot login or agent name.
- Verify the heading through the publication workflow and keep check
updates scoped to the App and endpoint.
- Document bot-named summaries and independent checks. Update both
access maps.

## Verification

- Focused policy, heading, and existing UI tests: 67 passed.
- Database-backed regression cases: 2 passed, including bot-name
publication and independent checks.
- Map checks, token gates, and git diff --check passed.
- Typecheck and build passed on the final rebased branch. The final
focused run passed 44 tests; the two database-backed regression cases
also passed in a separate run. All final-head CI checks passed,
including full test suites, build, typecheck, E2E, and security scans.
Greptile reviewed the final commit at 5/5 with no actionable findings.
No review threads remain unresolved.

## Risks

- Consumers that parse the old summary heading must accept bot names.
- The GitHub check remains Paperclip Review. Multiple-bot check
isolation was tested with provider fixtures; a live two-bot GitHub test
was not run for this change.

## Model Used

OpenAI GPT-6 through Codex. The exact backend model ID and context
window are not exposed in this session. Used reasoning, repository
tools, and code execution.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 15:33:05 -05:00
DottaandPaperclip 433d94ee0b refactor(maps): generate indexes from local story and feature metadata (#16214)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Feature recipes and Storybook help contributors find behavior,
examples, and verification steps.
> - Independent feature changes currently update shared catalogs,
indexes, and review hashes.
> - Those shared files cause merge conflicts and repeated bookkeeping
during parallel work.
> - This pull request stores metadata in each feature recipe and story,
then generates the combined views.
> - Contributors can merge independent work without editing a common
index. Git and PR evidence retain change and review history.

## Linked Issues or Issue Description

**What existing behavior does this improve?**

Maintaining the product, agent-access, and Storybook maps while multiple
agents change different features.

**Current behavior**

A story or recipe change can update `catalog.json`, `INDEX.md`, review
hashes, verification tables, and tracked generated navigation. Two
unrelated changes then conflict in the same files.

**Proposed behavior**

Each story declares capability links and classification in
`parameters.paperclip`. Each feature recipe declares its navigation and
optional verification guidance. Startup, build, and UI typechecking
discover these sources and generate ignored indexes and Storybook pages.

**Reason and benefit**

A routine change edits its own source files. Aggregate metadata is
rebuilt from the merged checkout. There is no sidecar registry, shared
review journal, or hash acknowledgment to maintain.

**Breaking changes**

The tracked Storybook catalog and index paths are retired. Consumers use
`ui/storybook/generated/` or `maps/generated/` after generation.
Contributor instructions and the existing feature-gap browser suite use
the new paths. Story and overview IDs remain stable.

## What Changed

- Move the existing annotations into 262 story files. Preserve
classifications, capability associations, exports, and explicit IDs.
- Discover all 35 feature recipes. Store section/order beside each
recipe and move durable verification routes out of the shared table.
- Remove tracked catalogs, inventories, overview pages, and inline
preview ordering. Keep authored preview behavior in `preview-base.tsx`.
- Generate the Storybook guide, feature/access Markdown indexes, gap
report, page-reference inventory, and preview wrapper automatically.
- Update the map contracts and maintenance skills to use Git history and
revision-specific PR/CI evidence.
- Add schema, identity, regeneration, and actual Git merge tests. Run
these through the existing UI Vitest suite. Add focused browser
navigation checks.

This is one coordinated migration. Most of the 367 changed files contain
only moved metadata or deleted generated content. Review the generator
scripts, map contracts, Storybook configuration, and tests first. No
product API or authorization behavior changes.

## Verification

Passed:

- `node scripts/check-maps.mjs`: 35 paired areas and 175 capabilities.
- `node scripts/storybook-catalog.mjs --check`: 262 suites and 2,485
authored stories after incorporating current master.
- `node --test scripts/check-maps.test.mjs
scripts/storybook-catalog.test.mjs
scripts/storybook-feature-index.test.mjs`: 28 tests, including
independent branches merged in both orders with identical generated
output and no tracked changes.
- `pnpm --filter @paperclipai/ui exec vitest run
storybook/map-tooling.test.ts`: the CI entrypoint runs those map tests.
- `pnpm check:token-gates`.
- `pnpm -r typecheck` and `pnpm build` before the final master rebase.
- `pnpm build-storybook`: all 2,517 original story/docs URLs retained.
Current master contributes exactly four additional recovery stories.
- Focused Playwright navigation checks: search and open a feature
without examples; expand verification guidance and check source links;
retain capability order and follow a related Foundations suite.

The final clean Storybook build passed after deleting every ignored map
output. Post-rebase UI typechecking and both browser tests passed. The
working tree stays clean after generation. The concurrent-cleanup
regression fails with `ENOENT` without the fix and passes with it.

All GitHub CI gates passed on `00fc7ec18e`, which also received Greptile
5/5 with no unresolved findings. The final merge commit `1c3c5143a6`
incorporates master and resolves only the two modify/delete conflicts by
retaining removal of the aggregate index and catalog. Master’s new
workspace feature and access guidance is preserved. Map validation,
catalog generation, overview generation, all 28 map tests, and diff
checks pass after conflict resolution. The maintainer explicitly
requested merging without another Greptile review. CI has not been rerun
to completion on this merge commit. The local repository-wide `pnpm
test:run` was stopped before completion after the earlier CI matrix
passed; it is not reported as a local pass. No screenshot baselines or
production acceptance are claimed.

To repeat the browser check against an owned Storybook server:

```sh
PAPERCLIP_GAP_STORYBOOK_URL=http://127.0.0.1:6136 pnpm exec playwright test --config tests/storybook-visual/feature-gap-stories.config.ts map-navigation.spec.ts
```

## Risks

- Existing branches need a one-time rebase to move their catalog changes
into local annotations. The PR incorporates the recovery changes from
current master.
- Changing the same story or capability can still produce a meaningful
conflict. This removes the shared aggregate bottleneck.
- The generator uses Storybook's existing CSF parser. Literal-only
annotations and parser regression tests protect the current contract.
- Generated Markdown is available after running the generator; the
published Storybook provides a browsable guide.
- Shared source changes still require review. Removing hashes removes
mechanical acknowledgments; it does not establish runtime parity.

## Model Used

OpenAI Codex, based on GPT-6, with repository inspection, code
execution, and browser-test tools. The exact deployment model ID and
context window were not exposed in this session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green on the previously reviewed head
`00fc7ec18e`; final conflict-resolution checks are documented above
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
on `00fc7ec18e`; another review was waived by the maintainer
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
canary/v2026.1013.0-canary.15
2026-10-13 15:27:23 -05:00
DottaandPaperclip 57881c607f Preserve selected Codex API-key precedence and login reload continuity
Skip subscription source reads and refresh binding when CODEX_API_KEY is selected, matching the native task materializer. Retain managed subscription validation, no-follow staging and credential redaction.

Update the existing mocked-login browser case to verify Connect restoration, the exact active session and saved selection through route reopening and real reload. Retain one login start, no pending hire and existing deadlines.

Verification: 93 setup and 12 lower controls, server no-emit, independent source review, map and token gates pass. Preserve initial local import-deadline failures. The old browser expectation was reproduced; final local browser treatment stopped at PostgreSQL initialization and remains for hosted Linux CI. No paid or image qualification was dispatched.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 15:25:17 -05:00
Dotta 1d09569b05 Merge workspace isolation fix and reject unsupported linked Codex homes 2026-10-13 15:02:50 -05:00
Dotta 736d326822 Merge master while retaining Codex setup and onboarding fixes 2026-10-13 14:37:53 -05:00
Devin FoleyandPaperclip c7f4b74111 fix: isolate fresh task sources from restricted project workspaces (#16095)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Each task must have an isolated workspace that its agent can read.
> - Older project checkouts can contain worktrees for restricted tasks.
> - The source access check correctly rejects these shared checkouts.
> - A fresh task then fails even when its agent can clone the project
remote.
> - This pull request gives fresh default tasks a separate clone of the
same remote.
> - The task can start while the restricted task files remain protected.

## Linked Issues or Issue Description

**What happened?**

Fresh tasks fail with `Task workspace access is no longer available`
when their default project checkout contains a restricted task worktree.
The caller has access to the new task and its remote repository. The
shared local Git source is unsafe to copy.

**Expected behavior**

Use a separate clone of the same authorized remote for a fresh default
task. Keep source access checks and responsible-user Git credentials in
force.

**Steps to reproduce**

1. Put a restricted task worktree inside a project checkout.
2. Assign a new default task to an agent that cannot read the restricted
task.
3. Start the new task. The current source check fails before workspace
creation.
4. With this fix, the task uses a separate remote source. The restricted
files are absent. Later runs reuse the same owned source.

Related work: Refs #15749, Refs #15528. This change keeps their source
retention and workspace ownership checks.

## What Changed

- Add a remote source path scoped to the company and task.
- Clone through the run’s Git connection after the shared source fails
its access check.
- Reject reused workspaces, explicit selections, pinned branches, local
sources, credential-bearing URLs, and symlink paths.
- Check source access again before publishing the workspace.
- Resolve later runs from the verified recorded source. Ignore leftover
clones that the saved workspace does not own.
- Record provenance for new implicit Git defaults. Read the current task
binding before fallback. Preserve explicit, inherited and ambiguous
legacy checkout choices.
- Keep the effective task strategy during startup validation of matching
implicit defaults. Preserve the existing explicit-selection write check.
- Add regression coverage and document the fallback.

## Verification

- Merged master `c8efdbfba43` and resolved both rounds of catalog/index
conflicts. All upstream suites, classifications, source references and
story IDs are preserved. Both fix branches combine cleanly in either
merge order, with no catalog fingerprint drift.
- Passed locally: 313 focused source-isolation, preparation,
task-creation, binding and trust tests before the final startup fix. The
final fix passes all 100 source-trust, task-binding and
environment-selection tests. Earlier workspace-resolution and
persisted-source suites also passed.
- Real-Git regressions cover all three review findings. Reconstruction
ignores an unrecorded clone and preserves unpublished commits/files.
Explicit and parent-inherited checkout IDs without typed selections
retain their denial and branch tips without cloning or acquiring an
environment. A protected-project heartbeat completes and resumes using
the task’s Git strategy with read access. Explicit selection still
requires writes, and a mismatched default is rejected.
- Passed: the complete Storybook catalog check with no drift errors,
feature and agent map structure checks, and all 17 catalog/index script
tests. The generated index counts match the merged catalog. The current
upstream verification-route inventory remains unchanged. The catalog
contains all 262 authored suites and 2,481 story IDs.
- Passed: full workspace typecheck and build after the final guard
changes, on latest head `79d2adadcb6d3d7a04b9943a91bdb8b0b6abea6d`.
- Latest head `79d2adadcb6d3d7a04b9943a91bdb8b0b6abea6d`: complete CI
passed (54 successful checks, two intentional skips), including the full
general/serialized suites and all eight browser shards. Fresh Greptile
Apex review is 5/5 on this same commit, with no unresolved findings or
recommendations. The full local test command was attempted earlier
without a complete aggregate result; the complete suite result is from
CI.
- Manual check: configure a shared project checkout with a restricted
task worktree. Admit a fresh default task using the authorized remote.
Confirm separate Git storage and no restricted local branch or file.
Reuse, close and reopen the task workspace. Confirm that explicit,
literal branch and low-trust selections retain the denied source.

## Risks

- A clean remote clone excludes unpublished local work. The fallback
applies only to fresh default tasks and rejects existing workspace or
branch selections.
- A private remote can fail to clone when the responsible user lacks Git
credentials. The run then reports the failure; access checks are not
bypassed.
- Older untyped checkout bindings cannot prove default provenance. They
keep the source denial instead of silently dropping unpublished work.
- New implicit Git defaults use the existing workspace-intent contract.
The source directory uses existing instance storage. No schema migration
is required.

## Model Used

OpenAI GPT-6, model ID `gpt-6`, through Codex. Used reasoning,
repository inspection, code editing, terminal tools, and test execution.
The API session does not expose an exact context window size.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
canary/v2026.1013.0-canary.14
2026-10-13 12:31:40 -07:00
Dotta 12046f522b Fix saved Codex setup credentials and onboarding reload recovery 2026-10-13 14:28:40 -05:00
DottaandPaperclip 393d1c4108 docs(skills): add standalone test-audit workflow (#16211)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Repository skills guide agents through engineering work.
> - Test gardening must preserve useful regression coverage while
reducing repeated work.
> - Contributors need a local procedure for evidence, validation, and
delivery.
> - This pull request adds a standalone test-audit skill with a short
entry point and focused guides.
> - The procedure supports focused cleanups and coordinated audits
without requiring an external skill checkout.

## Linked Issues or Issue Description

**Issue type**
Missing documentation.

**Where is the issue?**
The repository has no standalone `.agents/skills/test-audit/` procedure
on master.

**What's wrong?**
Test audits need consistent rules for retaining contracts, proving
removal safety, recording cost evidence, and tracking stacked delivery.

**Suggested fix**
Add a self-contained skill with candidate evidence, validation,
campaign, and Paperclip delivery guides. Preserve upstream attribution.

Related audit work: Refs #15978, Refs #16022, Refs #16197. The duplicate
search found no standalone skill PR. This docs change does not duplicate
planned core features in ROADMAP.md.

## What Changed

- Add a short test-audit entry point and agent metadata.
- Require contract and keeper evidence before removing tests. Apply an
authoring gate to added or changed tests.
- Define targeted and exhaustive campaign modes, a second review of
redundant layers, and full keeper dependency checks.
- Document matched baselines, intended-failure controls, selection
checks, honest cost claims, and current-head delivery gates.
- Add Paperclip commands and invariants. Retain OpenClaw attribution and
its MIT notice.

## Verification

- The skill frontmatter validator passed with cached PyYAML.
- Agent metadata YAML parsed. The default prompt names `$test-audit`.
- All eight relative Markdown links resolve. All seven delivery files
matched the reviewed source.
- `git diff --check` passed. The PR contains only seven Markdown/YAML
skill files.
- An independent scenario review checked the campaign completion and
coverage rules.
- Local application typecheck, full Vitest, and build were not run for
this documentation-only change. Fresh current-head CI passed: 55
successful checks and two expected skips on
`1a9af8ffacd532882f0a01bac8ab3f5063ab9cd9`.
- E2E shard 8/8 was interrupted after its assertions passed. A single
same-head job retry passed. The interruption cause was not exposed.
- Greptile reviewed the current head at 5/5 with no actionable findings.
There are no review threads. The PR has no merge conflicts and remains
open as requested.

## Risks

- Low runtime risk. This PR changes contributor instructions only.
- Agents can misapply audit evidence. The skill requires valid keepers
and preservation proof, rejects keeper cycles, and makes incomplete
audits explicit.
- CI routing can change. The guide requires readers to inspect current
repository files.

> For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and
discuss it in `#dev` before opening the PR. Feature PRs that overlap
with planned core work may need to be redirected — check the roadmap
first. See `CONTRIBUTING.md`.

## Model Used

OpenAI Codex based on GPT-6 wrote and tightened the skill. Its exact
deployment model ID and context-window size are unavailable. Independent
scenario review and PR delivery used OpenAI `gpt-6.1-sol`, with
reasoning, repository inspection, and tool execution. The context-window
size was not exposed.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 14:08:51 -05:00
Nicky LeachandPaperclip db65a0863e Deliver durable resource lifecycle events to plugins without polling (#16203)
## Thinking Path

> - Paperclip manages AI agents and their work.
> - Plugins keep external resources aligned with Paperclip projects and
agents.
> - The durable resource journal stores changes, but its plugin
interface requires polling.
> - Project deletion has no journal entry, so consumers must scan for
missing projects.
> - This PR delivers committed journal events through a native plugin
callback and records deletion.
> - Plugins can recover unfinished work without periodic change scans.

## Linked Issues or Issue Description

Related: #15343 introduced the durable inbox. #15631 added required
agent lifecycle participation. This change keeps both contracts and adds
automatic delivery for the resource inbox.

**What happened?**

Plugins must schedule reads of the durable inbox. A deleted project has
no durable deletion event. Consumers must scan saved bindings to detect
its removal.

**Expected behavior**

Core should deliver committed resource events and replay unfinished
work. Empty queues should have no polling timer. Project removal should
leave a durable event.

**Steps to reproduce**

1. Install a plugin that consumes project lifecycle events.
2. Create or update a project. The plugin must call `listLifecycle` to
discover it.
3. Delete the project. The journal has no deletion entry.

## What Changed

- Add `resourceLifecycle` to the manifest and `onResourceLifecycle` to
the SDK. Require `events.subscribe` and a configured, enabled company
scope.
- Reuse transaction-aware work signals and the delivery coordinator.
Wake after commit, on startup and plugin activation, and after
configuration changes.
- Acknowledge only a matching successful result. Retry unfinished or
interrupted work. Retain deferred events without an idle retry timer.
- Wake again after successful worker configuration application, and
retain failed scans through idle drain (both Apex findings fixed).
- Keep ordering per resource and deliver past failed or deferred
resources. Keep the manual inbox methods for existing consumers.
- Record project deletion in the removal transaction. Extend the journal
constraint with a generated migration.

## Verification

- Apex follow-up: 129 focused worker, delivery, coordinator, and
application tests passed; server typecheck passed. Regression coverage
verifies configuration-application races and failed scans across idle
drain.

- Focused lifecycle, transaction coordinator, manifest, and SDK dispatch
suites: 105 tests passed, including single-connection saves, redacted
failure diagnostics, wakeups retained during idle drain, and per-event
retry deadlines.
- Complete SDK suite plus delivery database tests: 128 tests passed.
- Shared, database, and SDK typechecks passed. Direct server `tsc
--noEmit` passed against rebuilt SDK declarations.
- Full local `pnpm test:run` finished with 19,491 passed, 148 skipped,
and 6 failed tests across 5 files (plus two suite setup errors). This
run overlapped branch updates and is not final-head evidence: failures
included missing Cargo, local Git default-branch assumptions, and stale
in-process lifecycle modules. Final Apex-fix commit `75d028788` passed
all CI gates, including the full test shards, and received Apex 5/5 with
no unresolved comments.
- `pnpm -r typecheck` and `pnpm build` were attempted. Both stopped
because Cargo is unavailable locally. CI supplies the Rust toolchain.
- Local installation used the repository's documented lockfile fallback
because master has dependencies missing from its lockfile. No dependency
changes are included here.

## Risks

- Delivery is at least once. Plugins must re-read current state and make
external effects idempotent.
- Signals are process-local, like the other delivery queues. Startup
recovers committed rows. Independent database writers or multiple active
server processes require an explicit ownership and wake protocol.
- Apply migration `0340_open_warlock.sql` before running code that
records project deletion. Earlier deletions cannot be reconstructed.
- Automatic delivery selects plugins with company configuration rows.
`deferred` waits for a later startup, configuration change, or other
work notification.
- This does not replace required agent lifecycle participation or
establish that external mounts are unused.

## Model Used

OpenAI Codex (GPT-6), with tool-assisted code editing, code inspection,
and test execution.

## 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
- [ ] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
canary/v2026.1013.0-canary.13
2026-10-13 12:00:30 -07:00
Devin FoleyandPaperclip 5a6d0d08a7 fix: record verified workspace file recovery from tasks (#16104)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Recovery must preserve files and show the next operator action.
> - A stopped run can leave a file repair hold after its recovery action
is resolved.
> - The task notice shows that hold but has no form to record verified
file recovery.
> - A chat connection can also replace the file repair instruction with
a chat retry instruction.
> - This pull request adds a file recovery form and preserves the file
repair instruction.
> - The form records evidence for the original run and keeps the current
task status.

## Linked Issues or Issue Description

**What happened?**

A retained workspace file hold can block a task after its recovery
action is resolved. The task page offers no file recovery form. A chat
binding can hide the required file repair instruction.

**Expected behavior**

An authorized board member can record verified recovery of the original
files. The server checks the original stop proof. The task keeps its
current status and does not start another run. Chat instructions must
not replace file repair instructions.

**Steps to reproduce**

1. Create a stopped legacy run with a retained workspace recovery marker
and a resolved recovery action.
2. Open its task page, including a task with a chat connection.
3. Observe that the file hold has no supported form to record verified
recovery.

Refs: #15857, #15824, #16095. Those PRs address shutdown export, native
finalization and workspace source isolation. This PR uses the existing
file repair API.

## What Changed

- Add a board-only file recovery form with evidence and an explicit file
verification confirmation.
- Preserve the current task status when recording file recovery.
- Project whether the original recovery marker supports file recording.
- Keep file repair instructions when a task has a chat binding.
- Add UI, route and Storybook examples for success, denial and
chat-connected file holds.
- Document the recovery flow and update the affected Storybook catalog
entries.

## Verification

- Merged master `c8efdbfba43` and resolved both rounds of catalog/index
conflicts. Upstream review notes and classifications are preserved,
together with all four retained-file recovery examples and their stable
story IDs. Both fix branches also combine without merge conflicts or
catalog fingerprint drift.
- Passed locally after conflict resolution: 47 tests covering the file
recovery UI, execution blocker notice and retained workspace repair
route. The earlier ownership-route pass also covered 196 tests.
- Passed: UI token gates, the complete Storybook catalog check with no
drift errors, feature and agent map structure checks, and all 17
catalog/index script tests. Verification inventory counts match all 262
authored suites and 2,485 story IDs. The upstream production
verification obligations remain intact.
- Passed: full workspace typecheck, build and Storybook build on latest
head `10ac22b35d0a4fe469cf620914845c509046da48`. The built index retains
all four file-recovery story IDs.
- Latest head `10ac22b35d0a4fe469cf620914845c509046da48` has 54
successful checks and two intentionally skipped Storybook checks. Apex
is 5/5 on that exact commit, with no unresolved findings. The full
general/serialized suites and all eight browser shards passed in CI.
Local tests use the focused suites above. Storybook browser interactions
have not been executed locally.
- Manual check: open a task with a retained file hold. Verify that
evidence and confirmation are required. Record verified file recovery.
Confirm that its status stays unchanged and no run starts. Repeat
without board runtime access and with an unverified stop receipt.

## Risks

- The form records an operator attestation. It does not recover files
itself or prove external action outcomes.
- A stale source or missing stop proof must remain rejected by the
existing server route.
- No database migration or automatic task retry is added.

## Model Used

OpenAI GPT-6 (`gpt-6`), used through Codex with reasoning, repository
tools, code editing and test execution. The exact context window size is
not exposed by this environment.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 13:47:10 -05:00
Dotta e301c68d64 Merge Storybook coverage from current master 2026-10-13 13:40:52 -05:00
DottaandPaperclip c8efdbfba4 test(storybook): add production examples for feature map UI gaps (#16196)
## Thinking Path

> - Paperclip manages AI agents and their work.
> - The feature map records the user-facing capabilities.
> - Storybook uses the same feature index.
> - Step 2 found 49 UI capabilities with no authored examples.
> - This pull request adds shipped-component examples with isolated
fixtures.
> - The catalog records each example's states and remaining production
checks.

## Linked Issues or Issue Description

Refs: #16167. The verification inventory is merged; this follow-up now
targets master.

## What Changed

- Add 37 suites and 257 scenarios for all 49 UI capabilities from the
step-2 inventory. Keep existing stories and IDs.
- Use shipped pages and components. Simulate API replies, sockets,
props, and callbacks at their boundaries.
- Activate story API fixtures before the application providers read
data. Block unregistered API mutations and restore owned storage/fetch
state.
- Add browser checks for rendering, declared play assertions, fixture
reset, and selected mobile/theme states. Update the catalog and
verification inventory.

## Verification

- `pnpm -r typecheck`: passed.
- `pnpm build`: passed.
- UI Vitest suite: 730 files and 8,208 tests passed. Fixture boundary
tests: 4 passed.
- Map/catalog checks, 27 generator/map tests, and token gates: passed.
- `pnpm build-storybook`: passed. All 2,248 previous built entry IDs
remain present.
- Pre-reconciliation static browser suite: 260 checks passed (257
scenarios, token fixture reset, and two mobile/theme cases). All
non-play stories assert an explicit subject state; 129 play functions
passed.
- `pnpm test:run` could not complete on this Mac. Embedded PostgreSQL
exhausted host shared-memory allocation. The run also reported
native-runner test timeouts. Only this task's verified runner was
stopped; other jobs and host settings were preserved.
- Reconciled onto merged master `252d9b5077`. The six draft stories and
new same-browser reset regression passed (7 checks); 16
draft-persistence tests and UI typecheck passed. Static merge
verification: 32 affected-subject/draft checks passed, including
same-browser reset. Rebuilt Storybook retains all 2,248 original IDs in
its 2,517-entry index. Four additional play-result checks passed:
visible onboarding reset, pending probe, filtered-empty runs, and
optimistic queued-response removal. UI typecheck and 27 catalog/map
tests also passed. Final static browser suite on
`3fab35df8d912935fa86ce0de7d32d07e2b5f4c3`: all 261 checks passed (257
scenarios plus fixture-reset and mobile checks). Latest head
`3fab35df8d912935fa86ce0de7d32d07e2b5f4c3`: all 55 CI/status checks
passed; the two optional Storybook workflow jobs were skipped. Greptile
5/5 with no unresolved threads.
- No pinned Linux visual-baseline comparison or real provider journey is
claimed.

## Risks

Fixtures can drift from production contracts. The catalog records
inspected sources and their fingerprints. Capability links provide
initial isolated UI coverage; they do not certify every recipe variant,
real permissions, persistence, or provider behavior.

The new examples expose existing UI limits. Plugin discovery failure
stays on Loading. Document and environment-list reads lack dedicated
failure feedback; Cases and Inbox fall back to empty views after errors.
Goal alignment has display views but no assignment control. These
findings remain visible in the inventory.

## Model Used

OpenAI GPT-6 via Codex. The exact runtime deployment ID and context
window are not exposed in this session. Used code generation, shell
execution, and browser verification.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 13:24:09 -05:00
DottaandPaperclip 6c0eca8716 Merge current master and preserve qualification failure diagnostics
Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 13:14:03 -05:00
DottaandPaperclip 252d9b5077 docs(storybook): record verification routes for missing examples (#16167)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - The feature map describes product capabilities and verification
journeys.
> - The Storybook catalog links existing examples to those capabilities.
> - A capability without a story can need UI examples, CLI checks, or
browser checks.
> - This pull request records the required verification surface for all
60 current gaps.
> - The next Storybook pass can add useful examples without claiming
backend proof from mocks.

## Linked Issues or Issue Description

Refs #16154. Reconciles the new task-notification capability from
#16153.

The related PR search found no duplicate of this classification pass.
This change follows the merged association corrections. It does not add
product behavior or duplicate a roadmap feature.

## What Changed

- Add `maps/storybook-map/VERIFICATION.md` with all 60 unassociated
capabilities: 49 UI example gaps, eight CLI/operator operations, and
three browser verification boundaries.
- Record required UI states, separate production checks, source links,
and existing test starting points. Keep execution marked not run.
- Link the record from the catalog contract. Tell the maintenance skill
to keep its rows, counts, and source revision current.
- Regenerate the feature index for personal task notifications. Refresh
only the inspected recipe/index-dependent review fingerprints. Retain
all 223 suites, 2,212 authored IDs, associations, and classifications.
- Record the targeted association revisit. It found no additional
justified links.

## Verification

- `node scripts/storybook-catalog.mjs` and `node scripts/check-maps.mjs`
passed.
- All 27 catalog, feature-index, and map structural tests passed.
- The maintenance skill validator passed.
- A source check confirmed that the 60 unique rows match all non-guide
association gaps. All report, contract, and skill file links exist.
- `git diff --check` passed.
- Inspect the eight CLI/operator rows and three browser rows. UI/API
capabilities retain both obligations.
- Full repository typecheck, tests, build, Storybook build, and live
product journeys were not run locally for this documentation and
generated-data change. No live proof is claimed.

- Final head `a9ef9e8ebc1f41bb7047142704655d08b3e47be7`: all 57
checks/statuses are green (55 successful, two Storybook jobs skipped).
Greptile approved this head at 5/5. The review finding is resolved and
the PR is mergeable.

## Risks

- This source inventory can become stale as capabilities or associations
change. The maintenance skill requires refreshing its rows and source
revision.
- Existing test links identify starting points. They do not certify
complete or passing production coverage.
- There is no migration, permission change, product behavior change,
story removal, or new visual baseline.

## Model Used

OpenAI Codex with GPT-6 assisted with source review, documentation, and
checks. It used shell tools and read-only area agents. The runtime did
not expose an exact backend model revision 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
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
canary/v2026.1013.0-canary.12
2026-10-13 12:39:04 -05:00
DottaandPaperclip 0065d06474 Bound the existing Codex onboarding eval before task admission
Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 12:38:48 -05:00
DottaandPaperclip ccdc6754b2 fix: retain background preparation traces from unsampled requests (#16205)
Start preparation phase root traces independently of request sampling and link each phase to its trigger. Preserve operator root sampling, concurrent child context, and silent unconfigured behavior.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 12:23:48 -05:00
Nicky LeachandPaperclip da9af67415 Persist agent-owned instance secrets through lifecycle results (#16191)
## Thinking Path

> - Paperclip coordinates agents and controls when they can run.
> - Lifecycle plugins prepare and remove resources for each agent.
> - Those resources can require private connection credentials.
> - The current SDK can resolve configured secrets but cannot save these
credentials securely.
> - Ordinary company secrets can be bound to agents and do not provide
the required server-only boundary.
> - This change saves agent-owned instance secrets through the existing
local lifecycle result and native secret service.
> - The tenant can retain runtime credentials through restarts without a
separate encryption system or remote API.

## Linked Issues or Issue Description

**Subsystem affected**

Agent lifecycle, plugin contract, and native secret storage.

**Problem or motivation**

Lifecycle plugins need to save private runtime connection details for
the owning agent. Worker memory loses these details on restart. Plugin
state and company secrets do not provide a private runtime-only
boundary.

**Proposed solution**

Add optional instance-secret changes to lifecycle results. Save them
through the existing secret service and local encrypted provider before
accepting the result. Require company, agent, plugin, phase, operation,
revision, and current unexpired attempt ownership. Supply saved values
through the existing local preparation/resume request.

**Alternatives considered**

A separate encrypted store duplicates the native secret system. Generic
plugin company-secret writes proposed by #5007 do not supply agent
ownership or a server-only secret scope. This change does not add that
general write API.

**Roadmap alignment**

Extends the existing lifecycle contract from #15631. It does not add a
resource provider or select an execution backend.

## What Changed

- Add an instance scope to native secrets with mandatory agent/plugin
ownership, a company-qualified agent foreign key, and key uniqueness per
owner. Existing company and user scopes retain their constraints.
- Reuse native creation, rotation, deletion, secret versions, access
audit, and the local encrypted provider. Keep values out of company
catalogs, normal bindings, agent access, and public agent records.
- Accept local secret patches only after locking and checking the
current lifecycle operation and required plugin selection. Storage
failure or a stale reply cannot complete setup. Expired or replaced
attempt owners cannot overwrite a successor's credentials.
- Keep vault-import conflicts company-scoped. Protect instance-owned
account-home paths during failed device-login cleanup with a private,
fail-closed scan.
- Skip decryption on stop and cleanup so a lost key cannot block
removal. Cascade secret records when their agent or plugin is deleted.
- Log fixed provider diagnostics without raw errors that can contain
credentials. Document the local contract, runtime resolver, and
access-map exclusions. Retain the five latest migration snapshots
through the normal generator pruning.

## Verification

- 239 focused tests passed across agent-instance-secrets, lifecycle,
secrets-service, secrets-routes, plugin-secrets-handler, and
agent-device-login-routes. Used disposable PostgreSQL 18 clusters
through the existing test constructor seam because the bundled binary
cannot start on this macOS host. The temporary harness is outside git.
- Regression tests reproduced the vault-import conflict and missed
cleanup claimant before the fixes; both pass after the fixes.
- New coverage includes encrypted native versions, rotation, restart
recovery, company/agent/plugin isolation, ordinary-read and binding
denial, stale replies, storage failure, safe logging, cleanup without
the master key, and same-name secret isolation, native account-home
mutation guards, lease takeover/expiry, and live agent/plugin deletion
cascades.
- Direct server TypeScript check, DB/shared typechecks, migration
numbering/safety checks, module boundaries, and git diff check passed.
- Full workspace typecheck and build were attempted; both stop at the
missing local cargo toolchain. The full test command was started and
stopped after failures in unchanged native-runtime/workspace suites plus
bundled-PostgreSQL skips; it did not complete. CI must verify the full
toolchain paths.
- Current head `c0f8bfd12477ad509252ecd40e168a6c84dbeb36`: all 55 CI
checks passed, including the previously canceled e2e shard. Greptile
Apex reviewed this exact head at 5/5 with no unresolved threads. GitHub
reports the branch mergeable and clean.
- No live provider probe, production data access, or deployment.
Reviewed the diff for credentials, private references, and run
artifacts.

## Risks

Apply migration 0339_luxuriant_iron_monger.sql before deploying tenant
code. It adds nullable ownership columns, a partial unique index,
foreign keys, and a stricter scope constraint. Existing rows remain
valid. Keep the schema on application rollback. Preserve the existing
secrets master key through deployments and backup restoration.

The lifecycle request/result now has a sensitive, server-only field.
Plugins must never log it or return it to an agent or browser. Values
stay in the tenant database through the existing encryption provider.
Trusted runtime consumers must apply normal execution admission before
resolving them. Older hosts omit instanceSecrets; plugins that require
durable storage must reject those hosts.

## Model Used

OpenAI GPT-6 via Codex, with reasoning, repository inspection, code
editing, and local test execution. The exact serving model identifier
and context window are not exposed in this session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
canary/v2026.1013.0-canary.11
2026-10-13 10:13:42 -07:00
2a56e5c734 fix(ui): show soft budget incidents as warnings, not hard stops (#16201)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Budget policies limit what an agent, a project, or the organization
can spend.
> - At the warning threshold (80% by default), the server opens a soft
incident. It does not pause the scope. At 100%, it opens a hard incident
and pauses the scope.
> - The budget incident card always shows the hard-stop design. A soft
incident shows "agent hard stop", "This scope is paused", and a "Keep
paused" button.
> - Operators read this as a paused agent. The policy card and the
"Paused agents" counter for the same agent say something different.
> - This pull request shows soft incidents as warnings. Hard stops do
not change.
> - The benefit is that the Costs and Budgets pages give one consistent
and correct state.

## Linked Issues or Issue Description

I searched open and closed issues and pull requests for "budget
incident", "hard stop", "soft incident", and "BudgetIncidentCard". I
found no issue for this bug. Refs #14306: that open PR also changes
`BudgetIncidentCard`, for failed-action feedback. It does not change the
soft and hard labels. The two PRs can conflict in this file.

**What happened?**

An agent budget policy reached its warning threshold. The Audit →
Budgets page and the Audit → Costs overview showed the soft incident as
"AGENT HARD STOP" with the banner "This scope is paused. New heartbeats
will not start until you resolve the budget incident." The card showed
"Raise budget & resume" and "Keep paused". The agent was not paused. Its
policy card showed "Warning", and the "Paused agents" counter did not
count it.

**Expected behavior**

A soft incident looks like a warning. It says that work continues. Its
actions are "Raise budget" and "Dismiss warning". A hard incident keeps
the current design and actions.

**Steps to reproduce**

1. Create an agent budget policy with a $1,000 monthly limit and the
default 80% warning threshold.
2. Record $800 of cost for that agent.
3. Open Audit → Budgets.
4. Look at the active incident for that agent. It says "agent hard stop"
and "This scope is paused".

**Paperclip version or commit**

Seen on v2026.1012.0 (`bba6a45`). The same code is on `master` at
`721e87ac0`.

**Deployment mode**

local_trusted (not deployment-specific).

## What Changed

- `BudgetIncidentCard` reads `incident.thresholdType`. A `soft` incident
shows:
- The heading "<scope> budget warning", with amber styling and a warning
icon.
- The banner "Spending crossed the warning threshold. This warning does
not pause work."
- The actions "Raise budget" and "Dismiss warning". They call the same
handlers as before (`raise_budget_and_resume` and `keep_paused`). For a
soft incident, the server dismisses the incident for `keep_paused`, and
the resume step has no effect because the scope is not paused.
- A new-budget prefill of the current limit plus $10. Before, the
prefill was equal to the current limit, so "Raise budget" did not change
the limit.
- A `hard` incident does not change: the same heading, banner, styling,
prefill, and actions.
- The "Active incidents" description on the Costs page now covers
warnings and hard stops.
- New tests in `BudgetIncidentCard.test.tsx` cover a hard stop, a soft
warning, and a project hard stop.

## Verification

- `cd ui && npx vitest run src/components/BudgetIncidentCard.test.tsx`:
3 tests pass. Before the fix, the soft-warning test failed with
`expected 'agent hard stopOpen…' to contain 'agent budget warning'`.
- `cd ui && npx vitest run src/pages/Costs src/components/Budget`: 31
tests pass.
- Manual check in a running instance (v2026.1012.0 with this patch,
seeded with an agent at 100% and an agent at 80% of a $1,000 budget), in
light and dark themes:
- The 100% agent shows the red "Agent hard stop", "This scope is
paused", "Raise budget & resume", and "Keep paused".
- The 80% agent shows the amber "Agent budget warning", the warning
banner, a $1,010.00 prefill, "Raise budget", and "Dismiss warning".
  - "Paused agents: 1" agrees with the cards.
- `ui` typecheck: no errors in the changed files. The local run had
unrelated errors in `PluginOrganizationSwitcher` because the plugin SDK
was not built.

## Risks

- Low risk. The change is UI-only. Hard-stop rendering and behavior do
not change. No API, server, or data changes.
- The soft card now prefills a value above the current limit. Before, it
prefilled the current limit.
- PR #14306 changes the same component. One of the two PRs can need a
small rebase.

## Model Used

- Claude Opus 5.5 (`claude-opus-5-5`), Anthropic, through Claude Code
with tool use (shell, file edits, test runs, Playwright screenshot
capture). A human requested and reviewed the change.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes (no
`doc/` page describes this card, so no change was needed)
- [x] I have considered and documented any risks above
- [ ] All Paperclip CI gates are green
- [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Aron Prins <aronprins@icloud.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-13 10:12:49 -07:00
Dotta ca31623d36 Keep native setup probes independent of workspace instruction discovery 2026-10-13 11:49:42 -05:00
DottaandPaperclip e43af9770a refactor(server): isolate publication recovery and Board sends (#16192)
## Thinking Path

> - Paperclip publishes task messages through several chat providers.
> - Operator recovery must keep durable receipts and task authority
consistent.
> - The service combines shared publication transactions with provider
recovery details.
> - Provider-specific recovery belongs beside its transport
implementation.
> - This pull request extracts publication requests and resolution
workflows.
> - Shared workflows keep transaction ownership and delegate provider
operations.

## Linked Issues or Issue Description

Depends on #16187. Refs #16185, #16183, and #16180. Review against the
parent branch.

**What existing behavior does this improve?**
The structure of publication requests, Board sends, and operator
recovery.

**Current behavior**
Six public publication methods live in the main service and include
provider-specific transfer and receipt operations.

**Proposed behavior**
Move shared requests and resolution to publications modules. Move Teams
file resolution and Board preparation, Slack file receipts and Board
staging, and Photon retry records to their provider folders.

**Reason and benefit**
Provider recovery is easier to locate without moving transaction and
idempotency ownership into providers.

## What Changed

- Extract six public publication methods into two shared workflow
factories (629 and 467 lines).
- Reduce chat-channels.ts from 5,337 to 4,078 lines. The full stack
reduces it from 7,919 lines.
- Extract Teams transfer resolution and cold-runtime Board preparation.
- Extract Slack upload receipt resolution and Board send staging.
- Extract Photon operator retry records.
- Preserve the same public service API and keep provider operations in
the original transactions.

## Verification

- Merge preparation: replayed this stack onto current master after
#16180 landed. Preserve master's new Telegram scheduling methods and
connection-scoped Photon notifications. Server typecheck, callback
syntax audit, and module-boundary check passed. Fresh local integration
and wiring checks passed (1,318 tests). The dedicated Photon suite
passed 18 before and 18 after the conflict resolution. This final slice
was replayed onto merged #16187 with all chat-channel source unchanged.
Current-head CI and review are running. Earlier verification below
describes previous stack commits.

- Publication, attachment, Board send, and operator recovery baseline:
261 passed before and 261 passed after; 1,034 other cases excluded.
- Server typecheck, module-boundary check, and git diff --check passed.
- Syntax audit reconstructs all six public method bodies from the
provider helpers and matches the original AST. Unrelated service
functions and the public API match too.
- Final repository typecheck passed. Build passed. The broad local test
run encountered heartbeat fixture setup failures under the macOS
PostgreSQL shared-memory limit and was interrupted after 868 seconds
(exit 130). Four confirmed abandoned guard slots were reclaimed without
stopping active databases. The complete chat integration suite and
source-wiring checks passed separately (1,309 tests).
- Greptile rates current head 55417debfe 5/5 with zero inline findings.
All 55 CI checks pass on that head. Tests use local PostgreSQL and
fixture transports, not live provider execution.

- Previous stack validation on #16192 (55417debfe): repository typecheck
and build passed; all 1,295 chat integration cases plus 14 source-wiring
checks passed locally (1,309 total). All five PRs have current-head 5/5
reviews and 55 passing CI checks. The broad local pnpm test:run hit
PostgreSQL shared-memory fixture failures and was interrupted after 868
seconds (exit 130); it is not a local full-suite pass.

## Risks

Operator recovery can duplicate a send if receipt updates move out of
their transaction. The extracted helpers use the caller transaction.
Teams preparation remains outside Board locks, and repeated send
identities retain their existing receipt. Public method names and return
values stay the same.

## Model Used

OpenAI GPT-6 via Codex, with code execution and repository tools. The
precise serving variant and context-window size are not exposed in this
session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [ ] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 11:48:07 -05:00
DottaandPaperclip f18247b7e7 refactor(server): isolate durable chat wakeup workflows (#16187)
## Thinking Path

> - Paperclip accepts chat messages as durable task input.
> - Wakeups must preserve current company, identity, and task
permissions.
> - The main service mixes those shared checks with provider message
rules.
> - Shared wakeup workflows should own persistence and queue ordering.
> - This pull request extracts wakeup authorization, processing, and
notices.
> - Slack and GitHub rules move into their provider folders.

## Linked Issues or Issue Description

Depends on #16185. Refs #16183 and #16180. Review against the parent
branch. Related open #13620 covers durable chat wakeup feature work;
this PR only moves existing behavior.

**What existing behavior does this improve?**
The structure of durable inbound wakeup processing.

**Current behavior**
The service contains authorization, durable wake receipts, queue
notices, and provider authority details.

**Proposed behavior**
Use three cohesive inbound modules and provider-owned authority
functions.

**Reason and benefit**
The shared transaction and company checks stay together while provider
rules have a clear home.

## What Changed

- Move wakeup authorization, processing, and notices into inbound
modules (245, 418, and 377 lines).
- Move Slack mention checks and GitHub automatic-event admission and
acknowledgements into provider folders.
- Preserve lock order, durable receipt ordering, notice cursor lifetime,
and the live heartbeat dependency.
- Reduce chat-channels.ts from 6,340 to 5,337 lines, including blank-gap
cleanup.

## Verification

- Merge preparation: replayed this stack onto current master after
#16180 landed. Preserve master's new Telegram scheduling methods and
connection-scoped Photon notifications. Server typecheck, callback
syntax audit, and module-boundary check passed. Fresh local integration
and wiring checks passed (1,318 tests). The dedicated Photon suite
passed 18 before and 18 after the conflict resolution. This slice was
replayed onto merged #16185 with its chat-channel source unchanged.
Current-head CI and review are running. Earlier verification below
describes previous stack commits.

- Existing wakeup, queue, retry, and authorization integration cases:
212 passed before and 212 passed after; 1,083 other cases excluded.
- Server typecheck, module-boundary check, and git diff --check passed.
- Syntax-tree audit compares all 12 moved functions, cursor state,
retained service functions, and public API after explicit provider
delegations.
- The first three stack PRs have 55 passing CI checks and current-head
5/5 reviews.
- Final stack checks are recorded below. The first broad local run
encountered a PostgreSQL shared-memory fixture limit and was interrupted
after that failure.
- Greptile rates current head 1462819f53 5/5 with zero inline findings.
All 55 CI checks now pass. Initial CI failures: the first workspace job
hit EADDRINUSE in sandbox-callback-bridge.test.ts, and
cloud-auth.spec.ts hit a disposed Playwright response. Both jobs passed
on retry without source changes. Integration uses local PostgreSQL and
fixture provider transports, not live providers.

- Previous stack validation on #16192 (55417debfe): repository typecheck
and build passed; all 1,295 chat integration cases plus 14 source-wiring
checks passed locally (1,309 total). All five PRs have current-head 5/5
reviews and 55 passing CI checks. The broad local pnpm test:run hit
PostgreSQL shared-memory fixture failures and was interrupted after 868
seconds (exit 130); it is not a local full-suite pass.

## Risks

Authorization and wakeups must retain the same locks and transaction
scope. Factories receive narrow dependencies and initialize before their
consumers. The notice cursor stays per service. Shutdown and heartbeat
reads remain live. Provider helpers do not own transactions.

## Model Used

OpenAI GPT-6 via Codex, with code execution and repository tools. The
precise serving variant and context-window size are not exposed in this
session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [ ] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

Co-authored-by: Paperclip <noreply@paperclip.ing>
canary/v2026.1013.0-canary.10
2026-10-13 11:36:35 -05:00
DottaandPaperclip 721e87ac02 refactor(server): separate receiver ownership and provider callbacks (#16185)
## Thinking Path

> - Paperclip accepts provider callbacks as durable task input.
> - Runtime ownership prevents two servers from accepting the same
receiver stream.
> - Discord and Photon share the lease machinery but have different
callback details.
> - Moving that shared machinery into Discord would create the wrong
platform dependency.
> - This pull request extracts common receiver ownership and puts
provider callbacks in their own folders.
> - The service keeps startup and shutdown coordination.

## Linked Issues or Issue Description

Depends on #16183; review against the parent branch. Refs #16180 and
#16080. Related open work: #15532 changes Discord command reconciliation
scheduling. This extraction preserves existing scheduling.

**What existing behavior does this improve?**
The structure of shared receiver ownership and Discord/Photon runtime
callbacks.

**Current behavior**
The shared entry point mixes lease acquisition, renewal, provider
capability checks, and Photon checkpoint transactions.

**Proposed behavior**
Put the common lease operations in runtime/ownership.ts and the protocol
details in the provider folders.

**Reason and benefit**
The ownership lifetime stays explicit without making Photon depend on
Discord implementation code.

## What Changed

- Extract 11 receiver-ownership helpers into runtime/ownership.ts (397
lines). Expose only the operations used by the service.
- Extract Photon ownership checks and checkpoint callbacks (44 lines).
Retain the same runtime context object.
- Extract Discord command and capability reconciliation (112 lines).
- Keep the original service-owned lease map, runtime versions, stop
tasks, and shutdown sequence. Read shutdown and test overrides through
live accessors.
- Reduce chat-channels.ts from 6,880 to 6,340 lines, including removal
of blank gaps left by extractions.

## Verification

- Merge preparation: replayed this stack onto current master after
#16180 landed. Preserve master's new Telegram scheduling methods and
connection-scoped Photon notifications. Server typecheck, callback
syntax audit, and module-boundary check passed. Fresh local integration
and wiring checks passed (1,318 tests). The dedicated Photon suite
passed 18 before and 18 after the conflict resolution. Current head is
6d52aba35f; CI and review are running. Earlier verification below
describes the previous stack commits.

- Existing Discord, Photon, and runtime integration cases: 110 passed
before and 110 passed after; 1,185 other cases excluded.
- Server typecheck, module-boundary check, and git diff --check passed.
- Syntax-tree comparison: 11 ownership helpers, two Photon callback
bodies, Discord reconciliation, unrelated service functions, and the
full public API/shutdown return expression preserve structure.
Intentional binding changes are audited.
- Both preceding PRs have 55 passing CI checks and current-head 5/5
reviews.
- Repository typecheck and build passed earlier in this stack. Final
stack checks are recorded below. The first broad local run hit a macOS
PostgreSQL shared-memory fixture limit and was interrupted after that
failure.
- All 55 CI checks pass on df15f9dd9c. Greptile rates that head 5/5 with
no inline findings. Tests use real local persistence with fixture
runtimes; they do not prove live Discord or Photon execution.

- Previous stack validation on #16192 (55417debfe): repository typecheck
and build passed; all 1,295 chat integration cases plus 14 source-wiring
checks passed locally (1,309 total). All five PRs have current-head 5/5
reviews and 55 passing CI checks. The broad local pnpm test:run hit
PostgreSQL shared-memory fixture failures and was interrupted after 868
seconds (exit 130); it is not a local full-suite pass.

## Risks

Lease loss and partial startup can create overlapping receivers if
cleanup order changes. The service retains the same map objects and
shutdown ordering. The ownership module reads current shutdown state,
and Photon callbacks retain the exact mutable runtime context reference.
No new worker or timer starts during module initialization.

## Model Used

OpenAI GPT-6 via Codex, with code execution and repository tools. The
precise serving variant and context-window size are not exposed in this
session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [ ] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 11:17:21 -05:00
Nicky LeachandPaperclip c4e80ccdc8 chore(db): prune obsolete migration snapshots and document retention (#16194)
## Thinking Path

> - Paperclip uses versioned PostgreSQL migrations to preserve
application data.
> - Drizzle uses schema snapshots to generate future migrations.
> - The database package already prunes snapshots to the five newest
files.
> - PR #15749 added three snapshots but left eight in the resulting
tree.
> - This PR removes the three excess files and documents the retention
requirements.
> - Coding agents and Greptile receive the same scoped rule for future
migration changes.

## Linked Issues or Issue Description

Refs #15749. Related: #16191 includes overlapping snapshot cleanup with
its new migration. This PR isolates the existing excess and the
repository rule; it has no dependency on that feature.

**What happened?**

The migration metadata directory contains snapshots 0331–0338. The
existing pruning script retains only the newest five, but the older
three were left in master.

**Expected behavior**

Keep snapshots 0334–0338. Commit snapshot pruning alongside additions
and recheck the combined tree after rebases or merges. Preserve all SQL
migrations and journal entries.

**Steps to reproduce**

At master commit e3029c632, list
`packages/db/src/migrations/meta/*_snapshot.json`. There are eight
files. Run `pnpm --filter @paperclipai/db prune:snapshots`; snapshots
0331–0333 are removed.

**Paperclip version or commit**

e3029c632. Repository maintenance; deployment mode is not applicable.

## What Changed

- Remove snapshots 0331–0333 using the existing pruning script.
- Add `rules/database-migration-snapshots.mdc` with retention,
generation, rebase, preservation, and review requirements.
- Register the rule in `.greptile/files.json` with matching scope
patterns.

## Verification

- Existing `prune:snapshots` script completed successfully via `npm run
--prefix packages/db prune:snapshots`.
- Existing migration numbering and safety checks passed, run with the
available tsx loader. Safety reported only baseline-covered historical
findings.
- A local assertion check confirmed exactly snapshots 0334–0338 remain,
with retained snapshots and journal byte-for-byte equal to the base. SQL
migrations are unchanged.
- A local assertion check verified that rule globs equal the Greptile
scope, all manifest paths exist, representative migration/schema files
match, and unrelated server/UI files do not match.
- `node scripts/check-maps.mjs` and `git diff --check` passed.
- Full application typecheck, test suite, and build were not run for
this metadata and review-rule-only change. No runtime code, schema, SQL,
or dependencies changed.

## Risks

Low risk. The five newest schema snapshots remain unchanged. Database
migration history is preserved. The rule supplies agent and review
guidance; it does not add a new CI enforcement gate. Recheck retention
if another migration merges first.

## Model Used

OpenAI GPT-6 via Codex, with reasoning and shell/file tools. The exact
runtime model ID and context-window size are not exposed in this
session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [ ] All Paperclip CI gates are green
- [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 09:08:04 -07:00
DottaandPaperclip ba00e9ef1a refactor(server): isolate provider webhook handling (#16183)
## Thinking Path

> - Paperclip connects provider messages to governed agent work.
> - Webhooks must authenticate and persist messages before acknowledging
them.
> - The shared service still contains GitHub and Slack protocol details.
> - The platform-boundary rule places those details in provider folders.
> - This pull request extracts provider webhook handling behind typed
methods.
> - The service retains dispatch, runtime selection, and durable
lifecycle recording.

## Linked Issues or Issue Description

Depends on #16180; review this PR against its parent branch. Refs
#16080. Related open work: #16163 changes GitHub automatic-author
policy. This extraction preserves that policy implementation.

**What existing behavior does this improve?**
The ownership and readability of GitHub and Slack webhook handling.

**Current behavior**
The shared service implements GitHub signatures, replay fences,
automatic event messages, and Slack callback verification.

**Proposed behavior**
Place those details in the respective provider folders and keep the
common dispatcher small.

**Reason and benefit**
Provider code can be reviewed without reading the shared task service.

## What Changed

- Extract GitHub request-local deadline and replay scope (60 lines).
- Extract GitHub authentication and durable-ingress coordination (280
lines).
- Extract GitHub event admission, message construction, and policy-skip
receipts (140 lines).
- Extract Slack workspace validation and authenticated callback
observation (131 lines).
- Keep the same service-owned background task set and GitHub provenance
maps. Forward late-initialized callbacks without reading them during
construction.
- Reduce chat-channels.ts from 7,383 to 6,880 lines: 503 net lines
removed.

## Verification

- Merge preparation: replayed this stack onto current master after
#16180 landed. Preserve master's new Telegram scheduling methods and
connection-scoped Photon notifications. Server typecheck, callback
syntax audit, and module-boundary check passed. Fresh integration, CI,
and current-head review are running. Earlier verification below
describes the previous stack commits.

- Parent baseline: 544 selected GitHub, Slack, and webhook integration
cases passed; 751 other cases excluded.
- Initial extracted run: 543 passed and one idle-queue scan assertion
failed. The idle-queue case passed separately on both the parent and
extracted code. Its publication implementation is unchanged. The full
selected-suite retry passed all 544 cases; the initial failure remains
documented and its cause is not established.
- Server typecheck, module-boundary check, and git diff --check passed.
- Syntax-tree comparison verifies unchanged request-scope logic, durable
ingress, leased authentication, event handling, workspace validation,
and callback recording. All unrelated service functions remain
unchanged.
- Repository typecheck and production build passed for the parent
extraction. Full-stack verification will run at the final handoff. The
first broad local run hit a macOS PostgreSQL shared-memory fixture limit
and was interrupted after that failure.
- All 55 current-head CI checks passed. Greptile: 5/5 on f74ecb5094,
with zero inline findings. No live third-party execution is claimed.

- Previous stack validation on #16192 (55417debfe): repository typecheck
and build passed; all 1,295 chat integration cases plus 14 source-wiring
checks passed locally (1,309 total). All five PRs have current-head 5/5
reviews and 55 passing CI checks. The broad local pnpm test:run hit
PostgreSQL shared-memory fixture failures and was interrupted after 868
seconds (exit 130); it is not a local full-suite pass.

## Risks

Moving callback code can change initialization timing or lose
request-scoped state. The new factories retain live option getters, the
exact runtime context and provenance maps, and typed forwarding for late
initialization. Authentication stays inside the existing credential
lease. The common lifecycle write still completes before returning
provider success.

## Model Used

OpenAI GPT-6 via Codex, with code execution and repository tools. The
precise serving variant and context-window size are not exposed in this
session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [ ] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 11:02:19 -05:00
DottaandPaperclip 30bc9e40ce Align native setup isolation and finish shared runtime pickers
Use the server-resolved sandbox transport for native setup, retaining local and SSH isolation and stripping injected flags. Preserve the complete local and managed E2E roster and existing graders. Replace the remaining scoped native dropdowns with the shared picker without changing saved runner or account choices.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 10:59:57 -05:00
DottaandPaperclip 1e64c875b2 refactor(server): move Slack recovery into channel modules (#16180)
## Thinking Path

> - Paperclip manages AI agents and their work.
> - Chat channels connect provider messages to governed tasks.
> - Slack task recovery still lives in the shared channel service.
> - Its provider sends and recovery state belong in the Slack folder.
> - This pull request moves Slack task-start resolution and
Board-message recovery into two modules.
> - The service keeps the public dispatcher and the existing shared
authorization owners.

## Linked Issues or Issue Description

Refs #16080. Related open work: #15421 changes linked-user task trust;
#15532 changes Discord reconciliation. This extraction changes neither
behavior.

**What existing behavior does this improve?**
The ownership and readability of Slack task-start and Board-message
recovery.

**Current behavior**
The 7,919-line shared service implements Slack retry and cancellation
details.

**Proposed behavior**
Keep those implementations in the Slack folder. Preserve public methods
and all state transitions.

**Reason and benefit**
The channel boundary follows rules/chat-channel-platform-boundaries.mdc
and makes Slack recovery easier to review.

## What Changed

- Move Slack task-start operator resolution into
slack/task-start-resolution.ts (488 lines).
- Move the durable Slack Board-message worker into
slack/board-messages.ts (104 lines).
- Keep initial endpoint/action lookup and provider-effect dispatch in
the service. Pass the original endpoint record to avoid a new read or
race.
- Preserve live reads of heartbeat and deferred-processing options.
- Reduce chat-channels.ts from 7,919 to 7,383 lines: 536 net lines
removed.

## Verification

- Existing Slack integration cases: 282 passed before and 282 passed
after; 1,013 non-Slack cases excluded by the filter.
- pnpm -r typecheck: passed. The first sandboxed attempt could not
create a local tsx IPC socket; the permitted rerun passed.
- pnpm build: passed.
- Module-boundary check and git diff --check: passed.
- Normalized TypeScript AST comparison: moved Board worker and Slack
resolution tail unchanged; all other service function declarations
unchanged.
- All 55 current-head CI checks passed; two optional Storybook checks
skipped. Greptile: 5/5 on 1c1bf5d019, with zero inline findings.
- The broad local pnpm test:run encountered PostgreSQL fixture startup
failure because the macOS shared-memory ID limit was exhausted (the chat
integration file did not execute in that run). The focused 282-case
before/after runs passed. Two verified abandoned, unattached 56-byte
guard segments were reclaimed; no active database was stopped. The broad
run remains unverified and its output is retained.
- Existing public-service integration tests use real local database
fixtures and injected provider transports; no live Slack execution is
claimed.

- Final stack validation on #16192 (55417debfe): repository typecheck
and build passed; all 1,295 chat integration cases plus 14 source-wiring
checks passed locally (1,309 total). All five PRs have current-head 5/5
reviews and 55 passing CI checks. The broad local pnpm test:run hit
PostgreSQL shared-memory fixture failures and was interrupted after 868
seconds (exit 130); it is not a local full-suite pass.

## Risks

Credential lease loss, ambiguous sends, and scheduler failure can cause
duplicate work if ordering changes. The extraction keeps the lease,
transaction, provider-confirmed receipt, and resume marker sequence
intact. No schema, API, dependency, or workflow change.

## Model Used

OpenAI GPT-6 via Codex, with code execution and repository tools. The
precise serving variant and context-window size are not exposed in this
session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 10:50:23 -05:00
DottaandPaperclip 9cb3e157b3 docs: keep routine product work in the harness (#16193)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - The runtime and server handle routine execution and recovery.
> - Product flows can expose internal steps that the system can handle
safely.
> - Users then have to operate infrastructure to achieve their original
goal.
> - This pull request adds a short rule that assigns this work to the
harness.
> - The benefit is a calm product experience with useful details and
real choices.

## Linked Issues or Issue Description

**Issue type**

Missing documentation.

**Where is the issue?**

`rules/` and the repository review configuration.

**What's wrong?**

The repository has no shared product rule for harness responsibility and
useful user-facing detail. Recovery can become a user checklist even
when the system knows the next safe step. Related implementation:
#15824.

**Suggested fix**

Require the harness to perform routine work within its existing
authority. Require visible controls and details to serve a real decision
or useful outcome. Keep progress truthful and apply the rule to changed
flows.

## What Changed

- Add the short product rule in
`rules/product-harness-responsibility.mdc`.
- Register it as a repository-wide review rule in
`.greptile/files.json`.
- Link the rule from `rules/README.md`.

## Verification

- `git diff --check origin/master...HEAD` passed.
- Node assertions passed for rule frontmatter, unique reviewer
registration, repository-wide scope, all registered file paths and the
README link.
- The diff contains only three rule/documentation files. No application
behavior changes. Application typecheck, tests and build were not run
for this documentation change.
- Review the rule's scope and read its four product requirements and
review criterion. All applicable CI checks passed on head `89803a6cd7`.
Greptile gave 5/5 with no unresolved findings.

## Risks

The rule affects future product design and review. It applies to changed
flows and does not require unrelated redesigns. Existing permissions,
approvals and runtime safeguards remain in force. No migration or
deployment is required.

## Model Used

OpenAI Codex, GPT-6, with repository inspection, tool use and code
execution. The exact serving model ID and context-window size were not
exposed in this session. The user edited and approved the final short
rule.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 10:50:03 -05:00
DottaandPaperclip e67db42dc9 docs: define heartbeat execution design principles (#16190)
## Thinking Path

> - Paperclip coordinates AI agents and their work.
> - Heartbeat controls when that work starts, who owns execution, and
how it settles.
> - The extracted modules need shared architectural guidance as they
evolve.
> - Rules should protect those boundaries without freezing the current
implementation.
> - This PR adds scoped heartbeat principles for contributors and
reviewers.
> - The rule helps future changes preserve execution authority and
recoverable work.

## Linked Issues or Issue Description

**Issue type**

Missing documentation.

**Where is the issue?**

The heartbeat service has a module map but no scoped architectural rule
under `rules/`.

**What's wrong?**

Changes span admission, execution, completion, and recovery. Reviewers
need shared principles for authority, ownership, and settlement across
these boundaries.

**Suggested fix**

Add a concise heartbeat rule, route contributors to it from `AGENTS.md`,
and register the same scope for Greptile. Keep implementation details in
the code and existing developer documentation.

Related: #16172 established scoped repository rules. #15984 completed
the latest heartbeat extraction. Searches found no duplicate
heartbeat-guidelines PR.

## What Changed

- Add `rules/heartbeat-execution-boundaries.mdc` with a folder guide, a
concise map of existing module responsibilities, and six design
principles.
- Keep `heartbeat.ts` focused on coordination: extend an existing owner
or extract cohesive modules when new behavior would substantially grow
it, with tests and explicit contracts.
- Cover current execution authority, explicit ownership, distinct
completion obligations, recovery intent, durable state, and visible
uncertainty.
- Register matching paths in `.greptile/files.json` and link the rule
from `AGENTS.md` and `doc/DEVELOPING.md`.
- Include behavioral review criteria and flag substantial coordinator
growth or mixed responsibilities while allowing justified cohesion and
ordering exceptions.

## Verification

- Parsed the rule YAML and Greptile JSON. Confirmed that the rule globs
exactly match the Greptile scope.
- Checked 14 positive and negative scope cases with Node's
`path.matchesGlob`, including nested heartbeat modules, sibling
services, regression tests, and unrelated paths.
- Verified local links and heading anchors, including the existing
heartbeat module map, and confirmed all 20 named modules exist. Reviewed
their responsibility descriptions against the current code and developer
documentation.
- `git diff origin/master --check` passed after rebasing onto current
master.
- Reviewed the principles against the current heartbeat code and tests.
The diff changes four documentation and review-configuration files.
- Application typecheck, runtime tests, and build were not run locally.
This worktree has no installed dependencies. CI and review status are
tracked below.

- CI passed on `a17f5a2cc82b7bb7e4629d4a2d9e3a766e27c5c0`: 55 successful
checks, two skipped, no failures or pending checks. This includes
typecheck, build, server/runner tests, and browser tests.
- Greptile reviewed the same commit at 5/5 with no findings or
unresolved review threads.

## Risks

The rule can influence later implementation and review decisions. It
applies to changed heartbeat behavior and permits justified contract
changes with tests. The scoped globs exclude unrelated subsystems. This
PR does not change application behavior. Hosted loading of the new rule
has not been demonstrated by the local configuration checks.

## Model Used

OpenAI GPT-6 Astra (`gpt-6-astra`) via Codex, with repository
inspection, file editing, and command execution. The context-window size
was not exposed to this session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass (scoped rule/configuration
checks described above)
- [x] I have added or updated tests where applicable
(documentation/configuration validation; no runtime changes)
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 10:48:17 -05:00
DottaandPaperclip 448db859e3 Merge master recovery updates into Codex defaults
Preserve current recovery and controller preparation behavior, both Storybook histories, and the reviewed Codex onboarding source. Targeted controls and direct TypeScript checks pass; exact-head hosted and live qualification remain required.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 10:33:51 -05:00
DottaandPaperclip 7956056b2f Merge current master and qualify managed Codex onboarding
Reconcile actual master 833769ab with preserved Codex 1a0ca662 and reviewed private onboarding preparation a758b226. Preserve the merged prerequisite and current native/security changes, saved runner choices, managed-image qualification and current Storybook identities.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 10:21:06 -05:00
DottaandPaperclip e3029c632b feat: trace controller preparation before agent dispatch (#16178)
Trace eleven controller preparation operations with the existing hashed run correlation and preserve errors without exporting exception text. Verify asynchronous child-span parenting with a real OpenTelemetry SDK and context manager.

Full exact-head CI and E2E passed after one documented fixture-startup retry; Greptile Apex 5/5.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
canary/v2026.1013.0-canary.9
2026-10-13 10:16:10 -05:00
0b0e53029f fix: recover saved workspace results automatically (#15824)
## Thinking Path

- Paperclip preserves accepted agent results before workspace copyback
and result commitment.
- A replaced controller can leave a physical copyback owner receipt
behind. A lost database lock or expired lease cannot prove that its
tar/Git children stopped.
- Infrastructure recovery should belong to the runtime and deployment
harness; task users should not investigate processes or attest shutdown.
- New receipts record the exact deployment. The harness independently
verifies that deployment fully stopped and signs a short-lived proof
bound to the stack, run, owner and deployment.
- The existing guarded reconciler then finishes the same accepted result
without a new agent turn. Legacy receipts retain the documented
administrator API after independent platform verification.

## Linked Issues or Issue Description

**What happened?**

An accepted native result can remain at `workspace_finalizing` with an
abandoned physical copyback owner. Repeated recovery sweeps could
replace specific instructions with advice to start new agent work. The
first version of this PR exposed a shutdown-evidence form in the task;
that asks end users to resolve infrastructure details.

**Expected behavior**

Automatically verify and recover the exact stopped deployment, preserve
the original accepted result and existing approval/monitor waits, and
show only a quiet task status. Unknown or live workers must remain
fenced. Older receipts without platform identity need independently
verified operator assistance through the administrator API.

**Steps to reproduce**

1. Persist an accepted native result and a copyback receipt from a prior
controller.
2. Replace that deployment before workspace finalization commits.
3. Let the normal finalization reconciler revisit the saved result.
4. With a platform-bound receipt and a fully stopped deployment,
recovery should finish automatically. With missing, live, unverifiable
or changed ownership, it must not write files or create another provider
turn.

Related public work: #14402 introduced copyback ownership; #9687 handles
dead-run finalize barriers; #15795 handles terminal stale-run cleanup.
This change addresses an accepted result whose physical copyback owner
prevents commitment.

## What Changed

- Record Railway project, environment, service and deployment identity
on new physical copyback owners.
- Request read-only platform verification from the managed cloud
harness. Require an Ed25519 stop receipt with a disjoint purpose,
configured signing key, exact stack/run/owner/deployment binding and
valid expiry.
- Keep live, unknown, malformed, unavailable and legacy owners fenced.
Compare the whole prior receipt during ownership takeover, under the
existing dedicated advisory lock.
- Persist platform proof and audit automatic takeover. Resume normal
finalization of the same saved result, preserving task ownership,
approved boundaries, monitors and pending confirmations.
- Remove process metadata, shutdown evidence, confirmation checkboxes
and infrastructure-repair forms from task views. Suppress the duplicate
technical owner-recovery card. Show “Restoring saved work…” only from
server-confirmed recovery or queued operator recovery; platform identity
alone shows the operator-assistance fallback. Remove the status when
recovery resolves.
- Share current-task, current-running-execution, accepted-result,
authoritative-reviewer and newer-execution checks between automatic and
operator recovery. Validate after the provider lookup, atomically with
the owner claim, and again before file publication; closed or superseded
tasks cannot start copyback.
- Keep the separately authorized exact-owner API for operator recovery
of legacy receipts, with active-lock, live-controller, stale-result and
newer-execution rejection. Generic dismissal cannot bypass the copyback
fence.
- Replace obsolete form stories with production-backed automatic,
queued, legacy, completed and mobile examples; retain stable suite IDs.
Update the operator runbook and scoped Storybook catalog.

## Verification

- Red/green: new platform-proof tests failed before implementation; the
database takeover regression failed against the original ownership
guard; reduced-UI assertions failed against the original form. All pass
after the changes.
- Passed: 59 physical-owner/finalization database tests using isolated
PostgreSQL, including real reconciler commitment from all three
saved-result phases through both automatic and operator recovery. They
preserve result identity, exact saved file bytes, pending approval and
overdue monitor waits, and create no new run or wake request. Unknown
evidence and changed ownership remain fenced.
- Passed: 162 focused proof, cloud identity, recovery route,
recovery-card and reduced-UI tests.
- Passed: full workspace typecheck and build, final server/UI
typechecks, token gates, and Storybook build.
- Browser inspection: desktop task composition shows only the quiet
status; completed example removes it and retains the approval-wait
message. Mobile shows the existing bottom navigation with no horizontal
overflow. These are fixture UI observations, not live provider
acceptance.
- A companion harness change implements the actual provider check,
signed receipts, server-token authentication and bounded/coalesced
provider reads. Its full typecheck and test suite passed: 3,240 passed,
92 skipped, zero failures. This application alone cannot enable platform
verification.
- The updated full application `pnpm test:run` was stopped after
repeated local embedded-Postgres startup failures; it is not claimed
green. The same affected recovery suites pass against isolated
PostgreSQL. CI passed on final head `9ad5c3529e`: 54 successful checks,
two intentional skips, and successful legacy Snyk status. Greptile is
5/5 with no unresolved findings.
- Global Storybook catalog validation is green: 225 files, 2,224
stories. Its 17 catalog/index tests pass. Master was merged and the
inherited index metadata was reconciled after source review.
- Review correction red/green: two UI and two database assertions
reproduced misleading progress / missing server recovery state; all pass
after server-confirmed state was added. All 153 focused server tests and
68 UI tests pass on the final recovery code, including repeated-sweep
idempotence. Full workspace typecheck/build, token gates and Storybook
build also pass.
- Safety regression red/green: stale-task copyback and publication tests
failed against the previous guard. The final suite covers changes during
proof lookup, closed/cancelled tasks, replaced execution/checkout, newer
and queued legacy runs, reassignment and rejected/unbound results, plus
the real reconciler selecting closed or superseded tasks. Files remain
untouched and no workspace operation starts.
- No staging mutations, deployment, live provider probes or live
production recovery were performed. The three historical receipts lack
deployment identity and still require independent operator proof.

## Risks

Automatic takeover requires the companion harness release and configured
runtime-identity keys. Deploying only this application leaves
unavailable evidence fenced. Legacy receipts are not retrospectively
assigned a deployment identity. An authorized operator can still make an
incorrect attestation through the fallback API; its administrator gate
and exact-owner safeguards remain. Provider history that is missing or
deeper than the bounded lookup defers automatic recovery. Copyback can
still fail under its existing retained-workspace policy.

No migration, telemetry change or cloud provider credential delivery is
required. The companion harness PR also has passing CI and a 5/5 review;
neither branch is deployed.

## Model Used

OpenAI Codex, GPT-6, with repository inspection, browser verification,
tool use and code execution. The exact serving model ID and
context-window size were not exposed in this session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change and contains no internal
Paperclip ticket id or instance-derived details
- [x] I have run the relevant tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
Co-authored-by: Paperclip <paperclip@paperclip.ing>
Co-authored-by: Devin Foley <devin@paperclip.ing>
2026-10-13 10:14:45 -05:00
DottaandPaperclip dfc00fb650 docs: record published canary qualification and Codex merge finish line
Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 10:00:42 -05:00
Devin FoleyandPaperclip 833769ab55 perf(chat): schedule Telegram maintenance from commits and deadlines (#16094)
Replace periodic Telegram discovery and maintenance scans with bounded startup recovery, connection-specific commit notifications, and durable action deadlines. Preserve ownership, inactive subscription parking, retry and cleanup recovery, and atomic credential binding updates.

Verified full typecheck/build, 30 focused scheduler tests, 12 database-backed recovery cases, all current-head CI checks, and Greptile 5/5 with no unresolved threads.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 07:55:27 -07:00
DottaandPaperclip 69f4bfc3c5 docs: add external bot integration skill (#16181)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - External agents need a connection, a work lifecycle, and clear
authority.
> - The Dot integration exposed gaps in setup, idle work, recovery, and
Cloud delivery.
> - Future integrations need a practical procedure that preserves those
lessons.
> - This pull request adds a core skill and six focused reference
documents.
> - The skill gives contributors concrete prompts, test cases, and
failure diagnostics.

## Linked Issues or Issue Description

**Issue type**

Missing documentation.

**Where is the issue?**

Repository contributor skills for external agent integration.

**What's wrong?**

The integration process has no single reusable guide for provider
discovery, both work directions, setup, managed Runner execution, and
live proof. Lessons from Dot are spread across implementation changes.

**Suggested fix**

Add `create-external-bot-integration` under `.agents/skills`. Keep the
core workflow short. Put detailed contracts, examples, tests,
diagnostics, and dated evidence in references.

Related public implementation: Refs #15402, #15414, #15581, #15691,
#15722, #15734. A search found no duplicate skill PR.

## What Changed

- Add a core skill for external agents and its Codex interface metadata.
- Add references for the release contract, Runner architecture,
onboarding, qualification tests, deployment, and the Dot case study.
- Include idle intake, native tool use, scoped authority, receipt
recovery, and resource cleanup.
- Mark provider facts and code paths as dated evidence. Use public PRs
for the source trail.
- Change only eight files under
`.agents/skills/create-external-bot-integration`.

## Verification

- Skill validator: passed.
- Interface metadata, Markdown fences, and 49 local links and anchors:
passed.
- `git diff --check`: passed.
- PR file scope: verified that all eight paths are inside the skill
folder.
- `pnpm build` and `pnpm -r typecheck`: passed in the isolated worktree.
- `pnpm exec vitest run --project @paperclipai/skills-catalog
packages/skills-catalog/src/shipped-catalog.test.ts`: 10 tests passed
after the description-budget fix.
- The broad local `pnpm test:run` attempt reported 12 native-session
lease test failures. It is not a passing full-suite result. One isolated
lease case passed. The PR changes no runtime files.
- Final commit `bd7aed82f623ee279c800af2b8b87f7bedd6be5c`: all GitHub
checks completed, with 55 success results and 2 skipped results.
- Greptile reviewed that exact commit at 5/5. There are no open review
threads.

## Risks

- Provider behavior and code paths can change. The skill requires
current code and official documentation checks before use.
- The case study describes one integration campaign. It does not claim
that every provider supports the same transport or capabilities.
- This change adds contributor instructions and metadata. It changes no
application code or database schema.

## Model Used

OpenAI Codex, GPT-6, with reasoning, filesystem access, shell tools, and
code review support. The exact serving endpoint ID and context window
size are not exposed in this session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-13 09:45:19 -05:00
Devin FoleyandPaperclip a0651c96f8 Add database-free process liveness probes (#16101)
Expose process liveness without database or credential queries while preserving hostname and runtime identity guards. Deep health and sleep/wake readiness checks retain their existing behavior.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-13 07:43:46 -07:00