Commit Graph
557 Commits
Author SHA1 Message Date
Nicky LeachandClaude Opus 5.5 83c6832ccb fix(build): typecheck package, Playwright, and e2e test files in CI (#18839)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - Runner, plugin, and Playwright tests verify how those agents run,
connect, and appear in the board
> - Most package tsconfigs exclude tests, and Vitest strips types, so a
type error in those tests fails nothing
> - The tests drifted to 803 real type errors, and some of those errors
hid assertions that checked nothing
> - paperclipai/paperclip#18739 and paperclipai/paperclip#18738 check
the server test tree and four test projects, but not these files
> - This pull request adds a required check for these test files, fixes
every error, and fails CI if a test file is in no program
> - The benefit is that a type error in any test file outside
`server/src` now fails CI

## Linked Issues or Issue Description

Refs #18739
Refs #18738

**What happened?**

517 test files were in no program that required CI checks. A type error
in those files did not fail CI.

**Expected behavior**

CI fails on a type error in any test file.

**Steps to reproduce**

Add `export const value: number = "text";` to a test file under
`packages/paperclip-runner/src` on master. CI stays green, because
`tsconfig.json` excludes test files and Vitest strips types.

**Measured gap**

Each row is a program with its tests included, on one thread. File and
error counts are for head `7d4b5e907a`. Memory peaks were measured
before the two latest merges of master.

| Group | Test files | Real errors | Peak |
| --- | ---: | ---: | ---: |
| `paperclip-runner` Node source | 290 | 644 | 1.09 GiB |
| `paperclip-runner` surfaces | 9 | 12 | 0.42 GiB |
| `paperclip-runner` devtools and examples | 14 | 0 | 0.68 GiB |
| `sandbox-providers/kubernetes` | 21 | 65 | 0.44 GiB |
| 8 other sandbox providers and `bridge-template` | 32 | 4 | 0.34 GiB |
| `plugins/sdk` | 22 | 15 | 0.41 GiB |
| `plugin-workspace-diff` | 5 | 0 | 0.37 GiB |
| `plugin-orchestration-smoke-example` | 1 | 1 | 0.15 GiB |
| `kv-demo-mcp-server` | 3 | 0 | 0.13 GiB |
| `packages/db` scripts | 1 | 0 | 1.01 GiB |
| 8 Playwright suites under `tests/` | 52 | 25 | 1.72 GiB |
| `tests/runner-acceptance` | 3 | 0 | 0.58 GiB |
| `tests/e2e`, through layer declarations | 63 | 37 | at most 1.59 GiB |
| `ui` `AttentionInteractionResolver.test.tsx` | 1 | 0 | n/a |
| **Total** | **517** | **803** | |

27 of the 803 errors came from master while this pull request was open.
Each merge of master brought new test code that no check had read.

Errors that were config errors, not real errors:

- One TS2688 for each provider, because the root install does not
install provider dependencies.
- 9 in the Runner Node program (TS7016 and TS6059).
- 2 in `tsconfig.browser.json`. TypeScript 7 removed `baseUrl`, so that
config was invalid.
- 213 in the Playwright suites (`@/*` aliases and Vite types).
- About 60 in `tests/e2e` (import extensions and aliases).

`packages/plugins/create-paperclip-plugin` has no gap. Its tsconfig
excludes its test, but `cli/tsconfig.json` reaches that test through an
import. `server/test-baselines` also has no gap, because
`tests/lifecycle-baseline` reads it.

## What Changed

- Added `scripts/typecheck-test-programs.mjs` and its tests. The
`Typecheck + Release Registry` job runs it. It checks each program in
`PROGRAMS` on one thread.
- The script fails if a tracked `*.test.ts(x)` or `*.spec.ts(x)` file
outside `server/src` is in no program. The compiler file list decides
this, because `include` drops `foo.test.tsx` when `foo.test.ts` exists.
- Added a `tsconfig.test.json` to each uncovered package, and
`tests/tsconfig.playwright.json`.
- Added `tests/e2e` to `PROJECTS` in
`scripts/typecheck-test-projects.mjs`, with a `tsconfig.json` and a
`tsconfig.layers.json`.
- Added `scripts/typecheck-sandbox-providers`. It is a small workspace
that installs provider SDKs from one lockfile. I did not add a lockfile
inside each provider, because
`scripts/build-standalone-public-packages.mjs` uses a frozen install
when one exists, and that changes what a release resolves.
- Corrected `packages/paperclip-runner/tsconfig.browser.json` for
TypeScript 7.
- Set `rootDir` to `..` in
`packages/paperclip-runner/tsconfig.test.json`, because one Runner test
imports from `packages/adapter-utils/src`. The program does not emit
files, so this changes no build output.
- Moved the Kubernetes provider from `vitest ^3.2.4` to `^4.1.8`, the
version the other providers use. Vitest 3 requires `tinypool ^1.1.1`,
which has two critical advisories (GHSA-85c8-ppgw-ccpr and
GHSA-5gmw-xhrv-c9v3). The first patched version is 2.1.2. Its tests have
the same result on both versions: 189 passed, and the same 12
`file-sync` tests failed.
- Moved the Kubernetes provider from `zod ^3.24.2` to `^4.6.6`, and gave
its two `z.record` calls a key schema. This is the only production
change, and it stays in this pull request. See "Production change for
review".
- Renamed `AttentionInteractionResolver.test.ts` to
`AttentionInteractionResolver.replace.test.ts`, so TypeScript reads the
`.test.tsx` beside it.
- Fixed all 803 errors, with changes to test files and test support
only. The fix for `contracts/native-execution.test.ts` is the same as
the fix in paperclipai/paperclip#18739, so those two changes merge
cleanly.
- Updated `doc/DEVELOPING.md`.

This pull request does not edit `server/scripts/typecheck-layers.mjs`.
paperclipai/paperclip#18739 and paperclipai/paperclip#18738 have both
merged, and this branch includes them.

### Production change for review

The new lockfile made dependency review flag `zod@3.25.76` as a
high-severity advisory (GHSA-mrhx-c7xc-m3w5). The first patched version
is 4.6.6, so 3.x has no fix. The published Kubernetes plugin uses zod to
validate operator config. The zod 3 source does not compile against zod
4, so a typecheck-only override cannot fix this.

The existing tests do not prove this change, because they also passed
with the invalid one-argument `z.record`. So I parsed 45 inputs with the
same schema on zod 3.25.76 and zod 4.6.7:

| Result | Inputs | Detail |
| --- | ---: | --- |
| Identical | 23 | Includes defaults, valid config, and a `__proto__`
key |
| Same outcome, new error wording | 21 | For example, `Invalid url` is
now `Invalid URL`. `validateConfig` shows this text to operators. |
| Different outcome | 1 | `jobTtlSecondsAfterFinished: 2 ** 60` was
valid and is now rejected. The new limit is `Number.MAX_SAFE_INTEGER`. |

I did not test this against a real cluster.

The decision is to keep this change in this pull request. Since then,
paperclipai/paperclip#17364 has moved the rest of the repository to zod
4.6.x, so the Kubernetes plugin now matches it.

### Behavior change for review

`reducedMotion` under `use` is not a Playwright option. It had no effect
in 11 configs and 2 `test.use` calls, so those suites ran with
`no-preference`. The options are now under `contextOptions`, so reduced
motion now takes effect. `app-shell-design.spec.ts` asserts a real
transition, so it now asks for `no-preference` itself.

The baseline manifest has `snapshotCount: 0`, so this invalidates no
published baseline. A frozen trial reference PNG can differ.

### Findings

These are product questions. I did not change them, and I did not hide
them with casts:

1. **`PrpEvent` and its schema disagree.** The TypeScript type in
`src/protocol/replay-contract.ts` requires `normalizedSessionId`. The
`required` list in `protocol/schemas/event.schema.json` does not include
it. `validatePrpEvent` accepts events that the type forbids.
2. **`requestCheckboxConfirmation` is stricter than its runtime.** It
uses the output type, so plugin authors must pass `continuationPolicy`
and `allowDeclineReason`, although the schema gives them defaults.
`z.input` would fix this.
3. **`RetainedRunnerdMaintenanceInput.backend.kind` is a free string.**
The quarantine domain comes from `descriptor.kind`, but the release uses
`proof.backend.kind`. If they differ,
`completeRetainedNativeSessionCleanup` returns 0 and the quarantine
stays. The production caller passes `"runner"` today, so this is not a
live bug.
4. **`CodexHarnessSession.close(input?)` is optional, but the contract
requires `{ reason }`.**

These are tests that verified nothing. I corrected them, and they pass:

- `backends/native-instruction-measurement.test.ts` filtered on
`placement === "core"`, which is not a valid placement. It measured an
empty tool list. It now measures 14 tools.
- `drivers/acpx/codex-acpx-driver.test.ts` checked for `usage.updated`,
which is not an event type.
- The `hostFixture()` helper in `drivers/acpx/runtime-host.test.ts`
ignored two overrides, so
`expect(prepareSandbox).not.toHaveBeenCalled()` could not fail.
- `live/live-session.test.ts` set `agent: "pi"` before a spread that
overwrote it.
- `native-distribution-integrity.test.ts` passed an AbortSignal where
`openCommand` expects `{ signal }`.

These are gaps that this pull request does not close:

- **The root lockfile still has some old zod versions.**
paperclipai/paperclip#17364 moved the direct zod dependencies to 4.6.x.
`pnpm-lock.yaml` still resolves `zod@3.25.76`, `4.1.11`, and `4.4.3`,
which are below the patched 4.6.6.
`packages/paperclip-runner/scripts/pi-distribution/package.json` pins
`zod` to `3.25.76`, and some agent SDKs resolve `4.4.3`. Dependency
review does not flag them, because this pull request does not add them.
- **Dead GitHub coverage.** `chat-adapters-ui-providers.spec.ts`
returned early for GitHub, so four later `provider === "github"`
branches never ran. I removed them. They included the private key file
and paste match, and the reconnect flow. Nothing asserts those behaviors
in that spec now.
- **Provider tests do not run in CI.** The root `vitest.config.ts` lists
only Daytona. The other 8 providers, `bridge-template` included, are
typechecked now, but CI does not run their tests.
- **One `packages/db` test never runs.**
`scripts/clean-poisoned-claude-sessions.test.ts` is outside the
`include` of `packages/db/vitest.config.ts`.
- **`plugin-orchestration-smoke-example` does not collect.**
`@paperclipai/shared` is not linked in its `node_modules`. It passes 3
of 3 with an alias.

## Verification

Run these commands:

```sh
node scripts/typecheck-test-programs.mjs --low-memory
pnpm --filter @paperclipai/server typecheck
node scripts/typecheck-test-projects.mjs --low-memory --reuse-declarations
node --test scripts/typecheck-test-programs.test.mjs
```

Results on macOS (arm64), Node 26.12. CI uses Node 24, and its
`Typecheck + Release Registry` job also passes. At head `7d4b5e907a`,
the test programs, `tests/e2e`, and the script tests pass again with 0
errors. The times and peaks below come from the run before the two
latest merges of master:

| Check | Result |
| --- | --- |
| Test programs, `--low-memory` | Exit 0, 0 errors, 42 seconds, peak
1.78 GiB |
| Server layers, low memory | Exit 0, 0 errors, 38 seconds, peak 3.41
GiB |
| Test projects, including `tests/e2e` | Exit 0, 0 errors, 13 seconds,
peak 1.59 GiB |
| Script tests | 12 passed |
| Injected type error in each of 23 places | Each one failed its program
with TS2322 |
| Coverage check | 0 unchecked files, 10 seconds |

I did not run this in a 4 GiB container. The peaks above are `maximum
resident set size` for the largest single process.

**Runtime check of the fixes.** Types do not prove that a test still
works, so I ran the suites before the two latest merges of master:

| Suite | Result |
| --- | --- |
| Runner, full suite | 4,885 passed, 3 failed, 13 skipped |
| Sandbox providers, 10 packages | 939 passed, 12 failed, 36 skipped |
| Plugin SDK | 200 passed |
| `kv-demo-mcp-server` | 12 passed |
| Renamed UI test and its sibling | 4 passed |

All 15 failures exist without these fixes or come from the local
machine:

- **3 Cursor Cloud timeouts.** `artifact-delivery.test.ts` has 1 and
`cursor-cloud-driver.test.ts` has 2. They time out in a full local run,
and all 133 tests in those files with `codex-security-config.test.ts`
pass when run alone. They fail in the same way with those two files at
their unedited versions.
- **12 Kubernetes `file-sync.test.ts` failures.** They fail in the same
way before and after the fixes. The first failure is that
`/proc/self/fd` does not exist on macOS.

After each of the two latest merges of master, I ran only the Runner
test files that I changed:

| Merge | Result |
| --- | --- |
| `885c249cb9`, 8 files | 534 passed |
| `7d4b5e907a`, 7 files | 672 passed, 16 failed |

The 16 failures are in the two `source-reconciliation` test files. They
fail in the same way with master's unedited versions of those files. 15
of them fail with `ACPX sidecar exited at initialize`, so I think my
local build of the Rust and sidecar binaries is out of date. I did not
rebuild them to check. CI builds them from scratch, and all Runner jobs
pass in CI at `7d4b5e907a`.

**Not run:**

- `tests/e2e` and the 8 Playwright suites need a server, so most of them
have only compile checks. `playwright test --list` loads 308 tests from
the main e2e config.
- `packages/plugins/sandbox-providers/kubernetes/test/integration` needs
a cluster, so it has only compile checks.
- I did not run the full `pnpm test:run` or root `pnpm build`. Required
CI runs them.

**Reduced motion.** I ran 6 motion-sensitive Storybook specs in system
Chrome with a temporary config, once with `reduce` and once with
`no-preference`. Both runs had 45 passed and the same 5 failed. So
reduced motion did not change those results. The 5 failures do not
depend on motion. At least one comes from the browser, because system
Chrome prints `oklch(55.6% 0 0)` where the test expects `oklch(0.556 0
0)`. I did not run the other Storybook specs. The `storybook-visual`
label runs that workflow.

## Risks

- **A new lockfile to maintain.** A change to a provider `package.json`
now fails the typecheck job until someone refreshes
`scripts/typecheck-sandbox-providers/pnpm-lock.yaml`. The failure
message gives the command.
- **The job has a new install.** The step downloads provider SDKs, so it
depends on the npm registry. It uses `--frozen-lockfile` and
`--ignore-scripts`.
- **The local install replaces provider `node_modules`.** A contributor
with a standalone provider install must reinstall that provider after
running the script.
- **Reduced motion can change Storybook results.** See "Behavior change
for review". That workflow is not part of required CI.
- **Kubernetes plugin validation changed.** A release of this plugin
ships zod 4. Error wording changes, and very large integers are now
rejected. See "Production change for review".
- **Master moves fast.** Each merge of master brought new test code with
type errors, 27 so far. After this merges, the check reports those
errors in the pull request that adds them.

## Model Used

- Provider: Anthropic Claude, through Claude Code
- Model: Claude Opus 5.5 (`claude-opus-5-5`)
- Capabilities: tool use, code execution, and subagents for the type
fixes in separate files

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [ ] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived
details. The app generated the branch name.
- [ ] I have run tests locally and they pass. See the failures explained
in Verification.
- [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: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-06 07:33:59 -08:00
DottaandClaude Opus 5.5 2b2004bf50 test(runner-e2e): gate completion briefs inside the run's own task directory (#19475)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - Agent Chat returns delegated-task completions to the chat that
started them, and the runner E2E `completion-updates` suite checks this
with real providers
> - The restart cell
(`completion-updates.runner-codex.local.handoff-completion-restart`)
failed before its server restart with "Timed out waiting for worker
waiting while originating chat is idle"
> - Since project-optional task workspaces (#15749), a task in a project
without a workspace runs in its isolated task directory. A native chat
runs in its isolated conversation directory. Native Codex can read only
that directory.
> - The fixture still wrote its brief wait scripts into the managed
project workspace and the agent home. Codex got EPERM on both scripts,
wrote the note from the task record, and finished. The worker never
reached the gate, so the setup poll timed out.
> - This pull request makes the waits name only cwd-relative files and
publishes each brief into the run's own isolated task directory
> - The benefit is that the restart cell reaches its real boundary again
(durable Done, source provider held at the gate, server restart) and
tests restart recovery instead of a stale fixture path

## Linked Issues or Issue Description

**What happened?**
The runner E2E cell
`completion-updates.runner-codex.local.handoff-completion-restart` timed
out in setup. The run ledger shows both agents report
`permission_denied` (EPERM) for `node .../wait-for-brief-*.cjs`. The
worker run cwd was `<instance>/isolated-workspaces/<company>/<issue>`.
The fixture wrote the script to the managed project workspace and the
agent home.

**What did you expect to happen?**
The worker waits at the brief gate while the chat is idle. Then the cell
releases the brief, holds the completion reply at its gate, and restarts
the server.

**Steps to reproduce**
`pnpm test:e2e:runner -- --max-automatic-retries 0 --id
completion-updates.runner-codex.local.handoff-completion-restart` on
master `6cafcaf89b`.

**Classification**
Test defect. The failure happens before the restart. Workspace isolation
is the intended product behavior.

## What Changed

- `tests/runner-e2e/chat-stories.ts`: add `workspaceChatBrief(nonce,
timeoutMs)`. It returns a bounded `node -e` command that reads and
writes only cwd-relative files, plus `at(dir)` to find the gate and
ready files in a workspace.
- `tests/runner-e2e/completion-update-flow.ts`: the worker and
completion instructions use that command. The fixture reads readiness
from, and publishes briefs to, `isolated-workspaces/<company>/<issue>`
for each delegated task and the source chat. The setup poll state now
records the worker run cwd. Cleanup releases every wait that is still
open.
- `tests/runner-e2e/chat-stories.test.ts`: regression test. It runs the
command from a temporary cwd, checks that the command names no host
path, and checks the nonce and timeout bounds. It was red before the
helper existed.
- `tests/runner-e2e/catalog.ts`: bump the `completion-updates`
definition to version 28 and set `workerBriefWorkspace:
"run-isolated-task-directory"`.
- `tests/runner-e2e/README.md`: describe the new brief location.

## Verification

- `npx vitest run --config tests/runner-e2e/vitest.config.ts
tests/runner-e2e/chat-stories.test.ts
tests/runner-e2e/completion-updates.test.ts
tests/runner-e2e/catalog.test.ts`: 108 passed.
- Live cell, native Codex `gpt-5.6-sol`, local runner: `pnpm
test:e2e:runner -- --max-automatic-retries 0 --id
completion-updates.runner-codex.local.handoff-completion-restart`.
Results are in the Verification comment below.
- Two earlier local attempts in this worktree failed in setup with
`harness_test_failed`. The worktree did not have a built
`paperclip-runnerd`. After `pnpm --filter @paperclipai/paperclip-runner
build`, the cell passed.

## Risks

- Low risk. The change is in test fixtures only. No product code
changes.
- The idle, busy, and multiple cells share this flow. They now also use
the isolated task directory. That is the same directory the product
selects for these tasks.
- The agent must run the inline command from its cwd. The instructions
say this, and the command fails closed (no gate) if the agent runs it
elsewhere.

## Model Used

- Claude Opus 5.5 (`claude-opus-5-5`), Anthropic, via Claude Code with
tool use (shell, file edits). Default context window. Extended reasoning
on.

## 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: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-06 09:32:50 -06:00
DottaandClaude Opus 5.5 a12fcb8f26 fix(runner-e2e): find saved slugify source in a workspace project folder (#19471)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - The runner E2E everyday `recover-controller` case proves that a task
survives a control-plane restart.
> - The case waits for an active run with a saved `slugify.py` before it
kills the controller.
> - The harness looked for `slugify.py` only at the workspace root.
> - The task brief asks for `slugify.py` "in the project workspace". It
does not ask for the root. ACPX Claude saved it in
`slugify-tool/slugify.py`.
> - The harness timed out before the restart, so the case did not test
restart recovery at all.
> - This pull request makes the harness find the saved source in a
bounded set of project folders.
> - The benefit is that the case reaches its real fault boundary for
agents that make a project folder.

## Linked Issues or Issue Description

**What happened?**
The local cell
`everyday-workflows.runner-acpx-claude.local.recover-controller` failed
with "Timed out waiting for active run with saved source". The agent
finished the task and delivered a correct ZIP. It saved `slugify.py` in
`<workspace>/slugify-tool/`. The harness read only
`<workspace>/slugify.py`, so it never saw the saved source. It also
recorded `saved-source-unavailable-at-final-capture`. The controller
restart never happened.

**Expected behavior**
The harness finds the source that the agent saved in the project
workspace. Then it kills the controller while the run is active and
grades the recovery.

**Steps to reproduce**
1. Run `pnpm test:e2e:runner -- --max-automatic-retries 0 --id
everyday-workflows.runner-acpx-claude.local.recover-controller` with a
provider that saves the project in a subfolder.
2. See the timeout before the `controller-restarted` timeline entry.

**Paperclip version or commit**
`master` at `6cafcaf89b` (also reproduced at `d87f6fa4c2`).

## What Changed

- Added `readWorkspaceSource` in
`tests/runner-e2e/everyday-interruption.ts`. It reads `slugify.py` at
the workspace root first. Then it searches subfolders to depth 2,
shallowest and alphabetical first. It skips hidden folders,
`node_modules`, `__pycache__` and `venv`.
- `recordSource` (the stop-redirect and recover-controller boundaries)
and the final local source capture in
`tests/runner-e2e/everyday-flow.ts` use this helper.
- The stop-redirect workspace snapshot (`workspaceFiles`) now includes
the same bounded project folders. A stop check therefore still sees
edits when the project is below the root.
- Added `tests/runner-e2e/everyday-interruption.test.ts`.

## Verification

- Red before the fix: `npx vitest run --config
tests/runner-e2e/vitest.config.ts everyday-interruption` failed 2 of 4
tests (the nested-folder cases returned `undefined`).
- Green after the fix: the same command passes 4 of 4.
- `pnpm test:e2e:runner:typecheck` passes.
- Live rerun of the cell after the fix (local, native ACPX Claude,
`claude-sonnet-5`): the harness observed the active run with saved
source, submitted the follow-up, and restarted the controller
(`source-saved-before-interruption` with `active: true`, then
`controller-restarted`). The original timeout did not occur.
- Two valid live reruns after the fix both reached the restart. Both
still did not pass. After the restart, the interrupted ACPX turn ended
as `native_provider_terminal_failed: Provider turn failed`. In the
second rerun the task stayed Blocked with the follow-up comment still
queued and a Retry offered. This is a separate product signature. It is
not in the scope of this harness fix. A follow-up handles it (see
Risks).
- One earlier rerun failed before the task started because the new
worktree had no built runner binary (`paperclip_runner_binary_missing`).
That was local setup only. The runner was then built with `pnpm --filter
@paperclipai/paperclip-runner build`.

## Risks

- Low risk. The change is test-harness only.
- If a workspace has several `slugify.py` files, the harness picks the
root copy, else the shallowest copy. A stale copy in another folder
could be chosen. The search depth and skip list keep this bounded.
- Known remaining failure in the same cell (separate signature): after a
hard controller restart, the ACPX runner restore path
(`acpx_provider_backend.rs`, `restore_session_if_needed`) closes the
in-flight turn with `code: acpx_active_turn_recovery_closed` and no
`error` object. The run shows the generic "Provider turn failed". The
Codex fix in #15297 gives Codex a recoverable
`provider_turn_lost_on_restore` cause and a same-conversation
continuation. ACPX does not have this yet.

> 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

- Claude Opus 5.5 (Anthropic), model ID `claude-opus-5-5`, used through
Claude Code with tool use (shell, file edit) for diagnosis, the
regression test, the fix, and live reruns.

## 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 (not
applicable: test-harness-only change)
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

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

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-06 09:24:33 -06:00
DottaandClaude Opus 5.5 7e6d882558 fix(runner-e2e): require Daytona image lock digest; name expired overhead allowance (#19467)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - Runner qualification uses a Daytona runner image and a nightly
Runner Full-Stack E2E workflow
> - The nightly workflow fails at "Validate catalog and select cells",
and a local image build fails at `sha256sum -c`
> - Operators cannot build a current Daytona image for restart tests
until both failures are understood
> - This pull request removes a stale Dockerfile lock digest default,
fixes the local recipes, and makes the nightly failure name its real
cause
> - The benefit is that a local build fails clearly when the digest is
missing, and an expired overhead allowance is obvious from the log

## Linked Issues or Issue Description

**What happened?**
1. The nightly `Runner Full-Stack E2E` runs 41997383733 and 42190298486
fail in "Validate catalog and select cells". The log shows
`digest-mismatch: error`, but that line is only the input list of
`actions/download-artifact`. The real error is `Operating overhead
allowance needs review before paid admission`. The repository variable
`RUNNER_E2E_OPERATING_OVERHEAD_JSON` has `expiresAt:
2026-11-03T19:49:53Z`. `scheduledOperatingOverhead` rejects an allowance
that expires within 4 hours. Manual dispatch (run 42046147744) does not
use the scheduled overhead path, so it passed this job.
2. `docker/daytona-runner/Dockerfile` set `ARG
PAPERCLIP_RUNNER_LOCK_SHA256=342a01e4…`. That value went stale when
`pnpm-lock.yaml` changed (#19443). The local recipes in
`tests/runner-e2e/README.md` and `docker/daytona-runner/README.md` did
not pass the argument, so local builds failed with a confusing checksum
mismatch.

**Expected behavior**
A local build computes and passes the lockfile digest. A missing digest
fails by name. An expired overhead allowance tells the operator which
allowance expired and which variable to renew.

**Steps to reproduce**
1. Run `gh run view 42190298486 --log` and read the "Validate catalog
and select cells" job.
2. Follow the old "## Daytona image" recipe in
`tests/runner-e2e/README.md` on current master.

## What Changed

- `docker/daytona-runner/Dockerfile`: remove the fixed
`PAPERCLIP_RUNNER_LOCK_SHA256` default. Reject a missing or non-SHA-256
value by name before `sha256sum -c` and before installation. CI already
passes the real value.
- `tests/runner-e2e/README.md` and `docker/daytona-runner/README.md`:
compute `shasum -a 256 pnpm-lock.yaml` and pass
`PAPERCLIP_RUNNER_LOCK_SHA256` in the local build recipes. Replace the
text about a "fixed Dockerfile default".
- `tests/runner-e2e/daytona-image.test.ts`: new test. It requires a
default-free `ARG`, the shape check before the checksum, and the
argument in every documented local recipe.
- `tests/runner-e2e/operating-overhead.ts`: the scheduled admission
error now names the allowance reference, its validity window, the 4-hour
margin, and `RUNNER_E2E_OPERATING_OVERHEAD_JSON`. The check itself is
unchanged.

## Verification

- `node node_modules/vitest/vitest.mjs run --config
tests/runner-e2e/vitest.config.ts
tests/runner-e2e/operating-overhead.test.ts
tests/runner-e2e/daytona-image.test.ts
tests/runner-e2e/scheduled-operations.test.ts
tests/runner-e2e/cost-ledger.test.ts`: 55 passed.
- `pnpm test:e2e:runner:typecheck`: passed.
- `pnpm verify`: exit 2 (README is a global CI input). Required CI
supplies broad coverage.
- `tests/runner-e2e/workflow-security.test.ts` has 5 local failures on
files that this PR does not touch (`pr-trusted.yml`,
`chat-catalog-testops-case.yml`). They are not caused by this change.
- I did not run a Docker build or a paid campaign.

## Risks

- Low risk. Any external script that builds this Dockerfile without
`PAPERCLIP_RUNNER_LOCK_SHA256` now fails with a clear message. Before,
it failed with a checksum mismatch whenever the lockfile changed. Both
CI build paths already pass the argument.
- The Dockerfile is an image content-ID input, so the next image gets a
new content tag. Current master needs a new image anyway.
- The nightly workflow stays red until an operator reviews and renews
`RUNNER_E2E_OPERATING_OVERHEAD_JSON`. This PR does not renew the
allowance, because that is a reviewed spend decision.
- Scheduled runs set `needs_daytona=false`, so the nightly run does not
publish a Daytona image even when the catalog passes. A current image
comes from a manual dispatch that selects Daytona cells.

## Model Used

- Claude Opus 5.5 (`claude-opus-5-5`), Anthropic, used through Claude
Code with tool use (shell, file edits, GitHub CLI).

## 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: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-06 09:08:59 -06:00
DottaandClaude Opus 5.5 d87f6fa4c2 test(runner-e2e): add staging-soak reliability cases to everyday workflows (#19455)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - The paid runner E2E suite (`tests/runner-e2e`) drives the real
browser, server, native runner, provider and Daytona
> - A manual staging soak found about nine reliability bugs (S47–S55,
H2, U9). Each fix got unit or integration tests
> - The end-to-end journeys that exposed the bugs existed only as ad-hoc
browser scripts, so a regression could return without a signal
> - These journeys are expensive, so they must not run per PR or in
`--all`. They must run on demand before a release
> - This pull request adds the journeys to the existing
`everyday-workflows` suite as an explicit `reliability` group
> - The benefit is one command that runs the whole reliability set
before a release or after a risky runner change

## Linked Issues or Issue Description

**What is the problem?**
The staging-soak scenarios that found S47–S55, H2 and U9 are not
repeatable. They were ad-hoc browser scripts on staging.

**Why does it matter?**
Without a repeatable end-to-end case, a reliability regression (stalled
follow-ups, duplicate execution, dead Retry, hangs after silent
commands) can return without a signal.

**What is the proposed solution?**
Add the scenarios to the paid `everyday-workflows` suite as
explicit-only cases with independent graders and a selectable
`reliability` group.

Refs #19370, #19355, #19354, #19407, #19419, #19394, #19421, #19431 (the
related fixes).

## What Changed

- `everyday-reliability-cases.ts`: seven new cases
(`interrupt-redirect`, `reassign-midrun`, `three-turn-revise`,
`long-silent-command`, `tree-pause-release`, `queue-steer`,
`queued-across-restart`), their soak signatures, prompts, bounds and the
explicit matrix.
- `everyday-reliability-flow.ts`: browser and public-API drivers for
each journey. A shared watcher records `executionBlocker`,
`interruption` and execution projections while it waits. It uses an
offered Retry at most once (never while an automatic retry is
scheduled).
- `everyday-reliability.ts`: pure graders. They encode the product rule:
interrupted work resumes automatically or offers a Retry that works on
first use. A send-a-message blocker, a dead or repeated Retry, a silent
stall, or duplicate execution fails.
- `types.ts` / `selectors.ts`: new optional `explicitGroup` on a task.
Such a task is selected only by its group, `--case`, or an exact `--id`.
`--all`, the plain suite and generic selectors skip it. `--list` still
shows it.
- `catalog.ts`: the suite gets the reliability tasks, the released
Grok/Kimi/Pi facades (only for `long-silent-command`), a per-turn
Daytona override for `three-turn-revise`, the `reliability` and `slow`
groups, definition version 11, and a computed `expectedMatrixSize` (52 →
62).
- `everyday-flow.ts`: a narrow hook calls the scenario driver after task
creation. Riley is created for the reassign and tree cases. The
reliability checks are added after settlement.
- `everyday-observations.ts`: an allowed interrupted run may end
`operator_interrupted` or `issue_reassigned`. Lifecycle checks accept a
declared reassigned parent owner.
- `live-fixtures.ts`: reliability cells get the existing 1,000-cent
company and lead-agent hard stop.
- Tests: new `everyday-reliability.test.ts` (selection exclusion,
matrix, credentials, and calibrated pass/fail cases for every grader).
Updated counts in `catalog.test.ts`, `everyday.test.ts` and
`installed-cli.test.ts`.
- Docs: new "Staging-soak reliability group" section in
`EVERYDAY-WORKFLOWS.md` (cases, signatures, run commands, cadence,
coverage boundary) and a link from `doc/evals.md`.

`everyday-flow.ts` was already over 1,000 lines. This PR adds only about
20 lines of wiring there. The scenario logic is in the new modules.

Matrix (10 cells, all Daytona, single attempt): one `runner-codex`
(gpt-5.6-sol) cell per case, plus `runner-acpx-grok`, `runner-acpx-kimi`
and `runner-acpx-pi` for `long-silent-command`.

Run command:

```sh
pnpm test:e2e:runner -- --suite everyday-workflows --group reliability --max-parallel 2
```

## Verification

- `pnpm test:e2e:runner:typecheck` passes.
- `node node_modules/vitest/vitest.mjs run --config
tests/runner-e2e/vitest.config.ts everyday catalog installed-cli
selectors support.test`: 15 files, 362 tests pass.
- The full runner-e2e Vitest run has the same 14 failures with and
without this change (`controller-outage`, `operating-receipts`,
`pi-controls-evidence`, `pi-file-evidence`, `workflow-security`). These
fail on the base commit in this local environment too.
- `pnpm test:e2e:runner -- --list --suite everyday-workflows --group
reliability` lists exactly the ten cells.
- `--all`, `--suite everyday-workflows` (still 52 cells),
profile/environment selectors and the daily/weekly scheduled selections
contain no reliability cell. A test asserts this.
- Not run: the paid cells. They need provider and Daytona credentials.
The first paid run of the group is the acceptance step.

## Risks

- The drivers have not run against a live stack. A first paid run can
expose harness timing or selector issues (for example, how fast the
queued Interrupt control appears). The failure then names the stalled
step and keeps `reliability-observations.json`.
- `long-silent-command` does not inject a runner connection loss. The
named-cause contract is checked only if a loss happens naturally.
- The Grok/Kimi/Pi facades run as ordinary released profiles. If one
returns to pending qualification, it drops out of the group and the
matrix size follows.
- No product code changes. Existing everyday cells keep their selection
and checks. The suite definition hash changes because the suite
definition changed.

> 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

- Claude Opus 5.5 (`claude-opus-5-5`), Anthropic, via Claude Code with
tool use (shell, file edit, code execution). Standard context window.

## 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

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

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-06 08:37:22 -06:00
github-actions[bot]andlockfile-bot 523818ea9b chore(lockfile): refresh pnpm-lock.yaml (#19443)
## Thinking Path

> - Paperclip uses a dependency lock for reproducible builds.
> - Dependency changes on master need matching lock entries.
> - Paid eval reports also pin a reviewed offline correction.
> - Reports must install before paid model work starts.
> - This automated PR keeps the lock and report proof together.

## Linked Issues or Issue Description

**What happened?**

Dependency manifests on master changed after the last committed lock
refresh.

**Expected behavior**

Frozen installs must match those manifests. Eval reports must retain
matching offline lock proof.

**Steps to reproduce**

Run a frozen install before and after this lock refresh.

## What Changed

- Refresh the dependency lock from the manifests on master.
- Include the matching offline report correction and hashes.

## Verification

- Pinned pnpm resolution completed with lifecycle scripts disabled.
- The report proof refresh accepted the reviewed committed baseline.
- The workflow rejected changes outside the lock and report proof files.

## Risks

The lockfile bot merges this PR without CI or review when every added
package version is at least 3 days old on npm. Otherwise the PR waits
for a maintainer, and the daily refresh tries again. The bot merges only
the exact commit this workflow generated from manifests already reviewed
on master. Unknown report lock baselines remain blocked. This update
changes no permissions or paid enable gates.

## Model Used

None — generated by pnpm and the deterministic report-lock updater.

## Checklist

- [x] Thinking path and problem description included
- [x] Generated lock and matching report proof included
- [x] Release-age gate decides between bot merge and maintainer review

Co-authored-by: lockfile-bot <lockfile-bot@users.noreply.github.com>
2026-11-06 12:19:36 +00:00
DottaandPaperclip 8836a71113 test(testops): pin calibrated secret acknowledgment source (#19428)
## Thinking Path

> - Paperclip lets people manage agents and inspect saved work.
> - Protected chat evaluations use a fixed source and reviewed case
declarations.
> - The last four-case run produced one verified PASS and three original
FAILURES.
> - Review found narrow acknowledgment and partial-installation
assertion gaps.
> - Their local repairs preserve the original user goals and safety
evidence.
> - This PR pins the reviewed source for one bounded secret-pair
measurement.
> - A final uniform-ten measurement on that same source is still
required.

## Linked Issues or Issue Description

Refs: #19423, #19325, #19416, #19093, #19084, #19112.
The core and full-catalog PRs remain open and unmerged.

**What happened?**

Launch 3310 retains one original PASS and three original FAILURES. Case
53 used the
same undismissed form correctly. Company rejected a valid ordered
save/ACK card
before human entry. Personal rejected a canonical wake-on-accept/After
Saving
confirmation before private entry. Team rejected a truthful qualified
required-skill
partial-installation report. No original result is regraded.

**What did you expect to happen?**

Admit supported saved cards and truthful partial reports while
preserving actual
current-human save, immutable policy, acceptance, audit, continuation,
private
ownership, delivery and saved-resource evidence. Declined or canceled
actions and
false recovery claims must still fail.

**Steps to reproduce**

Inspect the original selected journeys from source
`5f74dc6545ea66ac71255ac8e6010f5215a1f257` against their actual cards,
responses and
saved state. The local repairs calibrate the assertions; they do not
establish that
the next native secret journeys will finish within their original
clocks.

## What Changed

- Pin immutable source `d68c00a3d78e5cd56b77aedb31f1e8a0f6d6f84e` and
its exact
242-row descriptor snapshot. Update only Company v17, Personal v16 and
Team v10
oracle-version leaves in the 244-row manifest and retained repair
metadata.
- Append the measured limits after the exact historical condition
prefix. Keep
  every runtime condition and dependency list unchanged.
- Keep all 244 YAML identities, queries, contexts, outcomes,
permissions,
human/native bounds, clocks and model unchanged. Cap 2 and zero retries
stay fixed.
- Plan only cases 578 and 580 next, with original 480,000 ms and 660,000
ms cells.
Team calibration is not a new native PASS. Final uniform ten remains
required.

## Verification

- All 40 local pin controls passed:
`node --test
tests/runner-e2e/chat-full-catalog-testops-manifest.test.mjs
tests/runner-e2e/chat-full-catalog-testops-adapter.test.mjs
tests/runner-e2e/chat-full-catalog-testops-reconcile.test.mjs
tests/runner-e2e/chat-completion-testops-cli.test.mjs`.
- The exact source passed 352 fresh controls across ten files. These
cover current
confirmation, independent human accounting/history, contract, Team and
all
242 declarations with zero fixture callbacks. Full runner E2E types
passed.
- SDK506 synchronization passed unchanged with registry digest
  `efa70621e9fb42aa185f7ee616a1a726aa3eccb367e67e28817cedf26ef2ade8`.
  No install, native build, SDK build or local model call was needed.
- Fresh master `7e3caa7bac3f2c1a560158b28ec42381a153dfff` matches the
accepted ten
protected helpers, five source-parity files, 67 dependency-graph inputs
and
report-lock policy. No private helper imports ran during this
preparation.
- Local qualification used Node `v26.4.0`. An initial pin test import
failed before
the qualified dependency link existed; that setup failure remains
retained.
- Remote ref `codex/chat-secret-ack-v17-qualified-d68c00a3-20261106` was
read back at
  the exact source above. Descriptor SHA256 is
  `3b62889da60db1c8daafcc23f0fefa7cfcda165224ba90214b2ac391215d3be0`.
- New-head CI and reviews remain pending at PR creation. No paid
evaluation ran here.

## Risks

This source is unmeasured. Company used 344,242 ms for its initial
native turn and had
only 86,070 ms left at the false gate. Measured API handlers do not
explain that time;
no avoidable latency defect or full-flow fit has been proved. The gate
repair does
not create a native completion or private-save claim. Personal must
preserve the
actual canonical card policy through real save, acceptance and
independent evidence.
Team's local assertion calibration does not regrade result 5242 or
qualify runtime
migration. Every saved-state, actor, privacy and delivery check remains
mandatory.

Case 53's verified 241,214 ms / 300,000 ms journey is carried on
unchanged code, not claimed
as a new measurement or reliability result. All older failures remain
retained.
Secret journeys require independent semantic safety review before pass
credit.
Core and full-catalog PRs stay unmerged; the 196/244 gate remains. Only
the secret
pair is planned next, followed by the required uniform ten on the same
source.
No merge override or retry is requested by this PR.

## Model Used

OpenAI `gpt-6.1-sol` through Codex, with reasoning, tool use and code
execution.
The context-window limit is not exposed in this session. The native eval
model
remains `openrouter/deepseek/deepseek-v4.1-flash-1017` and was not run
locally.

## 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-11-06 03:47:43 -06:00
DottaandPaperclip b400914345 test(testops): pin calibrated four-journey fixture source (#19423)
## Thinking Path

> - Paperclip lets people manage AI agents and inspect saved work.
> - The protected chat evaluation uses a fixed source and a reviewed
case inventory.
> - The last four selected journeys all reported FAILED. Their originals
remain unchanged.
> - Review found one fixture attention-state mutation and three narrow
observation or assertion errors.
> - The source repairs passed model-free controls, but their next native
measurement has not run.
> - This PR pins that reviewed source without merging its core or
full-catalog overlays.
> - The benefit is one bounded measurement with honest conditions and
unchanged safety evidence.

## Linked Issues or Issue Description

Refs: #19418, #19325, #19416. The last two core PRs remain open and
unmerged.
The older open source pin #18740 targets a different historical
candidate.

**What happened?**

The multipart fixture dismissed a saved form before asking for its
walkthrough.
The Company guard rejected a bounded secure-page save instruction. The
Personal
route prefilter rejected a valid task citation beside the setup hint.
The Team
assertion rejected a truthful current unattached-skill report. Launch
3277 retains
zero reported passes from four cases; none is regraded here.

**What did you expect to happen?**

Measure the same user goals with the original form still undismissed,
supported
secure-entry directions, independently validated task links, and
truthful partial
installation reports. Require all real saved-state, actor and privacy
evidence.

**Steps to reproduce**

Run the protected selected journeys from source
`58449c4ecd7fd374f21f175411ef3249f55c18a3`. Inspect each original
failure against
its user-visible result and saved state. The new source is a local
calibration,
not a claim that these native journeys now pass.

## What Changed

- Pin immutable source `5f74dc6545ea66ac71255ac8e6010f5215a1f257`.
- Copy its exact 242-row descriptor snapshot. Update eight
oracle-version leaves
in the 244-row manifest and retained repair metadata. Dependency lists
stay fixed.
- Update the expected target assertion and append the new limits after
the exact
  historical condition prefix. Retain all existing runtime conditions.
- Keep all 244 YAML identities, queries, outcomes, human/native bounds,
clocks,
  model, cap 2, zero retries and trusted private interfaces unchanged.

## Verification

- All 40 local manifest, adapter, reconciliation and CLI admission
controls passed:
`node --test
tests/runner-e2e/chat-full-catalog-testops-manifest.test.mjs
tests/runner-e2e/chat-full-catalog-testops-adapter.test.mjs
tests/runner-e2e/chat-full-catalog-testops-reconcile.test.mjs
tests/runner-e2e/chat-completion-testops-cli.test.mjs`.
- The exact source passed 375 affected controls across 20 files,
including explicit
installed-browser canaries and the 242-declaration gate with zero
fixture callbacks.
Full runner E2E typecheck passed. These component results are not native
passes.
- The 506-input SDK guard passed without refresh. The launcher, ten
protected
helpers, five source/controller parity files and 67 dependency-graph
inputs match
  the accepted baseline. No install or build was needed.
- Local qualification used Node `v26.4.0`. Earlier alias and
declaration-output setup
failures remain retained. The normal remote CI configuration is
unchanged.
- Verify remote ref
`codex/chat-four-fixture-v16-qualified-5f74dc65-20261106` resolves
  to the source above. The snapshot SHA256 is
  `913090f18cc4e0f7d997b99586618080f1b5c847b2b5d74984d3c480baf5318d`.
- New-head CI and reviews must finish before merge. No paid evaluation
ran for this PR.

## Risks

The source remains unmeasured. Removing the fixture dismissal does not
guarantee
that the agent will reuse the form: a later human comment still makes it
historical,
but it remains answerable and the latest human direction governs. The
same-form
fidelity check stays strict. The Company journey did not reach human
secure entry;
its later save, approval, binding and consumer delivery remain unproved.
Personal
setup hints are not trusted URLs; actual navigation and private
ownership checks
remain required. Team calibration gives no runtime-migration credit.

All original failures remain retained. Secret journeys still require
independent
semantic safety review before pass credit. No native reliability or
latency claim
is made. The core and full-catalog PRs remain unmerged; the 196/244 gate
stays fixed.
A later full-ten run is a separate measurement. Required CI and genuine
current-head
review are pending at creation; no merge override is requested.

## Model Used

OpenAI `gpt-6.1-sol` through Codex, with reasoning, tool use and code
execution.
The context-window limit is not exposed in this session. Native eval
configuration
remains `openrouter/deepseek/deepseek-v4.1-flash-1017` and was not run
locally.

## 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-11-06 02:33:18 -06:00
DottaandPaperclip 4d49a31286 test(testops): pin reviewed four-case recovery source (#19418)
## Thinking Path

> - Paperclip manages AI agents and their work.
> - The protected TestOps workflow evaluates a fixed source commit.
> - The last five-case attempt retained two passes and three failures.
> - Reviewed fixture changes address observed admission and reporting
gaps.
> - Product denial guidance and closed diagnostics remain candidate
overlays.
> - This PR updates only the immutable source pin and its public
metadata snapshot.
> - A bounded four-case measurement can test this candidate without
merging catalog or core code.

## Linked Issues or Issue Description

Refs #19325, #19416, #19395.

**What happened?**
The current pin targets the prior five-case source. The next reviewed
source changes question fidelity context, Personal menu observation,
Company secure-save acknowledgment admission, and Team partial-install
reporting. The last attempt's original failures remain unchanged.

**Expected behavior**
The workflow must admit the exact reviewed source and matching
descriptors. It must preserve the selected model, native and human
bounds, clocks, credentials, and zero automatic retries.

**Steps to reproduce**
Compare the current manifest and descriptor snapshot with source
`58449c4ecd7fd374f21f175411ef3249f55c18a3`. Run the local manifest,
adapter, reconciliation, and CLI admission controls listed below.

**Paperclip version or commit**
Controller base `90b8190c33e8f8eae44cae1f57721251fe1e1343`; candidate
source `58449c4ecd7fd374f21f175411ef3249f55c18a3`.

**Deployment mode**
Protected AWS Product E2E through the existing TestOps workflow.

## What Changed

- Pin the reviewed immutable source and exact descriptor snapshot.
- Update four existing oracle-version leaves and Company/Personal
source-file provenance.
- Append current conditions while preserving the complete historical
conditions prefix.
- Retain all 244 case identities, YAML requests and outcomes, counts,
model, clocks, runtime conditions and policy gates.
- Change one expected target literal in the manifest test. No workflow,
lock, runtime, SDK or credential changes.

## Verification

- 40 local controls pass:
`node --test
tests/runner-e2e/chat-full-catalog-testops-manifest.test.mjs
tests/runner-e2e/chat-full-catalog-testops-adapter.test.mjs
tests/runner-e2e/chat-full-catalog-testops-reconcile.test.mjs
tests/runner-e2e/chat-completion-testops-cli.test.mjs`
- Parsed all 244 rows. Only the four oracle versions and two source-file
arrays differ. Runtime conditions are identical. The candidate snapshot
matches committed source bytes.
- The source qualification includes focused positive/negative controls,
full runner E2E types, and unchanged SDK506 registry
`efa70621e9fb42aa185f7ee616a1a726aa3eccb367e67e28817cedf26ef2ade8`.
Counts from overlapping component sets are not summed.
- All 67 controller dependency graph inputs match the accepted
frozen-install proof. No install, SDK build or runtime build was
repeated.
- The existing selector admits exactly cases 53, 578, 580 and 610 in the
native lane with cap 2. No workflow or settings change is needed. This
local admission control did not submit a run.
- Full repository build/typecheck/test commands were not repeated for
this metadata-only change. Normal PR CI and fresh review remain
required.

## Risks

- The candidate has no new native PASS. Launch 3244 retains two original
PASSES and three original FAILURES. Older failed and missing-original
results remain unchanged.
- Case 53 changes factual setup context to identify the existing visible
form and adds stricter request fidelity. Its YAML query and original
clock are fixed. This is not a latency fix.
- Personal v14 treats the inline code path as an imprecise hint. Actual
current-company UI links must establish navigation before private entry.
Save, owner isolation, consumer delivery and final confirmation remain
separate required proofs.
- Team v8 fixes truthful partial-report admission. It does not qualify
end-to-end runtime migration.
- Company v15 accepts completed-entry acknowledgment questions. Actual
current-human save, payload, source, continuation and governed-approval
proofs remain mandatory. The corrected 403 handoff guidance is a
recovery hypothesis. Closed diagnostics do not prove a native repair.
- Pinned OpenCode model-free tests preserve the tested finish types in
both directions. They do not prove real provider behavior or engine wait
authority.
- The next measurement selects only 53/578/580/610 once, with native cap
2, zero automatic retries and original bounds. A later uniform ten
remains separately unrun. The unchanged 585 pass is carried-forward
evidence.
- Core #19325 and #19416 must remain open and unmerged. This PR does not
merge the held full catalog or change its 196/244 gate. A maintainer
will perform any normal merge and actual measurement after required
checks.

## Model Used

OpenAI GPT-6.1 Sol (`gpt-6.1-sol`), with reasoning, code execution and
repository tools. The host did not report a context-window size. No
model inference was used for local fixture controls.

## 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-11-06 01:16:57 -06:00
DottaandPaperclip b918ee165d test(evals): pin coherent chat feature follow-ups (#19411)
## Thinking Path

> - Paperclip manages agent work and its permission boundaries.
> - The chat catalog runs feature checks from an immutable source.
> - The last full-ten attempt had five reported passes, four failures
and one missing original.
> - Local evidence identified narrow assertion, setup and
evidence-retention repairs.
> - This PR updates the trusted source pin and its exact descriptor
snapshot.
> - The next five-case measurement can test the affected features under
the same model, clocks and native cap.

## Linked Issues or Issue Description

Refs: #19395, #19405, #19093, #19084, #19112.

The previous source remains preserved. This PR selects reviewed source
`f5692c57dafaf9afbef479c25fcd277815932516` on
`codex/chat-full-ten-coherent-qualified-f5692c57-20261106`, tree
`b9e302d2ea7b605a60125dec8c81672eac7a3c57`. The full catalog and all
core PRs remain unmerged. Core #19405 is included only as a source
overlay.

## What Changed

- Update the source target, exact descriptor snapshot and the matching
pin checks. Preserve historical conditions, frozen source anchors and
the prior query clarification.
- Record Company ACK handling and Company/Personal negation corrections,
plus the skill-update preview negation correction. A denied or unapplied
action still fails when the agent claims it completed.
- Disclose the Team setup change: a disposable catalog package selects
the approved OpenCode runtime and same-company account. Other file bytes
and non-runtime sidecar fields stay unchanged. Original and effective
package identities and hashes are recorded. A real PostgreSQL install
without caller overrides proves the saved runtime. This gives no
end-to-end runtime-migration or override-handling credit.
- Include defensive failed-turn evidence retirement and generic,
schema-valid human-input examples. The old case 53 missing-original
ENOENT cause is not diagnosed. The examples are a usability hypothesis,
not a schema repair or native-success claim.

All 244 YAML definition fields (query, assumed context and expected
outcome) remain byte-identical versus source 936c. The Team derived
runtime fixture and task setup context change is disclosed above.
Native/human bounds, clocks, DeepSeek 1017, credentials, SDK506/efa,
launcher, private interfaces, native cap two and zero automatic retries
remain unchanged. Only descriptor `sourceFiles` and oracle versions
change. The 196/244 gate stays unchanged.

## Verification

Pin-local checks:

```sh
node --test tests/runner-e2e/chat-full-catalog-testops-manifest.test.mjs tests/runner-e2e/chat-full-catalog-testops-adapter.test.mjs tests/runner-e2e/chat-completion-testops-contract.test.mjs
```

- All 49 pin/admission controls pass locally. They join all 244
identities, historical query overrides, native bounds and the exact
242-row descriptor snapshot.
- Source qualification: 447 controls across 32 suites, full E2E
TypeScript checks and normal contract generators pass. The separate 21
core contract controls are carried-forward component evidence; they are
not added to 447. Local source checks used Node 26.4.0. AWS runtime
settings are unchanged.
- The selected source descriptor SHA256 is
`24fe88af167724c6fb120d3984296aab47c993a65782158e03d80a936fbd94ed`.
- The actual source launcher is byte-identical to 936c: SHA256
`2b9a6953ee51f0ea0dbbd475b0491d9a6c39a1d6835eeaa912e0dbb7cf987724`, Git
blob `c88df15f509b2ac8638af826647a97d45f16bd1f`.
- All 506 registered SDK inputs and the ten trusted helper bytes are
unchanged. Five required source-helper joins pass. No SDK renewal or
native build is part of this PR.
- The current controller's 67 dependency inputs match the qualified
frozen reporting graph. No reporting-lock, package, permission or
workflow change is included.
- Exact head `b833036fb477b55b05cbdf1f4feb2e2c5387b420` is green: CI run
42166216108 attempt 2 succeeded, Windows succeeded, and both current
reviews are 5/5 with zero unresolved threads. The check rollup has 56
successes, three configured skips and one neutral result. New
representative cases 53, 578, 580, 585 and 610 are unrun. A later
uniform-ten regression is separate.
- CI attempt 1 remains retained: one cloud-auth browser fixture read a
trailing health response after context teardown began, after all
task-recovery assertions had passed. One authorized rerun of only that
failed job and its dependent checks succeeded on the unchanged head.
This does not fix or qualify fixture reliability; no eval or model run
was retried.

The previous full-ten outcome remains five reported passes, four
failures and one missing-original/reporting gap. Case 585 reached only
its first preview before the false rejection; its update phase is
unqualified. Case 610's old noncompletion and runtime-override journey
remain unresolved. All original failures and evidence remain retained.
No old result is regraded or replaced.

## Risks

The local repairs may not produce a native pass. The new Team setup
tests installation with an already selected runtime package; it does not
qualify runtime migration. Failed-turn retirement has local regression
coverage but does not establish the cause of the old case 53 reporting
gap. The core guidance overlay remains unmerged and its native benefit
is unproved. Normal protected merge and a new authenticated measurement
are still required.

## Model Used

OpenAI `gpt-6.1-sol` through Codex. It used code inspection, local test
execution and GitHub tooling. The context window size is not exposed. No
model inference or provider call was made for this PR's local checks.

## 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-11-05 23:32:34 -06:00
Dotta d8b0eae687 test(evals): pin completed timeline command account for full-ten measurement (#19395)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - The chat catalog needs fixed source and explicit conditions for each
measurement.
> - The latest timeline run delivered a complete account within its
original deadline.
> - Its assertion missed ordinary exitCode notation and a command with
an omitted subject inside a named worker bullet.
> - The reviewed source corrects those bounded textual checks while
retaining independent history and command proof.
> - This pull request pins that immutable source for one full-ten
measurement.
> - Original failed grades and unresolved Company timing remain visible.

## Linked Issues or Issue Description

Refs: #19392, #19086, #19388.

This follows the prior source pin. The latest timeline response
correctly described requirements, a real failed command, saved pause,
human reassignment, repair and successful verification. Its original
grade still failed one narrative assertion. This pin carries the
reviewed correction without merging the full catalog or its production
overlays.

## What Changed

- Pin source `936c3bbe0e83ca15616254f23d9023b2065fc5fb`, tree
`e5c64d67935497164b098e31e995f87ba7875d06`.
- Advance only the timeline oracle from v11 to v12 in the candidate
snapshot and manifest.
- Retain all 244 current queries, contexts, expected outcomes, model,
credentials, clocks and human/native accounting.
- Record one planned full-ten bounded measurement at native cap 2 and
zero automatic retries.
- Change only the manifest, its target assertion and the exact candidate
descriptor snapshot.

## Verification

- I verified the immutable source branch readback before I published
this pin.
- The new narrative control fails on the parent. The fixed source passes
300 timeline, native-proof and declaration controls, including all 242
lazy declarations with zero fixture callbacks.
- The response from result 5094 is accepted by the local diagnostic. The
original grade is retained as FAILED; this is not a new native PASS.
- Fresh full runner E2E types and the SDK guard over 506 inputs pass in
the qualified source graph. An earlier isolated worktree type attempt
had dependency-alias errors; the clean source qualification supersedes
that setup gap.
- Controller: `node --test
tests/runner-e2e/chat-full-catalog-testops-manifest.test.mjs
tests/runner-e2e/chat-full-catalog-testops-adapter.test.mjs
tests/runner-e2e/chat-full-catalog-testops-reconcile.test.mjs` — 40
controls pass.
- The snapshot equals the committed source descriptor bytes. All 244
rows compare equal to the prior pin except the timeline oracle version.
- Source descriptor SHA256:
`19185aa5298c93d159c3d8547661fd6ef22185e74be1c18b8497bae2ef8051c7`.
- Controller manifest SHA256:
`822494b170139a8204ff36b33891e2f4960ac0aba6800e9856f2d25dd24de7c6`.
- Launcher, protected evidence wire and the accepted 506 SDK inputs
remain unchanged. The source SDK registry stays
`efa70621e9fb42aa185f7ee616a1a726aa3eccb367e67e28817cedf26ef2ade8`.

- Exact pin head `31f47fcdfb600e6b15b35ed50c2a447d03681f06` has 56
successful checks and three configured skips. Both protected checks
pass. Greptile is 5/5 for this head with zero open threads. Paperclip
Review completed neutral at 5/5. GitHub reports CLEAN and MERGEABLE.
These checks do not qualify the unrun native experiment.

## Risks

- Original timeline result 5094 remains FAILED. All three native runs
succeeded and the account was complete in 248,876 ms, but the original
narrative check failed. Local calibration does not rewrite that grade.
- Original Company result 5093 ended without first-CEO completion. Its
model/runtime timing cause remains unresolved. This source makes no
Company runtime or latency fix claim.
- The full-ten measurement is unrun. It is a bounded experiment, not
proof of deterministic timing, reliability or an all-ten pass.
- Company retains two base human inputs plus at most one independently
verified UI approval, minimum two and maximum three native runs, and
480,000 ms. Timeline retains three native runs, one human input and
720,000 ms. No condition is waived.
- Secret journeys still require independent semantic safety review.
Metadata shape alone does not establish that a proposed name is
non-sensitive.
- The interaction-accept and API-search overlays remain separate,
reviewed, unmerged core PRs. This pin does not merge them or the full
catalog. The 196/244 admission gate stays fixed.

## Model Used

OpenAI Codex, GPT-6.1 Sol (`gpt-6.1-sol`), with reasoning, repository
tools and code execution. The host does not expose an exact
context-window size. No model or paid provider was called for local
controls.

## 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
2026-11-05 21:13:17 -06:00
DottaandPaperclip 7c04adb2d6 test(evals): pin company environment and API search repairs (#19392)
## Thinking Path

> - Paperclip manages AI agents and their governed actions.
> - The TestOps controller runs an immutable product-eval source.
> - The last company-secret attempt rejected a safe metadata question
before private entry.
> - A governed approval also had a redundant server notification and
wake path.
> - Natural-language API search could hide the resource needed for a
timeline answer.
> - This pull request pins the reviewed source and its exact descriptor
snapshot.
> - New native evidence must still prove the affected journeys.

## Linked Issues or Issue Description

Refs #19381, #19093, #19387, #19388. This is the next controller pin for
those reviewed changes. The core pull requests remain unmerged.

## What Changed

- Pin source `2c99c248e839f41b520fc2d7e3702169ac6cb0a2` and its exact
descriptor snapshot.
- Advance company oracle v12 to v13. Admit bounded environment-name
questions without a required authored pattern or exact prompt template.
Preserve independent human-answer validation.
- Include the reviewed interaction-accept notification and API-search
ranking overlays. Record their route and catalog dependencies in the
company and timeline provenance.
- Retain the existing cap of two, zero retries, DeepSeek1017 model, and
all 244 current YAML definitions. Company keeps 480000ms, native2..3,
base human2 plus one independently proved approval. Timeline
keeps720000ms, native3/human1.

## Verification

- Source:396 controls in9 suites,2046 API catalog controls,145 route
controls, full runner TypeScript check, and unchanged SDK506 input guard
passed. Fresh-master API PR has2059 controls; its other baseline tests
are absent from this catalog source.
- Controller:133 contract, API, adapter, reconcile, streaming and
manifest controls passed. Existing report-lock preparation returned
`already-reviewed`.
- All current YAML definitions and launcher bytes remain unchanged from
the prior source. No model or native eval ran for this pin.
- The original company5059 and timeline5060 remain failed. Company
private entry, approval and final binding remain unproved on this
successor.
- Exact-head normal checks are terminal:56 success,3 intentional skips,
and one neutral Paperclip review. Greptile and Paperclip both report5/5
with no findings; review threads are empty. The next TestOps/AWS run
follows the protected controller merge.

## Risks

The new source is not a native feature pass. Its effect on model
completion is unproved. The original480000ms company budget may still be
too short for three native turns. No budget change or count waiver is
included. The full catalog remains outside master and its existing
admission gate remains unchanged. The controller reuses byte-identical
SDK506 evidence; no compiler or registry renewal is claimed. Actual
post-merge helper imports still need qualification against the merged
controller lock. The CI virtual merge includes a newer upstream lock
than the local frozen dependency proof.

## Model Used

OpenAI `gpt-6.1-sol` through Codex, with repository tools and code
execution. The host did not report its context window.

## 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 linked existing issues or described the issue in-PR
- [x] I have not referenced internal or instance-local Paperclip issues
or links
- [x] My branch name describes the change and contains no internal
ticket id
- [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 risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is5/5 with no open findings
- [x] I will address reviewer comments before requesting merge

Co-authored-by: Paperclip <paperclip@paperclip.ing>
2026-11-05 20:05:16 -06:00
github-actions[bot]andlockfile-bot 675f7283dd chore(lockfile): refresh pnpm-lock.yaml (#19389)
## Thinking Path

> - Paperclip uses a dependency lock for reproducible builds.
> - Dependency changes on master need matching lock entries.
> - Paid eval reports also pin a reviewed offline correction.
> - Reports must install before paid model work starts.
> - This automated PR keeps the lock and report proof together.

## Linked Issues or Issue Description

**What happened?**

Dependency manifests on master changed after the last committed lock
refresh.

**Expected behavior**

Frozen installs must match those manifests. Eval reports must retain
matching offline lock proof.

**Steps to reproduce**

Run a frozen install before and after this lock refresh.

## What Changed

- Refresh the dependency lock from the manifests on master.
- Include the matching offline report correction and hashes.

## Verification

- Pinned pnpm resolution completed with lifecycle scripts disabled.
- The report proof refresh accepted the reviewed committed baseline.
- The workflow rejected changes outside the lock and report proof files.

## Risks

The lockfile bot merges this PR without CI or review when every added
package version is at least 3 days old on npm. Otherwise the PR waits
for a maintainer, and the daily refresh tries again. The bot merges only
the exact commit this workflow generated from manifests already reviewed
on master. Unknown report lock baselines remain blocked. This update
changes no permissions or paid enable gates.

## Model Used

None — generated by pnpm and the deterministic report-lock updater.

## Checklist

- [x] Thinking path and problem description included
- [x] Generated lock and matching report proof included
- [x] Release-age gate decides between bot merge and maintainer review

Co-authored-by: lockfile-bot <lockfile-bot@users.noreply.github.com>
2026-11-06 01:42:27 +00:00
Devin FoleyandClaude Opus 5.5 434d224c3a fix(ui): retry stale chunk reloads while a deploy settles (#19361)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - The board UI loads each page as a lazy chunk. After a deploy, an
open tab can ask for a chunk from its old build.
> - #17349 added a recovery: the app reloads the page one time when a
chunk fails to load. A loop guard permits only one reload in five
minutes.
> - Staging error monitoring still reports `Failed to fetch dynamically
imported module` from builds that include #17349. The events come 1–10
seconds after page load, and 1–10 minutes after page load.
> - During a deploy, the old server and the new server can both answer
for some seconds. The reloaded page can then miss a chunk again. Also, a
second deploy can occur inside the five-minute window. In both cases the
guard stops the recovery, and the user sees the error page. One more
reload a few seconds later would recover.
> - #18518 keeps old chunks available after a deploy, but only on
deployments that enable shared UI assets. Other deployments still depend
on the reload recovery.
> - This pull request permits up to three reloads in the guard window.
The reloads wait 0 s, 2 s and 5 s, so that the deploy can settle. After
the last reload, the error page shows and reports as before.
> - The benefit is that a stale tab recovers through a normal deploy
without an error page and without error-monitoring noise. A chunk that
stays broken still shows the error after a small, fixed number of
reloads.

## Linked Issues or Issue Description

Refs #17349
Refs #18518

**What happened?**
A browser tab stayed open during a staging deploy. A lazy page chunk
failed to load with `TypeError: Failed to fetch dynamically imported
module`. The route error boundary showed "This page hit an error" and
reported the error. The release included the one-time reload from
#17349. The reload did not occur because the loop guard had already used
its single reload in the last five minutes.

**Expected behavior**
The app reloads again after a short wait while the deploy settles, and
the page loads. The error page shows only when the chunk stays broken.

**Steps to reproduce**
1. Open a board page on a deployment without shared UI assets.
2. Deploy a new build. While the old and new servers both answer, go to
a page that was not loaded yet.
3. The chunk fails, and the page reloads one time.
4. The reloaded page gets its HTML from one server and a chunk request
goes to the other server. The chunk fails again.
5. The guard stops the recovery, and the route error page shows.

**Paperclip version or commit**
`master` at 5ac05871b5

## What Changed

- `ui/src/lib/chunk-load-recovery.ts`: The recovery permits up to three
reloads in the five-minute guard window. The reloads wait 0 s, 2 s and 5
s (`RELOAD_DELAYS_MS`). After the third reload, the recovery returns
`false`, and the boundary shows and reports the error as before.
- Storage stays compatible with older builds.
`paperclip:chunk-load-reload-at` still holds only the bare start time of
the window, so an older build keeps its one-reload guard during a
deploy. The retry count is in a separate key,
`paperclip:chunk-load-reload-attempts` (`<window start>:<attempts>`).
The count applies only to the matching window. A window that an older
build started counts as one reload.
- A delayed retry keeps its timer. The new
`cancelPendingChunkLoadReload()` stops a retry that has not started.
`RouteErrorBoundary` calls it when the user moves to another route, and
when the boundary unmounts. A working page is therefore not reloaded
later.
- The abandonment timer starts after the delay, so a delayed reload gets
the full 10 s before the boundary reports.
- A reload that does not leave the document (for example, the user
cancels it) is not tried again from the same document. This keeps the
behavior from #17349.
- Tests: unit tests for delayed retries, the retry limit, compatibility
with older builds, a stale retry count, and cancellation. Boundary tests
start from a delayed attempt and cancel it on navigation. The e2e spec
for a lazy CSS asset that stays broken now expects 4 page loads before
the error page.

## Verification

- `cd ui && npx vitest run src/lib/chunk-load-recovery.test.ts
src/components/RouteErrorBoundary.test.tsx
src/components/AppErrorBoundary.test.tsx`: 3 files, 32 tests pass.
- Red before the fix: with the new tests, the first PR head fails 5
tests (older-build key, cancellation, cancel on navigation). The
original `master` code fails the retry tests. With this head, all pass.
- `tsc --noEmit -p ui/tsconfig.json` shows no errors in the changed
files.
- `tests/e2e/chunk-load-recovery.spec.ts` runs in CI.
- Manual check: on a deployment without shared UI assets, open a page,
deploy, and go to a page that was not loaded. The page reloads, and it
loads after the deploy settles. If you move to another page during the
wait, the page does not reload.

## Risks

- Low risk. The change affects only the chunk-load recovery path.
- A chunk that stays broken now causes up to three reloads (about 7 s of
waits in total) before the error page shows. Before, it caused one
reload. The limit stays fixed in each five-minute window, so a reload
loop cannot occur, also when old and new builds alternate.
- A retry that the `vite:preloadError` listener starts is not tied to a
route, so navigation does not cancel it. This matches the behavior
before this change, where that reload occurred at once.
- No server, data, or contract changes.

## Model Used

- Claude Opus 5.5 (`claude-opus-5-5`) by Anthropic, used through Claude
Code with tool use (shell, file edits and GitHub connector). Standard
context window, with reasoning.

## 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

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

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-05 17:21:08 -08:00
4550253dc9 feat(ui): rename Needs you to Inbox and move Mine into Tasks (#19363)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Coordinator gives people navigation for conversations, tasks, and
decisions.
> - The decision entry is called Needs you, while a separate Inbox
remains under More.
> - Coordinator's personal task filter does not retain the full behavior
of the original Mine view.
> - This pull request names the decision entry Inbox and hosts the
original personal work views inside Tasks.
> - People keep their triage tools and saved choices without moving
between two task destinations.

## Linked Issues or Issue Description

**What existing behavior does this improve?**

Coordinator navigation and the personal Mine view in Tasks.

**Subsystem affected**

UI navigation, task view routing, task collection preferences, and
browser coverage.

**Current behavior**

Needs you opens the decision feed. More contains another Inbox
destination. The default Coordinator task filter matches task creators
and assignees. It does not use the full personal participation rules,
archive behavior, shortcuts, grouping, or saved columns of the original
Mine view. The organization task table also resets its column choices on
reload.

**Proposed behavior**

Inbox opens the same decision feed with the inbox icon. Tasks defaults
to Mine and remembers a person's selected view per company. Mine uses
the existing personal Inbox implementation and preferences. It retains
read/unread title weights, keyboard navigation, read/unread shortcuts,
archive and undo, mobile swipe-to-archive, grouping, and saved columns.
Old Inbox links open the matching task view. The organization task table
saves its columns and order per person and company.

**Reason and benefit**

People get Chat, Tasks, and Inbox as distinct navigation entries.
Personal work remains a view within Tasks without losing the existing
triage behavior.

**Breaking changes**

Coordinator no longer offers the previous Inbox destination under More.
Old Inbox URLs redirect into Tasks and retain query parameters and
fragments. The Needs you label becomes Inbox; its decision feed, count,
history, and resolution paths stay in place. Classic retains its
separate optional combined-list setting.

**Additional context**

Refs: #19360, the workspace-defaults PR now integrated from master.
Refs: #10620, related Inbox attention ordering. Duplicate searches found
no open PR for this navigation and Mine integration. Roadmap review
found no separate new execution feature in this scope.

## What Changed

- Rename Coordinator's desktop and mobile decision entry and page to
Inbox. Use the inbox icon. Remove the old Inbox item under More. Clarify
that the combined-list experiment applies only to Classic.
- Add one Coordinator task-view router. Host Mine, Unread, Recent,
Blocked, and Everything through the existing Inbox owner. Keep
organization views in the task table and board. Normalize legacy
filtered URLs before mounting a collection so clearing the last filter
preserves the current layout and local filters.
- Reuse the existing Mine API, participation, read state, archive cache,
undo, keyboard, mobile gesture, grouping, and preference paths. Existing
personal column choices carry over.
- Save organization task-table columns and order per person and company.
Keep controls usable if browser storage fails.
- Update navigation tests, routing and persistence regressions,
exact-run retry browser coverage for each workspace variant, product
documentation, and the affected Storybook notes. Keep existing story
IDs.

## Verification

- Preference, routing, navigation, task table, and inherited Inbox
regression tests pass in focused runs. After integrating master and
addressing the review finding, all 187 focused tests, UI typecheck, and
token gates pass.
- Full build and repository typecheck pass after integrating master. The
full UI suite previously passed: 894 files, 11,169 tests passed, and one
skipped. All 14 desktop/mobile triage and exact-run retry browser cases,
including a fresh production UI build, pass after integrating master.
- The full repository test suite was not run locally for this UI-only
change; full PR CI is running.
- Browser checks use a fresh isolated local instance and a deterministic
process agent for real run-attributed unread activity. They exercise
legacy URLs, title weights, saved grouping and columns, read/unread
shortcuts, archive/undo, and a real mobile touch gesture.
- Earlier browser fixtures were corrected: own activity is read, agent
comments need valid run attribution, and undo uses `u` after the archive
refresh completes. The Inbox content heading is scoped separately from
the layout heading.
- The final settings wording correction passes all 63 settings tests.
- The [next CI browser
run](https://github.com/paperclipai/paperclip/actions/runs/42137377960/job/127629100535)
caught an old URL assertion for denied run retries. The test now pins
each workspace variant and covers Coordinator Tasks explicitly. The old
expectation fails deterministically for Coordinator; all 12 retry cases
pass with the corrected destination, preserving exact run identity and
truthful queued, deferred, and denied feedback.
- Token gates, map checks, and Storybook catalog checks pass. All 30
map/catalog script tests pass. Storybook play tests were not run.
- Greptile reviewed [the final
commit](https://github.com/paperclipai/paperclip/commit/5f2f3789b83af259f694f379afb769465688fb72)
at **5/5** with no new actionable findings. Its sort-only link finding
is fixed and resolved: three cases fail before the fix and pass after
it. `sortField` and `sortDir` keep organization links on the
organization table. [Current-head
CI](https://github.com/paperclipai/paperclip/actions/runs/42139668774)
is running.
- [CI exposed a routing
race](https://github.com/paperclipai/paperclip/actions/runs/42135293421/job/127621981587)
when removing the last label from a legacy Everything link. Four
deterministic regressions failed before the fix and now pass:
collections only mount after URL normalization. The existing end-to-end
component cases confirm local filters, board layout, fragments, and
history survive the change.
- The [initial server shard 4
run](https://github.com/paperclipai/paperclip/actions/runs/42131163087/job/127608751620)
failed an unchanged monitor-drain idleness assertion: two active
operations remained instead of zero. The complete scheduling suite
passes locally (54 tests). One isolated CI retry passed, including its
dependent verification gate. The original timing failure's root cause is
not established.

## Risks

- Mine includes the existing tasks, approvals, failed runs, and join
requests, preserving the original personal participation and attention
rules.
- Shared URLs with organization filters or table sort parameters still
open the organization task collection. Task back-links retain their
original fragments.
- Saved preferences are browser-local. Mine keeps its existing storage
keys; the organization table and selected Coordinator view use
person/company scopes.
- No database or server API contract changes are included. Existing
company access, personal participation, and decision permissions retain
their owners.

## Model Used

OpenAI Codex, based on GPT-6, with reasoning, repository tools, code
execution, and browser automation. The exact serving revision 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: Scott Tong <scott@scottsmbpm5max.lan>
Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-11-05 17:07:24 -08:00
DottaandPaperclip 46414fcfa4 test(evals): pin timeline and governed Company approval at native cap two (#19381)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - The chat catalog uses a fixed source and explicit execution
conditions.
> - A correct timeline response failed because its completed edit and
attached command result were not recognized.
> - Company credential setup can require a real human approval after the
secure save.
> - The controller must declare that optional approval and its run
bounds before it admits the source.
> - This pull request pins the reviewed source and caps native catalog
overlap at two.
> - The next run can test these conditions without treating local
controls as native acceptance.

## Linked Issues or Issue Description

Refs: #19357, #19086, #18971, #19093.

This follows the prior fixed-source catalog pin. It changes only
controller metadata, admission, tests, and load policy. The complete
catalog and separate core feature PRs remain unmerged.

## What Changed

- Pin immutable source `fe547be84826b4611d3ba9ee1a7d7aa0bd0a2843`, tree
`a23723ea5244e6ce8cee11e9c4b476acb6978fcd`.
- Advance only timeline v10 to v11 and Company v11 to v12. Add the
declared Company proposal helper to its source closure.
- Declare Company minimum two and maximum three native runs. Retain two
base human inputs and permit at most one independently verified UI
approval. Retain its original 480000ms attempt.
- Carry the literal Company-only approval marker from the descriptor
into the manifest. Reject foreign markers, changed bounds, and a
mismatch with static source task metadata.
- Cap native catalog execution at two workers. Keep the external lane
serial and retain zero retries.
- Keep all244 requests, contexts, expected outcomes, model, clocks,
credentials and other case bounds unchanged.

## Verification

- Source:421 focused controls across seven suites pass. Full runner E2E
TypeScript check passes.
- Explicit model-free approval UI canary passes one test with three
local scenarios. It checks accepted approval, wrong human, and failed
response. The first sandbox attempt stopped at Chrome launch; the
allowed execution passed.
- Controller:40 manifest, adapter and reconciliation controls pass.
- SDK506 inputs remain byte-identical to the accepted registry
`efa70621e9fb42aa185f7ee616a1a726aa3eccb367e67e28817cedf26ef2ade8`.
- Launcher and trusted private evidence wire remain byte-identical.
Source contract/flow accounting changes are explicit.
- Source descriptor SHA256:
`50e90d8c02ad57f444e27b522efe694db9734d47bdbc3a058475af77bac8b2ca`.
- Controller manifest SHA256:
`0447315601ed21ba15d6ea0ecd7fb89bc79ad6262db2594cd12ac774aa8d6c21`.
- Review the two changed rows. The next planned experiment selects
timeline and Company once at cap2 before a full ten-case run. No native
run on this source has passed yet.

- Exact controller head `d49dfc59ab7fddfe1a1de7e81bdb9c4e13400f30`:
normal CI has56 successful checks and three configured skips. Protected
`ci / verify` and `ci / e2e` both pass. Greptile5/5 and zero open
threads are verified for this head.

## Risks

- Original timeline5056 and Company5057 remain FAILED. Timeline5056
supplied the correct account; the local revised check passes its
diagnostic only. Company5057 saved the secret but left the binding
approval pending.
- Company native3 completion within480s is unproved. This change does
not raise its clock or claim to fix latency.
- Two-worker execution is a changed load condition. It does not prove a
concurrency cause, reliability, or eight-worker qualification.
- Secret journeys require independent semantic safety review before pass
credit. The documented closing-comma warning and arbitrary
metadata-prefill classifier limitations remain follow-ups in the
functional secret PR; a native failure is not waived.
- Candidate core PRs remain unmerged. The full-catalog196/244 admission
gate remains fixed. Local controls do not qualify all244 journeys.
- Local checks use Node26.4.0. They do not replace actual AWS runtime
qualification.

- The separate Paperclip Review app remains queued while its assigned
task waits for maintenance. It has no completed assessment. GitHub
reports `UNSTABLE` and `MERGEABLE`; this is not an all-checks PASS
claim. No review retry or staging mutation was performed.

## Model Used

OpenAI Codex, GPT-6.1 Sol (`gpt-6.1-sol`), with reasoning, repository
tools and code execution. The host does not expose an exact
context-window size. No model or paid provider was called for local
controls.

## 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-11-05 19:06:42 -06:00
Nicky LeachandClaude Opus 5.5 3a8f95d928 fix(ci): let verified Dependabot lockfiles merge through the reporting-lock gate (#19356)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - Only trusted environments may change `pnpm-lock.yaml`: the lockfile
refresh workflow and Dependabot. Contributors never commit it.
> - Paid evaluation jobs also install a lock only when the
reporting-lock proof (`tests/runner-e2e/report-lock.json` and `.patch`)
admits it.
> - #19283 added a CI test that checks the committed lock against that
proof. Only the refresh workflow writes the proof, so every Dependabot
lockfile pull request now fails CI. Examples are #17364, #17172, and
#17911.
> - A merged Dependabot lockfile also breaks the refresh workflow.
`prepare-report-lock.mjs --refresh` refuses to renew the proof for a
lock that the proof does not already admit.
> - This pull request lets a verified Dependabot lockfile pass, and it
keeps both lockfile rules strict. It also closes a gap in the
contributor rule.
> - The benefit is that Dependabot security updates can merge again, and
only trusted environments write lock content.

## Linked Issues or Issue Description

Refs #19283, #17364, #17172, #17911, #19303.

**What happened?**
`server/scripts/reporting-lock-policy.test.mjs` fails on each Dependabot
pull request that changes `pnpm-lock.yaml`. The error is "Reporting lock
changed; review the dependency correction before install". A Dependabot
pull request cannot change the proof files, so it can never pass. After
a merge, the lockfile refresh also stops at "Committed report lock is
not reviewed; refusing to refresh its proof".

**Expected behavior**
- Contributors cannot change `pnpm-lock.yaml` or the reporting-lock
proof.
- Dependabot can change `pnpm-lock.yaml`.
- The lockfile refresh workflow can change `pnpm-lock.yaml` and the
proof.
- After a Dependabot lockfile merges, the refresh workflow admits it and
renews the proof.

**Steps to reproduce**
1. Open a Dependabot pull request that changes `pnpm-lock.yaml`, such as
#17364.
2. Let CI run. The `server (9/12)` shard fails on the reporting-lock
policy test.

**Security gap found during this work**
The old rule skipped the lockfile check when `github.head_ref` was
`chore/refresh-lockfile`. A contributor could open a pull request from a
fork branch with that name and commit a lockfile change. The old rule
also exempted any pull request that Dependabot opened, including commits
that other people pushed to its branch.

## What Changed

- Add `.github/scripts/lockfile-trust.mjs`. It decides which writers may
change lock content:
- The refresh workflow: the head is `chore/refresh-lockfile` in this
repository, and `github-actions[bot]` opened the pull request.
- Dependabot: Dependabot opened the pull request from this repository,
and the head `pnpm-lock.yaml` matches a Dependabot commit. That commit
must have `dependabot[bot]` as its author, GitHub (`web-flow`) as its
committer, and a verified signature. The script reads these fields from
the GitHub API.
- The reporting-lock proof files count as lock content. Only the refresh
workflow may change them.
- `pr-trusted.yml` policy job: replace the inline `head_ref` and author
exemption with `lockfile-trust.mjs pr`. The job runs the script copy
from the base commit, so a pull request cannot change the check that
judges it. If the base predates the script, the job uses the earlier
rule.
- `refresh-lockfile.yml`: add `lockfile-trust.mjs merged`. It checks
that the last lockfile change on `master` is a GitHub-signed merge of a
Dependabot pull request, and that the lockfile at the pull request head
matches a verified Dependabot commit. If both checks pass, it gives the
lockfile SHA-256 to `prepare-report-lock.mjs --refresh
--trusted-lock-sha256`.
- `refresh-lockfile.yml` PR step: check `pnpm-lock.yaml` and both proof
files before it exits as unchanged. A refresh that renews only the proof
now opens a pull request.
- `prepare-report-lock.mjs` and its `.d.mts` declaration:
`refreshReportLock` accepts a trusted lock hash. If the trusted lock
already resolves, the proof admits it exactly with an empty patch. If
not, the proof records the resolution as the reviewed correction, as
before.
- `reporting-lock-policy.test.mjs`: skip on Dependabot pull requests.
The policy job verifies those lockfiles. The general test job gets
`PAPERCLIP_CI_PR_AUTHOR` for this purpose. This keeps the test, so it
still merges cleanly with #19303.
- `check-pr-lockfile.mjs` (advisory gate): allow Dependabot lockfile
changes, and flag changes to the proof files.
- `CODEOWNERS`: add the two proof files.
- `doc/RELEASE-AUTOMATION-SETUP.md`: describe the writers, the
`@dependabot recreate` path, and the proof renewal after merge.

## Verification

- `node --test '.github/scripts/tests/*.test.mjs'`: 707 passed. This
includes 17 new tests in `lockfile-trust.test.mjs` and 3 new tests in
`check-pr-lockfile.test.mjs`. The new tests run the `pr` command against
real git histories with a stub `gh`.
- `tests/runner-e2e/prepare-report-lock.test.ts`: 10 passed, including 3
new trusted-lock refresh tests. I ran it with a minimal Vitest config,
because the runner-e2e config builds a provider bundle first.
- `server/scripts/reporting-lock-policy.test.mjs`: passes normally, and
skips with `PAPERCLIP_CI_PR_AUTHOR=dependabot[bot]`.
- Live check of the `pr` mode against #17364 with the real GitHub API:
- With the real author, it reports "pnpm-lock.yaml matches verified
Dependabot commit 83c328c15c…" and `writer=dependabot`.
- With a contributor as the author and `chore/refresh-lockfile` as the
head ref, it fails.
- Live check of the `merged` mode at the real merge commits of #16018,
#16020, and #15361. All three report a trusted lock hash. For #16018 and
#15361, `master` changed after Dependabot's commit, so GitHub's merge
produced different lockfile bytes. An exact-bytes rule would refuse
them. That is why the rule trusts GitHub-signed merges of a verified
Dependabot head.
- Greptile reviewed `513ca2def8` at 4/5 with one P1: a proof-only
refresh was never committed, because the PR step checked only
`pnpm-lock.yaml`. `edbeb1ea0d` fixes it. A new test in
`lockfile-refresh-merge.test.mjs` runs the step's change check on a
proof-only change. The test fails without the fix.
- CI `Typecheck + Release Registry` failed at `edbeb1ea0d`:
`prepare-report-lock.d.mts` did not declare the new options argument
(TS2554 twice in `prepare-report-lock.test.ts`). `9139aaad85` updates
the declaration. A local `tsc -p tests/runner-e2e/tsconfig.json` shows
the 2 errors with the old declaration and none with the new one.
- CI at `9139aaad85` failed in six general test shards. None of them run
code that this pull request changes, and PR CI loads `pr-trusted.yml`
from `master`. The failures:
- `heartbeat-plugin-environment.test.ts`: "expected 'running' to be
'succeeded'"
  - `status-card-evaluation-work.test.ts`: a deadline comparison
  - `isolated-repository-rehome.test.ts`: timed out after 15 seconds
- `chat-channels.integration.test.ts`: GitHub webhook recovery
scheduling
- `company-import-export-e2e.test.ts`: child server start timeout, which
also fails on unrelated branches
- `workspaces-b`: every test passed, but an `EPIPE` error came after
`acpx-engine/execute.test.ts`
  I started a rerun of the failed jobs.
- Superagent found a P1 at `9139aaad85`: a verified signature proves who
committed, not who authored. A collaborator could sign a commit with
their own key and set Dependabot as the author. `4fe180d6c1` also
requires GitHub (`web-flow`) as the committer. New tests cover the
spoofed-author case. #17364, #16018, #16020 and #15361 still verify
against the GitHub API.
- `git merge-file` merges this test change with #19303 without
conflicts.
- Not run: the full repository test suite and typecheck. These changes
touch only CI scripts, workflows, one helper, and tests. GitHub CI
covers full regression.

## Risks

- `pr-trusted.yml` loads from `master`, so the new policy takes effect
only after merge. This pull request's own CI uses the earlier rule.
- A Dependabot pull request that is behind `master` now fails if someone
merges `master` into it and the lockfile changes. Use `@dependabot
recreate`. The policy job error says this.
- Paid evaluation jobs refuse a merged Dependabot lockfile until the
refresh pull request merges. The refresh merges without review when it
adds no new package versions. If the release-age gate holds it, the wait
lasts until a maintainer merges it or the daily refresh runs. During
that time, the reporting-lock policy test also fails on other pull
requests, which is the current behavior for any unrenewed lock.
- The rule trusts GitHub as the signer of Dependabot commits and of
merge commits (`web-flow`). Superagent uses the same trust root.
- People with write access can still push to `chore/refresh-lockfile`.
This was already true. The bot merges only its own head commit
(`--match-head-commit`), and code-owner review covers anything else.
- A future manual proof renewal, such as #19283, now needs the refresh
workflow or an admin merge. A contributor pull request that changes the
proof files fails.

## Model Used

- Anthropic Claude Opus 5.5 (`claude-opus-5-5`), with tool use and code
execution, in Claude Code.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass (focused tests; see
Verification)
- [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: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-05 16:42:26 -08:00
f2593b7905 feat: make Coordinator and Agent Chat standard and speed up navigation (#19360)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - People enter that work through the workspace, agent conversations,
and tasks.
> - Coordinator and Agent Chat still require experimental enrollment.
> - Task link prefetches do not warm the compact queries used by the
default task view. Chat also waits for a request when its navigation
list already holds the conversation.
> - This pull request makes Coordinator and Agent Chat standard and
reuses the reads needed for navigation.
> - People can choose Classic workspace in Experimental settings. Cached
work can appear while fresh data loads.

## Linked Issues or Issue Description

**What existing behavior does this improve?**

Workspace selection, Agent Chat availability, and navigation between
Chat, Tasks, and task details.

**Subsystem affected**

Cross-cutting: UI, workspace preferences, instance settings, and the
database migration.

**Current behavior**

People must enable Coordinator and Agent Chat in Experimental settings.
Opening a task can repeat requests because prefetch warms the full
detail and comment queries, while the default view reads compact task
data and a recent comment window. Opening Chat waits for a detail
request even when the current person's conversation list contains it.

**Proposed behavior**

Coordinator is the standard workspace for everyone. Experimental
settings offer Classic workspace, off by default. Old Coordinator
experiment values do not select Classic. Agent Chat is available to
everyone, including instances with an old saved or managed off value.
Task link intent warms the queries used by the mounted view. Chat can
use the current person's company-scoped conversation list during
refresh.

**Reason and benefit**

People can use the standard workspace without setup. Repeat navigation
can show cached content while the server refreshes it.

**Breaking changes**

Existing Coordinator experiment and Agent Chat off values no longer
disable these surfaces. Classic requires an explicit new opt-in. The
workspace API keeps its existing response shape and audit checks. The
migration retains legacy values and adds a separate Classic preference.
Execution permissions, company access, and chat privacy checks still
apply.

**Additional context**

Roadmap check: this graduates existing surfaces and improves their
navigation. It does not add a new agent execution capability. Duplicate
searches found no open Coordinator workspace PR. Related server cache
work, Refs: #17828, addresses compact issue-list invalidation; this PR
addresses client navigation queries.

## What Changed

- Add a default-off Classic workspace preference. Derive the existing
workspace API response from that choice. Keep personal persistence,
account isolation, and audited writes in the workspace preference
service.
- Replace the Coordinator experiment control with Classic workspace. Use
Coordinator while preferences load. Update the existing settings
examples and navigation recipe.
- Retire the Agent Chat experiment control. Ignore old stored and
managed off values. Retain the compatibility key and the existing
execution and access checks.
- Reuse account- and company-scoped chat list data with its original
freshness timestamp.
- Share compact task and recent-comment query options between prefetch
and the task view. Keep full-history prefetch for Classic tasks and
expanded history.
- Add upgrade, replay, cache, account isolation, and browser switching
regressions. Update product, database, development, and roadmap
documentation.

## Verification

- Targeted preference, settings, migration, cache, and UI regression
tests passed during implementation. The cache tests hold refresh
requests pending and check that content still renders. They also check
account isolation and stale refresh behavior.
- A real browser test verified fresh Coordinator defaults, Classic
opt-in persistence, and return to Coordinator. It used an isolated
source checkout with fresh data on macOS.
- Token, migration numbering and safety, map, and Storybook catalog
checks pass after the rebase.
- Repository typecheck and build pass. Typecheck and token gates also
pass after review repairs. The broad local run passed all six chat
integration shards (1,931 tests). It then found the host-CLI-dependent
recovery fixture described below. Its remaining duplicate work was
stopped after the full current-head CI matrix passed; this is not a
claim that the broad local command completed green.
- Review repairs passed 419 UI/migration fixture tests, 19 Coordinator
navigation tests, and all 214 tests in the five affected server suites.
The 24 Chat/workspace browser tests pass, including standard Coordinator
switching and explicit Classic persistence.
- The broader browser repair run passed 85 tests. It retained two failed
assertions and skipped five later serial cases. The affected files then
passed all 11 tests after the fixes: reopen the desktop panel after
reload and open More for Audit and Connectors. This includes the five
serial cases that had not run.
- The broad local suite exposed a recovery fixture that executed the
host Codex CLI during a simulated remote probe. On a host with Codex
0.154.0, model fallback broke its fixed-model assertion. The fake
sandbox now reports Codex 0.160.0. All 20 selected recovery/provider
compatibility cases pass after the repair.
- A CLI company import/export suite timed out during server startup in
the second CI run. The port fallback is intentional in that fixture. No
root cause was established. That suite passes on the final commit in CI.
This records recovery, not a claimed product fix for the earlier
timeout.
- The first CI run exposed remaining assumptions about the retired flags
and Classic UI. The repair commit updates those fixtures and navigation
steps. It also restores the missing enabled Cases destination in
Coordinator. Earlier local recovery attempts used the wrong fixture
notification and advanced fake time during live execution; the corrected
tests use the subscribed recovery queue and wall time during execution.
- Greptile reviewed commit `98972b030d4505d838427a2fca6b196b8cad6d47` at
**5/5** with no new comments. The original finding is resolved.
- Current-head CI is green: **56 successful checks**, with three checks
skipped by workflow filters. This includes typecheck, build, the
complete Vitest matrix, all eight browser shards, Runner verification,
release checks, and security checks. [Final CI
run](https://github.com/paperclipai/paperclip/actions/runs/42132651414).
- Typecheck caught missing `pid` and `startedAt` fields in the simulated
command result. The fixture now returns the complete process contract,
and the server test-layer typecheck passes.
- Storybook catalog alignment was checked. Storybook play tests were not
run. Hosted latency and cold bundle loading were not measured.

## Risks

- The new default changes the workspace for people who previously left
the Coordinator experiment off. They can opt into Classic in
Experimental settings.
- The additive migration must run before the new server code. It is safe
to replay and preserves explicit Classic choices.
- Cached content can be stale during background refresh. Existing query
invalidation and source timestamps still control freshness.
- These changes reduce avoidable loading waits. They do not establish a
measured improvement in hosted request latency or initial bundle
download time.

## Model Used

OpenAI Codex, based on GPT-6, with reasoning, repository tools, code
execution, and browser automation. The exact serving revision 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: Scott Tong <scott@scottsmbpm5max.lan>
Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-11-05 16:28:25 -08:00
Dotta b68f69a801 test(evals): pin author self-use and credential guard corrections (#19357)
## Thinking Path

> - Paperclip manages agents and their work.
> - The protected chat catalog selects an immutable evaluated source.
> - The measured parent produced seven independently reviewed passes out
of ten.
> - The authoring observer rejected valid author-only use, and two
credential wording guards needed stricter boundaries.
> - The reviewed source corrects those observers and declares each
affected oracle version.
> - This PR pins that source without changing the original questions or
run limits.

## Linked Issues or Issue Description

Refs #19346, #19095, #19093.

**What happened?**

The measured authoring response described real saved author-only use.
The old observer required zero assignments and wrongly rejected an
audited author-only assignment. The credential scanner also needed to
retain an unsafe comma-separated destination and mixed
reference/password requests. These are evaluation-layer corrections. The
parent timeline and company runs did not complete; no causal latency fix
is claimed here.

**Expected behavior**

Select the reviewed immutable observer source. Keep all original
scenario identities, questions, conditions, actor/resource proof,
counts, clocks, credentials, model, permissions and zero retries
unchanged.

**Steps to reproduce**

Run the source authoring and shared credential consumer controls.
Compare the committed candidate descriptor snapshot with source
`d1ab241cac0db7f700fadaaf62ffb3d2b51cf0c3`.

## What Changed

- Scope the private Company creation observer to the exact Create secret
dialog. Its successful close can open a separate details Sheet without
making the observer wait for that Sheet.
- Admit blank or bounded non-secret metadata defaults only for the
Company saved-secret-name question variant. Verify the same canonical
payload in independent human accounting.
- Pin source `d1ab241cac0db7f700fadaaf62ffb3d2b51cf0c3`, tree
`c4efaef62405cbb37236ad01db1187cf8a156868`.
- Store exact descriptor SHA256
`60db015337e807ff53a376b6db11c375a239097b224d2253dad68ecd0b0f61f3`.
- Update only seven oracle-version leaves: authoring v5, company v11,
personal v12, and four shared external consumers v6. Source-file lists
remain fixed.
- Retain provenance anchors, historical conditions and failures. Update
the single expected-target assertion. Exactly three metadata/test files
change.

## Verification

- 41 manifest, adapter, reconciliation and CLI controls pass on this
actual pin projection.
- Qualified source: one actual-worker offline browser canary passes all
three creation, failed-POST and missing-form mechanisms. Full E2E types
pass on this successor. Reused unchanged proof: 286 distinct controls
across authoring, Company saved-name question, human accounting and
shared-consumer/declaration suites pass. Full E2E typecheck passes. All
242 declarations load with zero fixture callbacks.
- SDK506 inputs and registry `efa70621` remain unchanged. Launcher
SHA256 `2b9a6953`, private transport interfaces, production/UI/CLI
source, lockfile and workflows remain unchanged from the measured
source.
- All 244 YAML queries, context and expected outcomes are byte-identical
to the parent. All descriptor native/human counts, clocks,
authentication, setup policy and source-file lists remain fixed.
- The parent source has seven measured semantic passes out of ten. The
new authoring and credential oracle versions are native-unrun. Existing
failed grades remain failed.
- The isolated company concurrency diagnostic
[run42124035785](https://github.com/paperclipai/paperclip/actions/runs/42124035785)
is a separate measurement. This pin does not alter concurrency or claim
to fix native noncompletion.
- Repo-wide build/tests were not repeated for this three-file metadata
update. Normal PR CI remains required.

## Risks

- The name character set does not prove secrecy. The saved-key-name
variant can admit a credential-shaped synthetic default; this general
classifier limit remains unfixed and tracked in #19093. These are finite
experimental journeys only. Independent review must reject any actual
credential-like or unknown-value prefill without clear
public-metadata/proposed-name grounding, even if autograding is green.
If safety cannot be established, the journey cannot receive PASS credit.
Secure UI save, human answer, canonical payload/hash, audit, binding and
byte-leak checks remain mandatory.
- Earlier CI includes three explicit runner-shutdown cancellations and
one deferred-observer test assertion at line573. Those outcomes remain
retained and unresolved; the Company dialog repair makes no claim to fix
them. New exact-head CI is required.
- The Company dialog mismatch was established from production source and
an actual-worker model-free regression before the next secure-save step.
The prior isolated attempt did not reach private entry, so it is not
evidence of an observed private-save failure.
- A valid review warning remains as a documented follow-up in #19093:
safe closing comma exclusions such as “only there” can be falsely
rejected by the credential wording guard. The pin authorizes bounded
experimental journeys only. If a valid actual handoff hits that guard,
its failed grade is retained; no regex failure is waived or counted as
PASS. Independent semantic review remains required for both secret
handoffs.
- Isolated Company original5055 remains FAILED. A real succeeded native
took255949ms and produced a valid saved-name question, but the observer
rejected its proposed non-secret metadata default. Secure entry and the
second native were not reached. This successor repairs that assertion
boundary only.
- The next selected74/466/578 run is an explicit bounded
lower-concurrency functional experiment at the existing cap2, same
model, original clocks and zero retries. It is not evidence of a latency
fix or reliability improvement.
- Local observer proof is not a new native PASS. Timeline and company
noncompletion remain unresolved, and no clock increase is included.
- A secure handoff still requires independent semantic review before
PASS credit. Actual saved resources, owner/audit evidence, provider
outcomes and privacy gates remain required.
- The source catalog remains separate from master. This PR does not
merge the core or full catalog feature changes into master.

## Model Used

OpenAI Codex, `gpt-6.1-sol`, with repository tools and code execution.
The host does not expose the 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
2026-11-05 17:57:18 -06:00
Dotta 390ef983d6 test(evals): pin coherent secure-entry and team repairs (#19346)
## Thinking Path

> - Paperclip manages AI agents and their work.
> - The protected TestOps catalog selects one immutable source revision.
> - The current pin predates reviewed secure-entry and Team observation
repairs.
> - A new run must use the qualified source and its exact descriptor
bytes.
> - This PR updates only the source pin, retained descriptor snapshot,
and expected-target test.
> - Existing failures remain failures until a new native run proves the
feature.

## Linked Issues or Issue Description

Refs: #19333, #19084, #18971, #19112.

**What happened?**

The current catalog points to the earlier source. It does not include
the reviewed personal entry-dialog observer, visible secure-entry
guidance, company menu navigation, Team claim attribution, or
completion-link guidance changes.

**Expected behavior**

The protected catalog must select the qualified immutable source and
verify its exact descriptor snapshot. Model, original queries, run
counts, clocks, private transfer interfaces, and retries must remain
fixed.

**Steps to reproduce**

Read the manifest target and candidate descriptor digest. Compare them
with source `7ccfc33bf074e37d8fd901a6e8453d1b45307e82` and its committed
descriptor bytes.

## What Changed

- Pin source `7ccfc33bf074e37d8fd901a6e8453d1b45307e82`, tree
`5afa0cf2e8ad8d17b7563e62378b0994f7777c67`.
- Store the exact candidate descriptor snapshot with SHA256
`e1b7de947567569d96fcc9dca607ef5807ffaba4bf994562c0c7ab46d1856df6`.
- Update current version and source-file provenance while retaining the
original anchors and prior conditions.
- Update one expected-target assertion. This PR changes exactly three
metadata/test files. The final target-only successor retains the
previous pin commit and its CI results; descriptor bytes do not change.

## Verification

- 41 model-free manifest, adapter, reconciliation, and CLI controls
pass. Another 42 chat-admission controls pass.
- Initial source qualification: 268 focused controls, five explicit
offline Chromium controls, and full E2E types pass. The first six-path
Company/Team amendment passes 233 affected controls and full E2E types.
The final reviewed six-path followup passes 271 affected controls, two
offline browser canaries and full E2E types. Unchanged source inputs
reuse the prior qualification. The accepted completion-feedback core
patch has 22 real PostgreSQL controls from its owner.
- All 244 scenario YAML definitions and all 242 descriptor run counts,
clocks, authentication, and setup policy remain unchanged from the
previous source. Seven descriptor rows change only versions or
source-file lists.
- SDK506 inputs and registry `efa70621` remain unchanged. Launcher
SHA256 `2b9a6953` and private transfer interfaces remain fixed.
- Fresh-main reporting installation passes with pnpm9.15.4, frozen
lockfile, ignore-scripts, and offline mode. The unchanged reviewed
report policy returns `already-reviewed`. No lock or workflow change is
included.
- Repo-wide build/typecheck were not repeated for this three-file
metadata update. Normal PR CI remains required.

## Risks

- Both secret journeys require independent review of the actual native
handoff before any PASS credit. Unsafe value requests cannot count as a
feature pass even if an oracle accepts them. Two additional unexercised
adversarial wording guards (comma-only plaintext destinations and mixed
reference/password requests) are being hardened separately in #19093.
They are not included in this source pin. No current native PASS is
claimed.
- This pin includes reviewed source changes whose separate core/catalog
PRs remain unmerged. This PR does not merge those features into master.
- New native measurements remain required. The prior personal failure
remains failed; its first native took 580602ms, and completion within
the unchanged 660s remains unproven.
- The plain-comment save acknowledgment fixes a downstream phase that
the failed attempt did not reach. Component checks do not prove native
completion.

## Model Used

OpenAI Codex, GPT-6.1 Sol (`gpt-6.1-sol`), with code execution and
repository tools. The runtime does not expose its 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
2026-11-05 16:05:01 -06:00
DottaandPaperclip 789a71bc17 fix(runner): retry quarantined tasks in their saved workspace (#19340)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Native sessions retain execution ownership and action history across
turns.
> - Task Retry must prove that old execution has stopped before it
starts another turn.
> - An attempt can inherit its predecessor's identity and fail before it
launches a provider.
> - The cleanup proof searched under that failed attempt and compared
unrelated event sequences.
> - This pull request verifies the retained owner and starts one fresh
authorized turn.
> - Saved results and uncertain action outcomes remain intact.

## Linked Issues or Issue Description

**What happened?** Task Retry accepted repeated clicks but kept the
canonical request deferred with `executionWait.reason: local_cleanup`.
It created no successor, although the retained local worker and provider
had stopped.

**Expected behavior:** After exact cleanup proof, admit one fresh turn.
Preserve the old journal and result. Keep unresolved action outcomes
unknown.

**Steps to reproduce:**
1. Finish a local native turn with retained cleanup state and a saved
result.
2. Let the next attempt inherit its identity and fail with
`native_session_cleanup_quarantined` before any launch.
3. Upgrade across a tool-contract change, then click task Retry.
4. The old code requires the failed attempt's stop receipt and journal
identity. It also requires the current tool fingerprint and equal
sequence numbers across raw and normalized events. Those requirements
cannot match the retained owner.

**Paperclip version or commit:** Reproduced on `31bf6e4482`.
**Deployment mode / installation method:** Authenticated, self-hosted
source checkout.
**Agent adapter(s) involved:** Native `paperclip_runner`, local Codex
app-server. The shared physical-stop proof also covers ACPX.
**Database mode:** Embedded PostgreSQL 18.1.
**Access context:** Board task Retry.
**Node.js version / operating system:** Incident: Node 24.20.0, Linux
ARM64. Local verification: macOS ARM64.
**Relevant logs or output:** Accepted Retry stays in
`deferred_issue_execution`; no new run or provider launch occurs.
**Relevant config:** Per-turn local native execution. The old tool
contract differs from the current contract.
**Additional context:** Related: #19311 prevents the oversized tool
result that can lead to retained cleanup. #18217 covers broader cleanup
isolation and retained-result maintenance. #19134 admits stopped Runner
sources under the current run lease. This patch fixes explicit
continuation admission on current master.

## What Changed

- Resolve the retained journal's owner under the same company, task,
agent, workspace, native session, and runner instance.
- Require terminal ownership, settled controllers, released local
leases, and exact inherited process birth. Refuse any launch evidence on
the failed attempt.
- Accept a current host's verified process absence from its exact launch
receipt when an older server lacks a stop receipt. A later launch
invalidates that observation.
- Validate normalized receipts against their own IDs, sequences, and
digests. Match ordered provider identities to the independent raw
journal.
- Keep tool compatibility at the session reuse boundary. Explicit
continuation always uses a fresh session.
- Bind the stop proof to its exact successor and canonical Retry
receipt. Reuse the proven local workspace through normal preparation.
Refuse changed bindings, closed or remote workspaces, pending
operations, and other live leases. Projectless run-ID placeholders keep
the existing fresh-workspace fallback.
- Retain journals, results, files, and uncertain action outcomes. Add
regression and opt-in live acceptance coverage.
- Make the split-handoff browser test wait for both child-completion
notices and all run settlement before teardown. Assert the final task
set stays unchanged.

## Verification

- Red: canonical Retry on the original code accepts one saved intent but
creates zero successors and records `local_cleanup`.
- Red: distinct raw and normalized event sequences reproduce that wait
after owner resolution alone. After admission was repaired, live
acceptance then exposed the empty-attempt workspace problem. A
PostgreSQL regression also reproduced that wrong workspace selection.
- Green at `6684df5e82`: **479 targeted cases**, including 26 new
PostgreSQL cases for duplicate clicks, exact process and workspace
ownership, controller/lease fences, changed state, and independent
receipt integrity. The complete 1,150-test native executor suite passed
earlier.
- `pnpm -r typecheck` and `pnpm build` pass again at final head
`432a52bea8`, including its build stamp. Token gates pass. Master now
contains the unrelated directory-fixture type correction found during
the first typecheck.
- Real authenticated HTTP Retry with Codex `gpt-6.1-sol`, high effort,
and per-turn execution passes again at final head `432a52bea8` (93.3
seconds). It preserves the first file line, appends the second once,
starts a fresh session in the existing workspace, keeps the retained
journal unchanged, commits finalization, and clears task locks.
- The strengthened split-handoff browser scenario passes **three
consecutive local runs**. Its original CI teardown and one same-head
rerun failed when cleanup cancelled an active legacy
completion-notification run and hit a PostgreSQL row-lock timeout. The
scenario now waits for the complete handoff before cleanup. [Initial
failure](https://github.com/paperclipai/paperclip/actions/runs/42106466518/job/127523693634),
[same-head
rerun](https://github.com/paperclipai/paperclip/actions/runs/42106466518/job/127531698321).
These failures remain part of the verification record.
- The local full `pnpm test:run` passed all six chat integration shards.
Its obsolete pre-rebase attempt was stopped during the general server
phase; no complete local-suite pass is claimed. Full CI, including both
required gates, passed at `6684df5e82`. At final head `432a52bea8`, all
initial CI groups passed except the unchanged status-card deadline test,
whose post-wakeup clock assertion missed its bound by 10 ms. That exact
case passed three unchanged local repetitions (16.8/27.0/18.3 seconds);
the single isolated shard rerun passed all **2,218 tests** (123 files),
with no source changes. [Initial timing
failure](https://github.com/paperclipai/paperclip/actions/runs/42114473652/job/127550722187).
- Greptile reviewed `6684df5e82` at **5/5**, with no actionable
findings. A second reviewer identified the supported projectless
placeholder case. A new real PostgreSQL regression reproduced its
workspace-binding failure before the one-line fallback correction; all
**45 focused cases** now pass, including default environment selection
and changed binding/cwd refusal. Greptile reviewed final head
`432a52bea8` at **5/5**, with no blocking findings. The second
reviewer’s thread is resolved.
- The patched Linux build verified the actual retained worker/provider
ownership and process absence in a transaction that was rolled back. No
retained state was retired or provider started during that
pre-deployment check.

## Risks

- This changes an execution admission proof. Incorrect ownership could
permit a second executor. The proof retains process, controller, lease,
scope, journal, and receipt fences, and duplicate admission is tested
through the real queue.
- Missing or conflicting evidence remains deferred. Windows, remote
execution, automatic replacement, and session reuse retain their
existing policies.
- No database migration or UI change. The original affected task still
needs deployment of the fix before recovery can be claimed.

## Model Used

- OpenAI GPT-6 through Codex, with reasoning, repository tools, code
execution, SSH diagnostics, and live provider testing. This session does
not expose the exact backend model build or context-window size. The
live test agent uses OpenAI `gpt-6.1-sol` at high effort.

## 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-11-05 16:04:38 -06:00
DottaandClaude Opus 5.5 b4cc2d30d2 fix(e2e): grade only started runs and bound the clarification readback (#19335)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - Product E2E journeys grade agent work in the QA staging smoke plan
> - On the current QA deployment, two journeys failed after the product
had already done the requested work
> - protected-actions counted a wake that the control plane retired
before it started as a bound run, and failed its runtime binding check
> - question-answer-resume waited for its saved document in a view that
no longer exists. The wait lasted 27 minutes, until the case deadline,
and starved the run queue
> - This pull request grades only runs that started provider work, and
reads the document where the UI now shows it, with a bounded wait
> - The benefit is that both journeys measure the product, and a UI
readback failure costs about two minutes instead of a whole worker

## Linked Issues or Issue Description

**What happened?**
- protected-actions: the task succeeded with two runs. A third
automation wake for the same agent and task was cancelled before it
started, with the reason "Agent cannot start work while completed runs
await accounting". Its `startedAt` was null, its
`resultJson.cancellation` had `source: "control_plane"` and `expected:
true`, and its `executionRecovery.providerWorkStarted` was false. That
run has no runtime binding, so `validateAgentTaskState` failed with
`agent_run_binding_mismatch`.
- question-answer-resume: the agent saved the requested document and the
task was done by 19:32. The journey then navigated to `#document-<key>`
and waited until 19:59 for an element that never appeared. With the task
chat shell and Artifacts V1, documents render in the properties pane's
Artifacts tab. The run reported `journey_operation_failed` and
`evidence_collection_timeout`, and the 60-minute job ended before four
other cases could run.

**Expected behavior**
- A wake retired before admission is kept as evidence but is not graded
as provider work.
- The saved document is read in its current view, and a UI readback
failure ends quickly.

**Steps to reproduce**
QA staging smoke launch 3074 on app cb8df178c8. The stack-side run
records are described above.

**Paperclip version or commit**
master at 03eb49053f.

## What Changed

- `agent-flows.ts`: add `retiredBeforeProviderStart(run)`. The run must
have status `cancelled` and `startedAt === null`, a control-plane
cancellation with `expected: true`, and
`executionRecovery.providerWorkStarted === false`.
`validateAgentTaskState` still checks such a run's company, agent and
task binding and counts it toward the run limit, then skips the runtime
checks.
- `clarification-flow.ts`: after reload, open the Artifacts tab with the
existing `openDocumentAuthoring` helper before reading the document.
task-dependency-resume uses the same path and passes on this deployment.
The UI readback is capped at 2 minutes after the API returned the saved
document. Agent work time is not changed.
- `agent-evidence.test.ts`: the retired wake is accepted. Nine variants
still fail: a started run, a missing `startedAt`, a failed status, an
unexpected cancellation, an operator source, `providerWorkStarted:
true`, missing recovery evidence, another agent, and another task. The
run limit still applies.

## Verification

- `npx vitest run --config tests/runner-e2e/vitest.config.ts
tests/runner-e2e/product-journeys`: 46 files passed.
- Negative control: without the skip, the new test fails.
- `clarification-readback.spec.ts` (browser support): 6 tests passed.
- `tsc -p tests/runner-e2e/tsconfig.json` shows no errors in the changed
files.
- Not verified live yet. QA uses the pinned harness, so the pin must
move to a commit that contains this change.

## Risks

- The exclusion is narrow, and every field it requires is positive
evidence that the wake did no work. Any started or unexpected extra run
still fails.
- The readback cap is stricter, not looser. It applies only after the
API has confirmed the document. Agent work and answer timing still use
the existing deadlines.

## Model Used

- Claude Opus 5.5 (`claude-opus-5-5`), Anthropic, via Claude Code with
tool use (shell, browser, code editing). Extended reasoning was used.

## 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

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

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-05 14:39:18 -06:00
DottaandClaude Opus 5.5 1c165e9f1e fix(ui): bound the queued-message strip so it scrolls instead of covering the conversation (#19321)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - In task chat, a user can queue messages while an agent run is
active. The queued messages show in a strip above the composer, with
Steer, Interrupt, Discard and Edit actions.
> - An onboarding test on staging reported that the steering strip
clipped and covered nearby UI.
> - The strip adds one 44px row for each queued message and has no
height limit. With several queued messages it takes most of the thread.
In the Coordinator layout the dock is absolutely positioned at the
bottom of the thread, so the strip grows up over the conversation.
> - This pull request puts the rows in a bounded list that scrolls. The
status and error lines stay below the list.
> - The benefit is that the conversation stays readable at desktop and
narrow widths, and every queued message stays reachable.

## Linked Issues or Issue Description

**What happened?**
With several queued messages, the queued/steering strip above the task
composer grew without a limit. It covered the transcript and nearby
components. At a 1024x600 window, 8 queued messages made the strip 353px
tall in a 555px thread.

**Expected behavior**
The strip stays readable and inside the available space at normal and
narrow widths. Extra queued messages scroll inside the strip.

**Steps to reproduce**
1. Open a task with an active run in the Coordinator workspace.
2. Queue 6 or more messages.
3. See that the strip covers most of the conversation.

**Paperclip version or commit**

`master` at 03eb49053f. Also seen on a staging cloud deployment during
an onboarding test (BUG-04, P2).

## What Changed

- `TaskChatQueuedMessages`: wrap the sortable rows in a list with
`max-h-(--tc-queued-list-max-h) overflow-y-auto overscroll-contain`.
Status and error lines stay outside the list, so they are always
visible.
- `ui/src/index.css`: new token `--tc-queued-list-max-h:
min(calc(var(--spacing) * 40), 28dvh)`. This is about 3.5 rows, and less
on short windows.
- New Storybook story `coordinator-dock-queued-messages`: the production
`TaskChatComposerDock`, queued strip and composer inside the Coordinator
thread layout, with 8 long queued messages (light, dark, phone).
- New Playwright spec
`tests/storybook-visual/queued-messages-dock-layout.spec.ts`: measures
the dock and strip against the header, thread and viewport at desktop,
desktop dark, short desktop (1024x600), very short desktop (1024x420)
and phone sizes. It also checks that the last queued Steer action is
reachable by scrolling, and that the latest transcript message is not
under the dock. A separate test drags the first queued row below the
third and checks the new order inside the scrolling list.

## Verification

Red first (spec run on unchanged `master` code, Storybook dev server):

```
STORYBOOK_TEST_BASE_URL=http://localhost:6016 npx playwright test --config tests/storybook-visual/playwright.config.ts --project=stories tests/storybook-visual/queued-messages-dock-layout.spec.ts --retries=0 --workers=1
  ✘  1 … queued messages stay bounded inside the composer dock (desktop)
  ✘  2 … queued messages stay bounded inside the composer dock (desktop dark)
  ✘  3 … queued messages stay bounded inside the composer dock (short desktop window)
  ✘  4 … queued messages stay bounded inside the composer dock (narrow phone)
    Error: queued strip covers the conversation
    Expected: <= 286
    Received:    353
    …
    Error: queued strip covers the conversation
    Expected: <= 222
    Received:    353
  4 failed
```

Green after the fix (same command):

```
  ✓  1 … queued messages stay bounded inside the composer dock (desktop) (14.8s)
  ✓  2 … queued messages stay bounded inside the composer dock (desktop dark) (3.3s)
  ✓  3 … queued messages stay bounded inside the composer dock (short desktop window) (2.1s)
  ✓  4 … queued messages stay bounded inside the composer dock (narrow phone) (2.3s)
  4 passed (25.7s)
```

Second round, after review feedback that a fixed 160px cap does not
shrink on very short windows. Red with the fixed `max-h-40` cap:

```
  ✓  1 … (desktop)
  ✓  2 … (desktop dark)
  ✓  3 … (short desktop window)
  ✘  4 … (very short desktop window)
  ✓  5 … (narrow phone)
  ✓  6 … queued messages still reorder by drag inside the scrolling list
    Error: queued strip covers the conversation
    Expected: <= 150
    Received:    161
  1 failed
  5 passed (18.6s)
```

Green with the `--tc-queued-list-max-h` token:

```
  ✓  1 … (desktop) (6.2s)
  ✓  2 … (desktop dark) (1.9s)
  ✓  3 … (short desktop window) (3.3s)
  ✓  4 … (very short desktop window) (1.3s)
  ✓  5 … (narrow phone) (1.4s)
  ✓  6 … queued messages still reorder by drag inside the scrolling list (1.5s)
  6 passed (16.1s)
```

Measured layout (strip height / dock top in a thread):

| Case | Before | After |
| --- | --- | --- |
| 1245x760 dark | strip 353px, dock top 272 | strip 161px, dock top 464
|
| 1024x600 | strip 353px, dock top 112 | strip 161px, dock top 304 |
| 390x700 phone | strip 353px, dock top 228 | strip 161px, dock top 420
|

Neighbouring suites and gates:

- `cd ui && npx vitest run src/components/task-chat/`: 55 files, 884
tests passed (includes `TaskChatQueuedMessages.test.tsx`).
- `pnpm check:token-gates`: All gates clean.
- `node scripts/storybook-catalog.mjs`: in sync.

Screenshots (1024x600, then 390x700; taken with the first-round 160px
cap, which is the same height at these sizes):

| Before | After |
| --- | --- |
| ![before short
desktop](https://raw.githubusercontent.com/paperclipai/paperclip/0cb0f9537f4ec3f226ff974ee0f895cccebb706b/before-short-desktop.png)
| ![after short
desktop](https://raw.githubusercontent.com/paperclipai/paperclip/0cb0f9537f4ec3f226ff974ee0f895cccebb706b/after-short-desktop.png)
|
| ![before
phone](https://raw.githubusercontent.com/paperclipai/paperclip/0cb0f9537f4ec3f226ff974ee0f895cccebb706b/before-phone.png)
| ![after
phone](https://raw.githubusercontent.com/paperclipai/paperclip/0cb0f9537f4ec3f226ff974ee0f895cccebb706b/after-phone.png)
|

## Risks

- Low risk. The change is one wrapper element with token-scale Tailwind
classes.
- Drag to reorder now happens inside a scroll container. The new spec
covers a drag reorder. dnd-kit auto-scrolls the container during a drag.
A dragged row can be clipped at the list edge while it moves, as before
at the strip edge.
- The original report mentioned a "black bar". The original screenshot
was not available. I reproduced the overlap and the unbounded growth. I
did not see a separate black bar in light or dark theme. The row action
menu uses a Radix portal, so it does not clip.

## Model Used

- Claude Opus 5.5 (`claude-opus-5-5`) in Claude Code, with tool use
(shell, browser, Playwright).

## 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: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-05 14:37:24 -06:00
github-actions[bot]andlockfile-bot 1e98aa76e3 chore(lockfile): refresh pnpm-lock.yaml (#19337)
## Thinking Path

> - Paperclip uses a dependency lock for reproducible builds.
> - Dependency changes on master need matching lock entries.
> - Paid eval reports also pin a reviewed offline correction.
> - Reports must install before paid model work starts.
> - This automated PR keeps the lock and report proof together.

## Linked Issues or Issue Description

**What happened?**

Dependency manifests on master changed after the last committed lock
refresh.

**Expected behavior**

Frozen installs must match those manifests. Eval reports must retain
matching offline lock proof.

**Steps to reproduce**

Run a frozen install before and after this lock refresh.

## What Changed

- Refresh the dependency lock from the manifests on master.
- Include the matching offline report correction and hashes.

## Verification

- Pinned pnpm resolution completed with lifecycle scripts disabled.
- The report proof refresh accepted the reviewed committed baseline.
- The workflow rejected changes outside the lock and report proof files.

## Risks

The lockfile bot merges this PR without CI or review when every added
package version is at least 3 days old on npm. Otherwise the PR waits
for a maintainer, and the daily refresh tries again. The bot merges only
the exact commit this workflow generated from manifests already reviewed
on master. Unknown report lock baselines remain blocked. This update
changes no permissions or paid enable gates.

## Model Used

None — generated by pnpm and the deterministic report-lock updater.

## Checklist

- [x] Thinking path and problem description included
- [x] Generated lock and matching report proof included
- [x] Release-age gate decides between bot merge and maintainer review

Co-authored-by: lockfile-bot <lockfile-bot@users.noreply.github.com>
2026-11-05 20:36:41 +00:00
DottaandPaperclip 6a66c09f7f test(evals): pin secure confirmation and team warning repairs (#19333)
## Thinking Path

> - Paperclip manages AI agents and human approval for work.
> - The chat catalog measures real user journeys through TestOps.
> - The last personal-secret journey reached a valid secure-save
confirmation that its observer rejected.
> - The team journey reported a missing named skill with a typographic
apostrophe that its observer rejected.
> - A company-secret request returned body validation before the
required agent authorization denial.
> - This PR pins one reviewed source that addresses these boundaries
without changing the requests, models, or time limits.
> - New native measurements must establish the result. Existing failures
remain failures.

## Linked Issues or Issue Description

Refs: #19084
Refs: #19112
Refs: #19325
Refs: #19261

This is the single successor pin for the reviewed personal confirmation,
team warning, and company authorization changes. It does not merge those
core or full-catalog branches into master.

## What Changed

- Pin immutable source `ab0f5246f765058af702b93d9b6637f2ef5b83cd`, tree
`6cf28980b0ab6d1dd8e54efda3996708c53aeb98`.
- Bind the exact descriptor snapshot
`0b57bba133a5c15860ca77b804f7282b5314d7feb8efbfd6f11fca42cdbdee49` and
matching target test.
- Advance personal-secret v9 to v10 and team-install v4 to v5. Record
the personal confirmation helper and its existing contract/flow inputs
in source provenance.
- Disclose the unmerged company-secret authorization fix from #19325. It
denies scoped agent creation before body validation and gives safe human
entry guidance. Board creation remains unchanged.
- Retain the original query history, including the single previously
approved multipart-form clarification. Preserve all 244 identities, the
196/244 gate, model, clocks, native and human bounds, SDK registry,
launcher, and private evidence protocol.

## Verification

- Pin-local checks: all **38** manifest, adapter, and reconcile controls
passed with `node --test
tests/runner-e2e/chat-full-catalog-testops-manifest.test.mjs
tests/runner-e2e/chat-full-catalog-testops-adapter.test.mjs
tests/runner-e2e/chat-full-catalog-testops-reconcile.test.mjs`.
- Exact source qualification: the combined domain run passed 328
controls and skipped one optional canary. Its two local listener
failures were sandbox EPERM setup failures. The same two controls then
passed with the authorized local listener, in a 73-control run. The
eight new route authorization controls also passed. These local runs do
not prove native completion.
- Full E2E TypeScript passed on exact source ab0 after reuse of the
healthy, same-source workspace graph. Earlier missing-alias graph
failures are retained. A full local server build or repository-wide
suite was not run; #19325 has its own core checks.
- The source SDK guard verified all **506** registered input Git blobs
unchanged, registry
`efa70621e9fb42aa185f7ee616a1a726aa3eccb367e67e28817cedf26ef2ade8`. No
SDK build or qualification renewal was needed.
- Actual anchored controller dependency check: `prepare-report-lock.mjs`
returned `already-reviewed`, then pnpm **9.15.4** completed the frozen,
ignore-scripts install in 17 seconds. This exercised the current
upstream Claude ACP patch and reporting output
`dd5934060dd06b8e731e3beeed49daf918d1a0b2a6c32d3da7815f2e7f0b3691`. It
made no tracked lock or policy change. Earlier source-lock and
controller-lock evidence remain separate.
- Existing failed personal/team attempts remain failed. The company
initial noncompletion remains uncorrected as an outcome claim; the
authorization fix addresses one proven error boundary only. Team
repeat/link checks were not reached in the failed measurement and remain
required. No uniform-ten PASS or new native feature PASS is claimed.
- Next validation is a controlled TestOps measurement after normal pin
merge and fresh actual-controller proof. Any later whole-ten regression
is separate. All attempts remain recorded; there is no retry-until-green
policy.
- Exact head `58d4a9b2d3c90be725e8877873010295122fb9c0`: required CI
aggregates `ci / e2e` and `ci / verify` passed in run 42099871883.
Windows passed in run 42099871391. Genuine Greptile review is 5/5 on
that exact head, with zero unresolved threads. The complete rollup has
56 successes, three configured skips, and one neutral check; no pending
or adverse check remains. No native measurement ran as part of these
checks.

## Risks

- Personal v10 accepts two logical human inputs: the original chat
request and a separately verified same-human secure-save confirmation.
The raw chat count remains one. This is a disclosed fixture variant, not
proof from a new native journey.
- The new confirmation fields do not change the trusted publisher schema
or its closed enums. Existing private helper and launcher bytes remain
unchanged.
- Team v5 only normalizes the apostrophe in its warning predicate. Saved
state, named-skill truth, repeat idempotency, links, and
contradictory-success guards still apply.
- The authorization fix is present only in the pinned source. #19325
remains unmerged; its effect on the unfinished native turn is unproven.

## Model Used

OpenAI `gpt-6.1-sol` through Codex, with reasoning, repository tools,
and local code execution. The context window size is not reported by
this runtime. No model inference was used for local tests.

## 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-11-05 14:22:05 -06:00
DottaandClaude Opus 5.5 aaaad177eb fix(e2e): follow renamed project and Artifacts V1 download controls (#19323)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - Product E2E journeys drive the real UI and run in the QA staging
smoke plan
> - Two UI changes landed after the previous QA deployment: the Projects
toolbar action is now "Create project" (#18716), and Artifacts V1 is on
for every instance (#19164), so attachment rows offer download as an
icon link with an `aria-label`
> - The journeys still clicked "Add Project" and required a visible
"Download" text, so they timed out before reaching the server
> - This pull request accepts both the old and the current controls
> - The benefit is that project-task-context, build-revise and
stop-redirect measure the product again on current deployments

## Linked Issues or Issue Description

**What happened?**
On the QA deployment of cb8df178c8, three journeys failed with the
generic `journey_operation_failed`: project-task-context, build-revise
and stop-redirect. Records on the stack show that build-revise and
stop-redirect delivered their ZIP and finished. The user's next
interaction never reached the server.

**Expected behavior**
The journeys use the controls that the current UI shows.

**Steps to reproduce**
1. Run the `project-task-context` product journey against a managed
local target at cb8df178c8.
2. Playwright waits 30 seconds for `getByRole('button', { name: 'Add
Project', exact: true })` and times out.
3. For downloads, an Artifacts V1 row renders `<a
href=".../content?download=1" aria-label="Download slugify.zip">` with
only an icon. `filter({ hasText: /Download/i })` matches no element.

**Paperclip version or commit**
master at 03eb49053f; deployed QA app cb8df178c8.

## What Changed

- `project-context-flow.ts`: open the new-project dialog with the button
named "Add Project" or "Create project".
- `story-artifact.ts`: find the attachment download link by "Download"
text or by an `aria-label` that starts with "Download". The attachment
ID is still required in the link.

## Verification

- Local managed target at cb8df178c8: project-task-context failed with
the old selector (Playwright timeout on "Add Project") and passed 1/1
with this change.
- A Chromium check with Playwright on V1, legacy and no-download markup:
the old locator finds 0 elements on V1 markup. The new locator finds the
download link on V1 and legacy markup, and finds nothing on markup
without a download link.
- `npx vitest run --config tests/runner-e2e/vitest.config.ts
tests/runner-e2e/product-journeys tests/runner-e2e/story-artifact`: 47
files, 1237 tests passed.
- Not run live on QA yet. QA uses the pinned harness
(`QA_SMOKE_HARNESS_SHA`), so the pin must move to a commit that contains
this change.

## Risks

- Low risk. Only the selectors change. All assertions, download checks
and artifact checks stay the same.
- The download link must still point at the exact attachment's content
route. The "Open raw" icon link is not selected.

## Model Used

- Claude Opus 5.5 (`claude-opus-5-5`), Anthropic, via Claude Code with
tool use (shell, browser, code editing). Extended reasoning was used.

## 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

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

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-05 14:19:50 -06:00
github-actions[bot]andlockfile-bot b37188ce42 chore(lockfile): refresh pnpm-lock.yaml (#19317)
## Thinking Path

> - Paperclip uses a dependency lock for reproducible builds.
> - Dependency changes on master need matching lock entries.
> - Paid eval reports also pin a reviewed offline correction.
> - Reports must install before paid model work starts.
> - This automated PR keeps the lock and report proof together.

## Linked Issues or Issue Description

**What happened?**

Dependency manifests on master changed after the last committed lock
refresh.

**Expected behavior**

Frozen installs must match those manifests. Eval reports must retain
matching offline lock proof.

**Steps to reproduce**

Run a frozen install before and after this lock refresh.

## What Changed

- Refresh the dependency lock from the manifests on master.
- Include the matching offline report correction and hashes.

## Verification

- Pinned pnpm resolution completed with lifecycle scripts disabled.
- The report proof refresh accepted the reviewed committed baseline.
- The workflow rejected changes outside the lock and report proof files.

## Risks

The lockfile bot merges this PR without CI or review when every added
package version is at least 3 days old on npm. Otherwise the PR waits
for a maintainer, and the daily refresh tries again. The bot merges only
the exact commit this workflow generated from manifests already reviewed
on master. Unknown report lock baselines remain blocked. This update
changes no permissions or paid enable gates.

## Model Used

None — generated by pnpm and the deterministic report-lock updater.

## Checklist

- [x] Thinking path and problem description included
- [x] Generated lock and matching report proof included
- [x] Release-age gate decides between bot merge and maintainer review

Co-authored-by: lockfile-bot <lockfile-bot@users.noreply.github.com>
2026-11-05 18:59:42 +00:00
github-actions[bot]andlockfile-bot b4e7b76635 chore(lockfile): refresh pnpm-lock.yaml (#19294)
## Thinking Path

> - Paperclip uses a dependency lock for reproducible builds.
> - Dependency changes on master need matching lock entries.
> - Paid eval reports also pin a reviewed offline correction.
> - Reports must install before paid model work starts.
> - This automated PR keeps the lock and report proof together.

## Linked Issues or Issue Description

**What happened?**

Dependency manifests on master changed after the last committed lock
refresh.

**Expected behavior**

Frozen installs must match those manifests. Eval reports must retain
matching offline lock proof.

**Steps to reproduce**

Run a frozen install before and after this lock refresh.

## What Changed

- Refresh the dependency lock from the manifests on master.
- Include the matching offline report correction and hashes.

## Verification

- Pinned pnpm resolution completed with lifecycle scripts disabled.
- The report proof refresh accepted the reviewed committed baseline.
- The workflow rejected changes outside the lock and report proof files.

## Risks

The lockfile bot merges this PR without CI or review when every added
package version is at least 3 days old on npm. Otherwise the PR waits
for a maintainer, and the daily refresh tries again. The bot merges only
the exact commit this workflow generated from manifests already reviewed
on master. Unknown report lock baselines remain blocked. This update
changes no permissions or paid enable gates.

## Model Used

None — generated by pnpm and the deterministic report-lock updater.

## Checklist

- [x] Thinking path and problem description included
- [x] Generated lock and matching report proof included
- [x] Release-age gate decides between bot merge and maintainer review

Co-authored-by: lockfile-bot <lockfile-bot@users.noreply.github.com>
2026-11-05 17:40:05 +00:00
DottaandPaperclip 3fca8a1500 test(evals): renew the reporting lock after iMessage update (#19283)
## Thinking Path

> - Paperclip verifies the selected source and reporting dependencies
before it obtains model credentials.
> - The reporting helper admits only an exact reviewed lock or its exact
reviewed correction.
> - Master updated the iMessage dependency and protobuf after the last
reporting-policy review.
> - The controller lock therefore stopped matching either admitted hash.
> - A real five-case launch failed at this guard before any case
execution.
> - This PR renews the exact hashes and keeps the existing patch and
rejection mechanism unchanged.
> - A normal-CI repository check now exercises the real helper against
the committed lock before paid execution.

## Linked Issues or Issue Description

Refs: #19261, #18914.

**What happened?**
The five selected execution jobs in the retained launch 3002 stopped
during “Verify source-bound build and authenticated selection before
credentials.” The first observed error was `Reporting lock changed;
review the dependency correction before install` in the trusted
controller helper. Model-key and original case execution steps were
skipped. The failed attempt remains infrastructure evidence; this PR
makes no native product-grade claim.

**Expected behavior**
Admit the exact reviewed current controller dependency graph. Keep
rejecting unknown locks, changed correction patches, and wrong output
bytes before credentials or provider execution.

**Steps to reproduce**
Run the reporting helper against the committed current-master lock. The
parent policy recognizes 754… and 60f…, while the actual controller lock
is 6f252b…. The parent stops at the same pre-credential boundary as AWS.
The existing correction patch reverses and reapplies cleanly to that
lock.

## What Changed

- Renew only the reporting policy input and output SHA256 values. The
output is the exact committed current-master lock after
`@photon-ai/advanced-imessage` 2.1.0→2.2.0 and `@bufbuild/protobuf`
2.15.0→2.16.0.
- Derive input
`ea91060774e3289d5d07bc58f72d8953f5a6dcb9db98aa9a1adf202476bf89ac` by
reversing the existing correction patch from the current lock.
Reapplying that byte-identical patch yields output
`6f252b0c8099ed837a297f97f1fc5e14e96bc7530b0239065d0789b33b2ee477`
exactly.
- Keep patch SHA256
`2adced9a66052ba5752140ec6cc6670f679552a9a8559bd1faea10036afeeb97`,
helper code, and guard behavior unchanged. Update the policy basis to
describe the review truthfully.
- Add one normal server-suite check. It copies the committed lock and
reviewed policy into a temporary directory and runs the real helper. The
prior focused suite already covered this contract, but its runner-e2e
location is outside normal root Vitest projects.
`server/vitest.config.ts` already includes `scripts/**/*.test.mjs`; no
workflow change is needed.

No `pnpm-lock.yaml`, workflow, source pin, descriptor, oracle, model,
permission, credential, scanner, or case bound changes. Immutable source
6773 and the failed launch remain unchanged.

## Verification

- Parent existing reporting suite: 4 fail and 3 pass because the
committed lock is outside the admitted pair. Renewed policy: all 7 pass,
including unknown-lock, changed-patch, wrong-output, and refresh-path
rejection controls.
- New normal-CI repository control fails with the exact paid-step
reporting-lock error on the parent policy. The corrected combined run
passes 8 controls across 2 suites.
- Exact patch reverse/forward roundtrip preserves the full current lock
bytes. The actual CLI returns `already-reviewed`; the working lock hash
stays 6f252b… and is not modified.
- Focused command: `node node_modules/vitest/vitest.mjs run --config
../report-lock-imessage-vitest.config.mts`. The external local config
selects only the two affected suites with the existing 30-second test
limit.
- `git diff --check` passes. No SDK/native/source build, model call,
evaluation retry, or private archive download was needed for local
proof. Full workspace typecheck/build were not run for this
policy-and-test change. Latest-head required CI and genuine review
remain pending.

## Risks

This policy deliberately rejects the next unreviewed lock change. The
normal-CI check should expose that drift before paid fanout. The input
is the current lock with the already approved correction reversed; it is
not a claim that a new dependency graph was resolved or installed
locally. Local guard controls do not prove a repaired AWS execution or
any of the five product journeys. The next measured attempt still
requires normal protected merge and fresh actual-controller admission.

## Model Used

OpenAI `gpt-6.1-sol`, with reasoning, repository tools, and local code
execution. The host did not expose a 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
- [ ] 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-11-05 11:32:46 -06:00
DottaandClaude Opus 5.5 45073d97ae fix(evals): keep evidence for wakes retired by a terminal issue before start (#19258)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - The Product regression TestOps plan runs 20 Product E2E cells, and
each cell saves run evidence after grading
> - In the final full run, `first-task/clarify-propose-accept` passed
every journey check
> - The cell still failed while saving evidence: it requested a provider
log for a wake that never started
> - That wake was retired with `issue_terminal_status` because its child
task was already done, so no log exists
> - The settle oracle already accepts such a wake
(`isTerminalUnstartedWake`), but the evidence collector did not
> - This pull request records that wake's log as omitted, with a reason,
and keeps its events
> - The benefit is that a passing journey is no longer reported as
failed because of a log that never existed

## Linked Issues or Issue Description

Refs #19073, #19243

**What happened?**
In GitHub run
https://github.com/paperclipai/paperclip/actions/runs/42046147744,
`first-task.runner-codex.local.clarify-propose-accept` had no failed
checks in `first-task.json`. The conversational acceptance was recorded
through `resolve-from-comment` (200). The `finally` evidence step then
threw `GET /api/heartbeat-runs/ef2295c4…/log returned 404: Run log not
found`. Run `ef2295c4` is an `issue_status_changed` wake on the
completed child task. It is `cancelled` with `issue_terminal_status`,
and `startedAt`, `logStore` and `logRef` are all null.

**Expected behavior**
Evidence capture keeps that wake's events and records why it has no log,
as it already does for reset, blocked, reassigned and pre-provider runs.

**Steps to reproduce**
Run the cell. A child status-change wake may be queued just before the
child becomes `done`, and is then retired before admission.

## What Changed

- `collectChatRunEvidence` (`tests/runner-e2e/chat-flow.ts`): a run that
is `cancelled` with `errorCode: issue_terminal_status` and explicit null
`startedAt`, `logStore` and `logRef` gets `log: null` and
`logOmissionReason: "issue_terminal_before_start"`. Its events are still
collected.
- `chat-flow.test.ts`: a test for that case, plus negative controls.
Each of the following still fails on a missing log: started, `startedAt`
undefined, `failed` status, a different error code, a log store, a log
ref.

## Verification

- `npx vitest run --config tests/runner-e2e/vitest.config.ts
tests/runner-e2e/chat-flow.test.ts tests/runner-e2e/first-task.test.ts
tests/runner-e2e/continuation.test.ts`: 378 pass.
- `tsc -p tests/runner-e2e/tsconfig.json`: no errors in
`tests/runner-e2e`.
- Retained artifact from run 42046147744 (cell
`clarify-propose-accept`): there are no failed checks, and the run
ledger shows the retired wake with null `startedAt`, `logStore` and
`logRef`.

## Risks

- Low. This is an evidence-capture change in the eval harness, and the
journey's grading is unchanged. The omission needs explicit positive
evidence that the run never started and never had a log store. Any run
that did provider work still fails on a missing log.

## Model Used

- Claude Opus 5.5 (`claude-opus-5-5`), via Claude Code with tool use 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

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

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-05 10:07:05 -06:00
DottaandPaperclip cb8df178c8 test(evals): pin the clarified five-case chat repairs (#19261)
## Thinking Path

> - Paperclip helps people manage AI agents and their work.
> - The TestOps catalog executes one reviewed immutable source with
declared model, permissions, counts, clocks, and private evidence gates.
> - Recent retained attempts exposed specific question, timeline,
secret-handoff, and team-reporting contract gaps.
> - Five focused repairs now have one qualified source; their component
checks do not establish a native pass.
> - This PR binds the trusted catalog lane to that source and records
its exact changed definitions.
> - One visible-form question is clarified and disclosed; all other
catalog requests stay fixed.
> - The controller, launcher, private evidence helpers, and execution
authority stay unchanged.

## Linked Issues or Issue Description

Refs: #19086, #19084, #19093, #19112, #19148, #19188.

**What happened?**
The retained native attempts include a timeline narrative rejected
despite the saved handoff, secure-entry admission failures before
downstream verification, and a truthful contextual team caveat rejected
after a correct repeat. Multipart attempts4623 and4717 did not complete
under the original broad request. All original statuses and evidence
remain unchanged.

**Expected behavior**
Measure the five reviewed repairs on one immutable source with the
original model, limits, and privacy gates. A component replay must not
rewrite an old result or count as a product pass. The catalog must
display and execute the same versioned request.

**Steps to reproduce**
After normal protected merge and fresh controller admission, use the
existing TestOps plan102 and job100 to select the intended five cases on
master. Root owns the actual Submit and original-evidence review. No
evaluation is dispatched by this PR.

## What Changed

- Pin only the catalog lane to
`6773b1c128a2e7efa7571ff04b38238f00d06117`, tree
`5669b199edc1aed3ab812403407b5930f5127da4`.
- Copy its exact descriptor snapshot, SHA256
`aaf15ca6755fcfe550daa98bca1ed263e3d625159b53cd1e1f52fefbf9474778`.
Advance only multipart53 v4, timeline466 v10, company-secret578 v8,
personal-secret580 v9, and team-install610 v4. Add four declared source
paths across the two secret cases.
- Record exactly one query clarification through the existing per-case
changed-field join. Old: “Help me choose the details for the launch page
before you build it.” New: “Walk me through the launch-page question
form so I can choose the audience and tone and enter my own headline
before you build anything.” Preserve the old query and failed results in
history. Retain inventory `0cf530…` and disclose clarified inventory
`814bb363…`. All other243 catalog requests are unchanged.
- Disclose that the company-secret second human message now uses actual
saved non-secret metadata instead of repeating the initial request. Its
continuation still requires the actual agent identity. No fabricated
agent comment or private value establishes the handoff.
- Team recovery uses independent saved canonical skill/version/member
proof. No recovery-success phrase is required. A contradictory current
denial still fails; a still-missing skill still requires truthful
disclosure.
- Keep all244 identities, the196/244 admission gate, model/profile,
human/native counts, clocks, retries0, cap8, launcher, private protocol,
and SDK506/efa qualification unchanged. No product code, full catalog,
workflow, permissions, secret, runtime, or helper change lands on
master.

## Verification

- Source owner qualification:680 affected controls on the accepted
parent and213 focused successor controls plus two explicit browser
canaries, fresh same-source server declarations, and full E2E TypeScript
pass on localNode26.4.0. Registered SDK506 Git inputs, production
source, private protocol, launcher, and original limits match the
accepted source. The source-only contract/flow additions are not copied
into this controller.
- Pin-local command: `node --test
tests/runner-e2e/chat-full-catalog-testops-manifest.test.mjs
tests/runner-e2e/chat-full-catalog-testops-reconcile.test.mjs
tests/runner-e2e/chat-full-catalog-testops-adapter.test.mjs` —38 pass.
- Exact source descriptor and launcher bytes match the bound hashes. The
manifest keeps the original metadata source and source history, joins
the new descriptor, and permits only the one explicitly recorded53 query
clarification. `git diff --check` passes.
- Warm controller admission:10 committed helper byte checks, five
required source matches, and four trusted module imports passed with the
existing exact-main60f dependency graph. No SDK or native rebuild ran.
Actual post-merge master and imports still require a fresh check before
Submit.
- The53 clarification changes the evaluated question. It does not fix or
regrade the original300-second failures. All form validation, back
retention, custom answer, persisted-answer, continuation, and
visible-summary checks remain required. One targeted post-clarification
measurement is planned; any later whole-ten regression is separate, with
all attempts retained and no retry-until-green. The existing case53
description must be updated and read back after merge so TestOps
displays the clarified request.
- All five successor scenarios remain unrun. No new native pass,
uniform-ten pass, reliability claim, or master catalog qualification is
made. Focused source PRs remain separate and unmerged; their independent
CI does not replace this PR's required checks.
- Full workspace typecheck/build were not run locally for this
metadata-only PR. Current-head required CI, Windows, genuine review, and
zero unresolved material threads are required before normal protected
merge.

## Risks

A wrong source or descriptor would misstate the measured definition.
Strict target, snapshot, field, and identity joins cover that risk. The
clarified question cannot establish success for the old broad request.
Safe guidance admission still needs real human entry, private UI
persistence, and worker evidence in the next attempt. Component controls
do not prove those outcomes or completion within the original limits.

## Model Used

OpenAI `gpt-6.1-sol`, with reasoning, repository tools, and local code
execution. The host did not expose a 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
- [ ] 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-11-05 10:00:50 -06:00
TonioandPaperclip 56517dda6c fix(ui): bundle connector, toolbar, empty-state and agent roster fixes (#18716)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Operators use connector setup, collection headers, empty states, and
agent lists to manage that work.
> - Provider redirects replace the setup page, and collection controls
use different sizes.
> - Agent selection inserts a bar above the list. The row link
highlights only part of the row.
> - This pull request keeps sign-in in a separate window and applies the
Tasks control sizes to collection and audit headers.
> - It also reuses artifact artwork for empty collections and gives
agent selection a fixed action card.
> - These changes preserve the operator's place and keep controls and
rows stable.

## Linked Issues or Issue Description

**What happened?**

Connector sign-in replaced the current page. Inline collection controls
had different heights. Projects and Artifacts used small placeholder
empty states. Agent selection moved the list, hover covered only the
identity cell, and chat/status shared that cell without matching
headings.

**Expected behavior**

Provider sign-in opens in a new tab or window. Collection controls match
Tasks. Empty collections use the large artifact graphics. Agent actions
float above the page while rows remain aligned.

**Steps to reproduce**

Start connector sign-in from a page or dialog. Compare collection and
Audit headers. Open an empty Projects or Artifacts collection. Select an
agent, then hover across its row.

Related public work: #13584 covers an earlier connector new-tab
implementation, including same-page fallbacks that this bundle does not
use. #8528 covers Tasks toggle sizing. #17742 covers scoped agent Audit
sections. This bundle does not change server callback or audit
authorization contracts.

## What Changed

- Reserve a separate authorization window during the click. Use
validated sign-in URLs, retain a new-tab fallback, and close blank
windows after failed requests. Store Cloud reauthentication state in the
destination window.
- Use the Tasks 44px control foundation for shared collection headers
and Audit, Costs, Timeline, Secrets, Teams, Gateways, and agent skill
controls.
- Use a large artifact stack with an off-white Paperclip image with a
dark icon for Projects and artifact Tasks empty states. Use one matching
artifact for other types. Set 20px gaps and use the label “Create
project”. Action hover and keyboard focus animate the artwork.
- Portal agent bulk actions to a fixed card 48px above the bottom safe
area. Use quintic entry/exit motion and respect reduced motion. Retain
card contents during exit.
- Give chat and status separate cells, add a Status heading, use the
MessagesSquare chat action with a hover tooltip, and highlight the
entire row.
- Add linked agent chips and a manager picker to the agent profile.
Block self and descendant manager choices. Keep the name crown and
custom title inline during edits.
- Update design guidance, the connection maps, regression tests, and
empty-state Storybook fixtures.

## Verification

- Final commit `a41a6c6494a839deaaec1ef7cc50c90078ab6381`: all 55 checks
passed, three skipped. [Canonical CI
run](https://github.com/paperclipai/paperclip/actions/runs/41999792769)
includes all eight browser shards and all server/runner/workspace
groups. Greptile: 5/5, zero unresolved review findings.
- Workspace typecheck/build passed. Local UI suite passed 11,006 tests
in 880 files, plus 542 CLI tests. Subsequent connector callback changes
passed all 245 AppsConnect tests, UI typecheck, token gates, and
query-error policy checks. Manager cache/error regressions passed four
tests. Map checks passed.
- Local connector browser suite: 20 passed. All six chat integration
shards: 1,931 passed. Workspace B groups passed; database tests passed
313 cases across 72 files with one worker.
- Browser preview verified agent manager changes, overview links, inline
name/title geometry, empty-state colors, row actions and the chat
tooltip. Live provider consent and post-deployment feature verification
remain separate from these fixtures.
- Preserved failures: ten bulk-roster tests initially missed the
portaled action card; their selectors were fixed and all twelve roster
tests passed. A nested fixture selected pnpm 11 and removed local
dependencies; the local shim now pins pnpm 9. Embedded PostgreSQL native
links were restored. A Python 3.9 fixture failure passed all 19 tests
with the current runtime. Concurrent local database startup failures
passed on the one-worker rerun.
- The broad local serialized server run passed 3,791 tests with one
scheduling assertion failure, which passed in isolation. The local
general-server run reproduced a native recovery provider/model fixture
failure and has not completed. These server sources are unchanged by
this bundle; all final canonical CI server shards passed. This is not a
claim that every broad local run passed.
- [Earlier CI
run](https://github.com/paperclipai/paperclip/actions/runs/41995119880)
failed a browser test during cleanup when heartbeat-run cancellation hit
a PostgreSQL lock timeout. All final browser shards passed without
weakening that test.
- Review follow-ups cover Slack popup/fallback recovery, a single
artwork hover transform, shared manager error rendering, detached
standalone OAuth windows, and verified task-bound callbacks in both
hosts.

## Risks

- Browser popup policy and provider callback behavior can affect sign-in
completion. The original setup page stays open; blocked windows have an
explicit recovery path.
- Shared toolbar styles affect several surfaces. Menu content remains in
its existing portals; canonical label tabs and search clear buttons
retain their own geometry.
- No schema, server, API authorization, or migration change.
- Required CI and review are complete. Deployment provenance and hosted
feature verification are checked separately after merge.

## Model Used

OpenAI Codex, GPT-6 family, with reasoning, repository tools, test
execution, and browser inspection. The exact 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 (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run relevant tests locally and they pass (broader local
exceptions are recorded above)
- [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-11-05 01:23:53 -08:00
TonioandClaude Opus 5.5 9e9a628a57 feat(ui): turn Artifacts V1 on for every instance and hide its toggle (#19164)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - Artifacts show the output of agent work on the Artifacts page, in
the panel Artifacts tab, and in the task thread
> - #17228 added the Artifacts V1 presentation behind an experimental
setting that is off by default
> - The presentation is now ready for all users, so an opt-in toggle is
no longer necessary
> - A new default alone does not reach all instances, because each
experimental write persists every flag
> - This pull request removes the toggle and turns V1 on for every
instance
> - The benefit is one artifact presentation for all users, with an off
switch for hosting operators

## Linked Issues or Issue Description

Refs #17228
Refs #17263

**Is your feature request related to a problem? Please describe.**
Artifacts V1 shows only on instances where an admin turned on an
experimental setting. Other users see the previous cards.

**Describe the solution you would like**
Show Artifacts V1 on all instances. Remove the toggle from Experimental
settings.

**Describe alternatives you have considered**
A new default without a change to the hook. This does not work, because
many instances have a stored false that nobody chose, and no toggle
would remain to change it.

## What Changed

- Removed the Artifacts V1 card from Instance Settings, Experimental.
- Changed `enableArtifactsV1` to default on in the schema, the feature
catalog, and the settings service.
- Changed `resolveArtifactsV1Enabled` to ignore a stored false. It
honours false only when the value comes from managed config.
- Kept the flag and the previous cards, so a hosting operator can hold
V1 off.
- Kept the key in the Cloud staging list, so a managed false does not
hold V1 off on staging.
- Updated unit tests, the Artifacts V1 plan, and the directions-lab
Today reference.
- Moved the attachment and upload e2e specs and the runner download
helper to the V1 rows.
- Added V1 tests for a Markdown review: expansion, deep link, and open,
raw and download actions.

## Verification

- `cd ui && npx vitest run`: one test file failed before its fix. That
file tests the previous cards, and it now mocks the hook to off. I reran
it with the other changed UI tests, and they pass. I did not repeat the
full UI run after the fix.
- `npx playwright test --config tests/e2e/playwright.config.ts
tests/e2e/text-attachment-tabs.spec.ts
tests/e2e/artifact-uploads.spec.ts
tests/e2e/artifact-tab-arrival.spec.ts`: 10 tests pass on V1.
- `tests/e2e/cloud-auth.spec.ts` failed once in CI on a task heading. It
does not touch artifacts, and 10 local runs pass.
- `cd server && npx vitest run src/__tests__/instance-settings`: 183
tests pass.
- `cd packages/shared && npx vitest run src/feature-catalog.test.ts
src/validators/instance.test.ts`: 35 tests pass.
- `pnpm run check:token-gates` and the `ui` and `server` typechecks
pass. I did not run the full repository check.
- In the artifact directions lab, with no stored settings, the Today
right panel renders the V1 rows.
- I did not test this on a live instance. After merge, confirm on
staging that the Experimental page has no Artifacts V1 card and that all
three surfaces show V1.

## Risks

- All users see V1 after the next release, not only staging users. To
revert, revert this pull request.
- Users cannot turn V1 off. Only a hosting operator can, through managed
config, and not on Cloud staging.
- An instance with a managed `enableArtifactsV1: false` stays on the
previous cards. The cloud harness source has no reference to this key,
but I cannot read the live fleet configuration.
- V1 surfaces render before settings load. An operator-held instance can
briefly show V1 before the previous cards.
- Admins who use the API can still write the flag. The write has no
effect on unmanaged instances.

> 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 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
- [ ] 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: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-05 08:14:49 +00:00
DottaandPaperclip 48b57e0c94 test(evals): pin held scenario repairs and await Cloud return (#19188)
## Thinking Path

> - Paperclip helps people manage AI agents and their work.
> - Protected TestOps runs admit one immutable catalog source.
> - Three held scenario observers now have reviewed, locally qualified
repairs.
> - A separate Cloud recovery test started its heading wait before the
Cloud return.
> - This PR pins the qualified successor and corrects that test
boundary.
> - It changes no product behavior, model, execution budget, or private
evidence protocol.

## Linked Issues or Issue Description

Refs: #19155, #19093, #19095, #19112.

The next candidate retains the reviewed skill, company-secret, and
team-install observer repairs. It adds a narrow timeline v9 correction:
a recorded task identifier can be the subject of its actual
reassignment. The real timeline attempt remains failed; the diagnostic
correction is not a regrade or a new native pass. Earlier failed
attempts stay retained; a source pin and component tests do not
establish a native pass.

The Cloud recovery fixture failed both direct-task variants in the first
CI attempt of #19155. Its five-second heading check started before the
external Cloud roundtrip ended. The failure image already showed the
expected task shortly afterward. One unchanged local direct-task control
passed. The single authorized CI recovery also passed; this did not
establish a reliable boundary. This PR waits for one handoff and the
exact return URL before the original heading check.

## What Changed

- Pin source `5aef4bffa2b106f2066bf2485338798f04a702bd`, tree
`464be838a448c728d44e2d5593b9d7faea266663`.
- Update the two manifest target literals and expected pin test literal.
Bind the exact v9 descriptor snapshot and its one changed timeline
oracle leaf.
- Add the reviewed two-line Cloud return readiness witness. Keep the
original five-second heading assertion and existing overall test limit.
- Use descriptor
`744a566faaa90b8048fff526e0a30b7475b86c2de88d697783f8da9e02f70e20`. Keep
the launcher, all private helpers, 244 identities, requests, setup,
human/native counts, clocks, profile, model, retry policy, permissions,
and the 196/244 gate unchanged.

## Verification

- Current infrastructure worktree: **131 pin, admission, selection,
streaming, API, and reconciliation controls passed**.
- The fixture owner ran the exact patched Cloud spec: **all five real
auth cases passed** in 37.4s. A six-second Cloud hold passed the
unchanged heading check after return. Missing handoff and missing return
controls rejected. This PR's fresh master base is verified by
current-head CI, not credited from the earlier run.
- Fresh v9 source qualification: **268 focused timeline controls**, the
242-declaration gate, fresh server declarations, and full E2E typecheck
passed under local Node **26.4.0**. The preceding held-helper
qualification (239 Node controls and one offline Chromium route control)
remains evidence for the byte-identical unaffected helper closures. The
original browser sandbox failure is retained. Actual AWS Node and model
configuration remain unchanged.
- All 506 registered SDK input Git blobs and registry
`efa70621e9fb42aa185f7ee616a1a726aa3eccb367e67e28817cedf26ef2ade8` equal
the prior qualified source. No new SDK build or runtime refresh.
- All 75 private protocol files, production trees, YAML, lockfile,
launcher, identities, counts, clocks, and sourceFiles declarations equal
the prior source. Only the timeline descriptor oracle advances v8 to v9.
- Prior head `ce18f2bd52ed00ce750302f63aecc4167a3daff3` finished CI with
43 passed, one expected skip, four originating runner interruptions, and
a failed dependent verify aggregate. Two logs show runner shutdown
signals; two annotations show lost runner communication. No assertion
failure was observed. Those outcomes are retained; no unchanged recovery
was requested.
- Required fresh current-head CI, genuine review, thread clearance, and
Root's exact-diff acceptance are pending. No merge or new paid run is
authorized by this PR's publication.
- The earlier 3 PASS / 7 FAIL uniform attempt and all later original
outcomes remain unchanged. No new native pass or whole-catalog readiness
claim is made.

## Risks

The source remains a frozen candidate with unmerged catalog repairs. A
real measured run is still required. The readiness witness requires both
a real handoff and the exact task URL; it does not extend the heading
timeout, bypass auth, skip a case, or change production code. The active
measurement on the previous pin is not altered.

## Model Used

OpenAI GPT-6.1 (`gpt-6.1-sol`), with reasoning, code execution, and
repository tools. The host did not expose a 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 for and linked related public PRs above
- [x] I have linked public PRs and described the issue
- [x] I have not referenced internal or instance-local Paperclip issues
or links
- [x] My branch name describes the change
- [x] Relevant local pin tests passed; source and fixture qualification
scope is stated above
- [x] I have updated the expected pin test and the observed fixture
boundary
- [x] Owning source metadata and this description document the change
- [x] I have considered and documented the risks
- [ ] All current-head infrastructure CI gates are green
- [ ] Greptile is 5/5 with no unresolved material findings
- [x] I will address reviewer comments before requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-11-04 23:14:14 -06:00
DottaandPaperclip 088e959d7b test(evals): pin qualified chat scenario follow-up repairs (#19155)
## Thinking Path

> - Paperclip helps people manage AI agents and their work.
> - The protected TestOps workflow admits one fixed catalog source.
> - The retained uniform attempt exposed scenario observation and
grading gaps.
> - Focused source PRs now contain the reviewed repairs and local
controls.
> - A new immutable candidate combines those changes without a runtime
refresh.
> - This PR binds that qualified candidate for a future normal TestOps
measurement.

## Linked Issues or Issue Description

Refs: #19135, #19148, #19086, #19084, #19093, #19095, #19100, #19112.

The previous uniform attempt finished **3 PASS / 7 FAIL**. Its original
results and the separate failed control result4587 remain retained. The
source repairs correct visible multipart summary evidence, canonical
skill navigation, bound approval history, timeline attribution,
credential guidance, company configuration questions, and team-install
observation. Local qualification is component evidence. It does not
establish a new passing uniform-ten attempt.

## What Changed

- Pin immutable source `2ec214914cdaa11148ab2527d2203303f1485e2f`, tree
`f1dc0c47668e1ed1db1b4d1ead4d3d262edefc0a`.
- Update eleven existing oracle-version declarations in the manifest and
its frozen descriptor snapshot.
- Keep all 244 identities, 242 canonical declarations, requests, setup,
human/native counts, clocks, model, profile, retries, permissions, and
the 196/244 readiness gate.
- Preserve historical manifest provenance and prior failure records.
- Keep the launcher and all 75 private protocol files byte-identical to
the prior source. This PR changes no controller helper or workflow.

## Verification

- Existing focused pin, selection, admission, streaming, API, and
reconciliation tests: **131 passed**.
- Source owner qualification on the exact published candidate: **675
Node controls and 20 hire DOM controls passed**; all six affected
domains are included. The 242-declaration gate passed.
- Fresh server declarations and full E2E typecheck passed on the exact
candidate under local Node **26.4.0**. The temporary Node24/output tree
disappeared; the source owner restored exact frozen dependencies and
rebuilt only missing identical-source outputs under Root authorization.
Actual AWS Node and the model profile remain unchanged.
- Existing SDK guard: **506 registered inputs unchanged**, registry
`efa70621e9fb42aa185f7ee616a1a726aa3eccb367e67e28817cedf26ef2ade8`; no
SDK renewal or runtime build.
- Production server, packages, CLI, UI, YAML, and lock bytes equal the
prior source. Only eleven oracle-version descriptor leaves change.
Query, clock, count, and policy comparisons passed.
- Launcher SHA256 stays
`2b9a6953ee51f0ea0dbbd475b0491d9a6c39a1d6835eeaa912e0dbb7cf987724`.
Descriptor SHA256 is
`41038d984f045f593923da53ac036a9a6adefed5edcaedc609e55991e2fa03b7`.
- The next controlled acceptance selection is **only [53, 466, 564,
580]**. Their current source reviews and manual contract reviews are
clear. Cases 74, 578, and 610 have separate open observation findings
and remain held. This pin does not qualify the whole catalog or a
uniform-ten result.
- Root approved the final three-SHA pin delta. Exact current-head pin
review is 5/5 with no unresolved threads, and Windows passed. Normal CI
is terminal and blocked: 42 jobs passed, one expected selector skipped,
and six failed. Both direct-task Cloud recovery variants failed the
existing initial heading check. The native Runner, package Runner, and
server1 test leaves lost communication with their self-hosted runners,
as the GitHub annotations confirm. Their host cause is unproven; Spot is
not established. The dependent E2E and verify aggregates also failed.
Original CI results are retained. One same-head failed-jobs-only
recovery was accepted after a fresh terminal/head guard. The independent
unchanged direct-task control passed locally in 4.9s; the CI trace shows
its five-second heading wait began before the Cloud roundtrip, with the
expected page visible in the failure screenshot shortly afterward. This
supports a test-boundary hypothesis, not a fixed race or reliability
claim. Attempt 2 is pending; no second unchanged retry is authorized.
Merge remains blocked until all required gates pass. Individual source
PRs retain their separate CI and base-policy limitations; this PR does
not claim that all source PRs are merge-ready.
- No model call, TestOps submission, archive read, permission change,
core merge, or catalog merge occurred during this pin work.

## Risks

The candidate contains unmerged catalog changes. The protected source
pin keeps that boundary explicit. Component controls cannot replace a
real product attempt. Prior failures and unknown historical grades
remain unchanged. A future measurement must use the admitted source and
original bounds.

## Model Used

OpenAI GPT-6.1 (`gpt-6.1-sol`), with reasoning, code execution, and
repository tools. The host did not expose a 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 for and linked related public PRs above
- [x] I have linked related public PRs and described the issue
- [x] I have not referenced internal or instance-local Paperclip links
- [x] My branch name describes the change
- [x] I have run the relevant pin tests locally and they pass
- [x] I have updated the source pin regression and descriptor snapshot
- [x] I have updated the owning source provenance conditions
- [x] I have considered and documented the risks
- [ ] All Paperclip CI gates are green
- [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address reviewer comments before requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-11-04 22:32:45 -06:00
DottaandPaperclip a0250284e3 fix: preserve proposal revision turns and prove chat completion (#19105)
## Thinking Path

> - Paperclip manages work done by AI agents.
> - A completed delegated task must report its result to the originating
chat.
> - That report uses a real provider turn and must stay in cost
accounting.
> - Ordinary first-task proposals must also support the promised chat
acceptance path.
> - A revision response can reject an older proposal before it creates
the replacement.
> - The old rejection transition clears that active response's ownership
and blocks its next tool.
> - This change proves required completion work, guides ordinary
proposal policy and preserves the revision turn under the existing
locks.

## Linked Issues or Issue Description

No separate issue exists. The original failures remain in [the complete
Product
run](https://github.com/paperclipai/paperclip/actions/runs/41915965118).
The independent continuation repair is #19076. Related #12209 concerns
prior-run confirmation binding. This change fixes the ownership reset
during rejection, rather than changing binding authorization.

**What happened?**

The complete 20-case run finished with 13 passes and 7 failures. Three
delegated-chat cases counted one required `chat_task_completed` provider
turn as unexpected work. Two first-task agents chose optional human-only
cards, then correctly received 403 when they tried conversational
acceptance.

A [reviewed two-case candidate
run](https://github.com/paperclipai/paperclip/actions/runs/41931445311)
then used the changed first-task skill. Both models inherited the
ordinary resolver policy. Clarify/propose/accept passed all 12
predicates. Revise/accept failed after the new response rejected its
predecessor's proposal. The saved rejection was followed by
`paperclip_runner_tool_binding_not_authorized` on its next tools. The
final `native_session_lease_lost` label followed those binding failures;
this PR does not assume lease expiry caused them. Both cells cleaned up
and published their original grades.

**Expected behavior**

Keep the existing ordinary-turn bounds and account for one independently
proved completion notification. Inherit the normal resolver policy for
ordinary proposals that accept chat replies. When an active response
rejects an older proposal, save the rejection and retain that response's
current ownership so it can create the revised proposal. Keep human,
current-source and native completion-review rejection behavior and all
real approval restrictions.

**Steps to reproduce**

The original full run used `4740d251`. The two-case candidate used
trusted workflow `7d1e9b34` and target `74da56c4`. Run the focused
provider-free controls below. The dual-run API regression first fails
because rejection changes the issue to `todo` and clears the newer run's
execution and checkout fields.

## What Changed

- Prove one completion notification only for native Codex/local
`multi-repository`, `clarify-reuse` and `plan-handoff`. Keep the
ordinary bounds of 2, 3 and 4. Preserve actual totals of 3, 4 and 5, all
run IDs and all usage.
- Read those declared totals from the current catalog, which now
includes the completion reply. Check the total once and prove that
exactly one turn is the required notification. Do not add another turn
while waiting. The required-server controls use the actual catalog
tasks.
- Bind the notification to the same company, agent, conversation
generation, completed child, single delivery, accounted native run,
saved reply and rendered result link. Reject extra work, duplicate
deliveries, unknown events and mutations, including native work without
a Paperclip tool call.
- Collect workspace operations through the real run API for these three
proofs. Keep other collector calls unchanged. Keep the proof controls in
the existing required server test lane.
- Stop idle polling on a permanent completion-proof error. Continue to
retry transient observations within the original 240-second window.
- Guide ordinary chat-accepting first-task proposals to omit optional
`resolverPolicy` and inherit server/company defaults. Preserve explicit
and governed human-only restrictions. Do not lower or recreate saved
restricted cards.
- Under the existing locked issue and interaction rows, preserve the
active responding run when it rejects a different source run's proposal.
Change only the ordinary requeue predicate. Keep the saved rejection,
notifications, activity and existing Telemetry calls. Keep global
status, lease and tool-authority guards unchanged.
- Extend the existing native API controls with the actual dual-run
rejection/revision sequence and policy, provenance, human,
current-source and native completion-review countercontrols. No new
workflow or test framework is needed.

## Verification

- Current combined head is `a8567ded67e5ab811675390e9a5c5ed2194aee2f`,
integrated cleanly on `fb96537e28c4c7bfced4939909cb334392320868`. The
upstream completion-reply waiter is preserved. [Current required
CI](https://github.com/paperclipai/paperclip/actions/runs/41940780852)
passes. Actual test checkout `ff93c034d7bb40f3df7bc75cf51828fd07bb0d29`
merges this head into `9c6993f0aab7ebb22a26d78f5d227accb35a6ad1`.
- Fresh Greptile is 5/5 on exact head `a8567ded`, with no blocking
finding. All addressed review threads are resolved. The separate
automated reviewer emitted a paused-work response; that response is not
a review approval.
- Current required server CI actually passed all 11 native confirmation
API cases, 46 completion-proof controls and 13 onboarding asset checks.
Canonical typecheck, Build, the native package/server suites, all
browser and serialized shards, `ci / e2e` and `ci / verify` pass. No
current-head CI retry was needed.
- Local dual-run RED: the unmodified transition returned HTTP 200 and
saved rejection, then changed the issue to `todo` and cleared the newer
run's execution/checkout fields. Whole setup and check took 28.95
seconds; the case took 596 ms.
- Local treatment: all 11 real native/API cases pass. The same-session
response retains execution/checkout ownership, reads task context and
persists the recorded-shape revised confirmation. Its stored lease
receipt stays intact and one rejection activity is saved. Human-only
rejection, current-source rejection, human rejection with/without a
newer owner, Plan/Ask, foreign provenance, authentication and formal
approval controls pass.
- All 59 existing confirmation resolver controls pass in 16.62 seconds.
These cover cancellation, lost ownership, company/user scope, policy
changes, transactional rollback, concurrent retries and stale revisions.
- All 46 completion controls pass in 4.07 seconds. The two added clock
controls preserve the original idle deadline and prove immediate
permanent-proof failure plus transient observation retry. The existing
live collector-to-proof and native mutation negatives remain in this
required server file.
- The first current-catalog integration check failed 5 controls in 2.70
seconds. The old consumer added the already-declared reply again and
could accept an extra ordinary turn. The corrected consumer passes all
46 controls using the actual catalog. The existing full 20-case
catalog/reporting compatibility check also passes in 4.93 seconds. Case
identities, configured models and reporting match the declared 20.
- The API controls used one owned loopback PostgreSQL instance through
existing supported test hooks. It was stopped and removed. Earlier
missing-library/setup failures and one corrected current-source test
expectation remain retained; they are not counted as product failures or
passes.
- The unchanged first-task skill has SHA-256
`b789090996e7925676590c006418eb8b57f4514e646f6bca18ffd7b2b8e864de`. Both
candidate runtime copies matched it. The inherited policy was observed
in both models; one complete acceptance journey passed. This does not
qualify the new rejection repair.
- The three retained real completion streams pass the stronger local
proof, including native items, workspace observations and recorded DOM
links. Their original failed grades stay unchanged.
- Earlier related checks passed 153 hiring/non-execution controls and 13
asset checks. Their source is unchanged. Required discovery includes the
completion, API and asset files exactly once.
- Prior candidate `74da56c4` passed all required CI, including canonical
typecheck and build, in [CI run
41929148958](https://github.com/paperclipai/paperclip/actions/runs/41929148958).
Its fresh Greptile was 5/5. This is prior-head evidence.
- The intermediate `053150d9` head also received Greptile 5/5. Its [CI
run](https://github.com/paperclipai/paperclip/actions/runs/41940014165)
and review stay retained as superseded evidence. They do not qualify the
final catalog correction.
- A clean full local typecheck/build is not claimed because the reused
dependency cache has stale adapter-utils/Runner declarations. No source
or lock workaround was made. Fresh canonical CI must pass before merge.
- The original full-plan result remains 13/20. The separate two-case
probe remains 1/2. A fresh complete saved-plan run against delivered
source is required for acceptance. No case, assertion, model, budget,
timeout or failed grade is changed.

Focused commands:

```sh
# From server/; database URLs point only to an owned disposable local instance.
node ../node_modules/vitest/vitest.mjs run src/__tests__/chat-completion-proof.test.ts
PAPERCLIP_TEST_DATABASE_URL="$OWNED_TEST_DATABASE_URL" node ../node_modules/vitest/vitest.mjs run src/services/native-runtime/confirmation-comment-api.integration.test.ts
PAPERCLIP_TEST_POSTGRES_ADMIN_URL="$OWNED_TEST_DATABASE_URL" node ../node_modules/vitest/vitest.mjs run src/__tests__/confirmation-comment-resolution.test.ts
```

## Risks

- The ownership exception applies only to an agent acting as the current
execution run against a different non-null source run. Human, unowned
and current-source requeue behavior must stay intact. Native
completion-review handling remains separate.
- The completion proof fails closed on new native tools or event shapes.
A new shape needs review.
- A stored unchanged lease receipt is supporting local evidence. The
final real journey must prove full revision, execution and delivery.
- The new head still needs normal protected merge approval. The optional
queued Paperclip review is not a passing review. No causal repair of
unrelated CI intermittency is claimed.

## Model Used

OpenAI `gpt-6.1-sol` in Codex, with `max` reasoning effort. The runtime
reports a 475,000-token context window. Used reasoning, code editing,
shell tools and provider-free controls.

## 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-11-04 22:04:12 -06:00
DottaandPaperclip 7c66b6b1f6 test(onboarding): cover plan, hiring, and execution approval history (#19069)
## Thinking Path

> - Paperclip manages agent work and human decisions.
> - Onboarding can approve a plan, a hire, and an execution step in
separate turns.
> - Tests covered single approvals more closely than that full history.
> - The repaired gate must retain valid plan approval through later
decisions.
> - Every consumer must recognize the saved confirmation kind and
selected scope.
> - This change tests that contract and registers a complete
interview-to-execution journey.

## Linked Issues or Issue Description

Refs #19043, #17914, #18283.

The earlier tests admitted one accepted proposal at a time.
Decomposition fixtures used standard confirmations. The direct-task E2E
path forbids hiring. Those cases did not cover an accepted checkbox plan
followed by hiring and a separate untargeted execution approval.

## What Changed

- Add eight PostgreSQL contract cases for standard and checkbox plan
approvals. Native tools create the cards. An authenticated human accepts
them through HTTP. A later native run reads the approved revision and
actual selected scope.
- Exercise native task creation, generic REST creation, child REST
creation, and accepted-plan decomposition. Check the assigned child and
one creation audit event. Check durable replay on the three entry points
that support it. A pending execution confirmation still prevents
creation.
- Register the explicit-only `onboarding-approval-history` suite for
local native Codex and ACPX Claude. The browser chooses the interview,
selects only drafting in the saved plan, approves one writer hire, and
approves a separate Start drafting confirmation. The model must hire the
writer and use that writer's own child execution to save the welcome
document.
- Grade each human decision, the unchanged plan revision and selection,
approval timing, one assigned child and worker execution, the exact
writer-authored saved revision, no pending requests, and persistence
after reload. Calibrate the oracle against missing, forged, premature,
duplicate, and changed outcomes.
- Preserve synthetic option choices, document/run bindings, and saved
revision authorship in the existing public first-task evidence
projection. Keep private provider/account data excluded. Document the
workflow, evidence, billing, and cleanup bounds.
- Align the approval-history fixture with its completion oracle: the
onboarding parent must be Done. Test both native profiles against graded
completion evidence and reject a completed child whose parent remains In
review. Count parent heartbeats separately from the writer: accept one
to seven parent records while retaining the twelve-company-run cap and
the independent three-approval/one-writer oracle.
- Retain the existing 52-cell first-task suite. The new suite has one
attempt, seven expected work turns, a twelve-run maximum, a
fifteen-minute deadline, and the existing $5 company task budget. It is
excluded from `--all`.
- Update two stale cleanup assertions to include the existing
thirty-second deletion timeout.

## Verification

- Red control: temporarily restore the pre-fix admission module and run
the new checkbox/native history case. It fails with the expected
`First-task proposal requires human acceptance` error after plan,
hiring, and execution acceptance. Restore the repaired module after the
probe.
- The final post-rebase history matrix and existing onboarding safety
suite passed together: 74 tests, no skips.
- Final focused Runner E2E support passed: 413 Vitest tests and all 370
Node support checks. This covers catalog discovery, journey controls,
wrong-outcome calibration, public evidence, and existing first-task
behavior.
- Review controls: four authorship cases fail before the revision check.
A delayed browser-response control fails before the approval-time fix.
Both pass after repair. The final oracle requires the exact current
document revision, writer ID, native child run ID, matching body, and
readback after reload.
- Credential-free discovery lists both new native cells. No provider
call was made. `OPENAI_API_KEY` and `ANTHROPIC_API_KEY` are absent, so
the real provider journey remains unqualified.
- The earlier broad credential-free E2E support run reported 6,728
passing cases, three skipped cases, and nine failures in three unrelated
files. All nine reproduce with the changed E2E source restored to the
unchanged baseline: three expired overhead-fixture cases, one stale Pi
profile-version assertion, and five workflow security assertions. This
change does not alter those files, paid workflow policy, or provider
pins.
- Previous full workspace typecheck/build and [Linux
CI](https://github.com/paperclipai/paperclip/actions/runs/41921754638)
passed on `4f431f5aae99d072cc75027e90d7b847b4c342ca`, including the new
eight-case PostgreSQL file. Ponytail subsequently found a fixture/oracle
terminal-status mismatch. Both native-cell controls fail on that fixture
(`done` observed versus `in_review` expected), while the
parent-in-review negative control passes. A second comparison uses the
actual `matchesRunCount` predicate: graded evidence with six parent runs
and one writer run fails the old exact-seven-parent requirement. Both
fixes pass these controls, all 413 focused support tests, all 370 Node
checks, and the owning E2E project typecheck. [Fresh
CI](https://github.com/paperclipai/paperclip/actions/runs/41936699686)
passed on `91c980b110252da451b92eda597c168517de1276`: 48 successful jobs
and one expected skip. Greptile reviewed this head at 5/5 with no
unresolved findings. Ponytail's terminal-status finding is fixed and its
thread is resolved; its current-head re-review remains queued. Live
provider cells remain unqualified.

## Risks

The production API and approval gate are unchanged. The new paid journey
can expose model or product failures at an intermediate approval
boundary. It retains those failures and uses the existing diagnostics
and cleanup. Registration and deterministic tests do not establish a
live provider pass. The unrelated baseline support failures remain
explicit.

## Model Used

OpenAI GPT-6 through Codex, with reasoning, repository tools, and code
execution. The exact serving 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 (focused tests; unrelated
baseline failures are recorded above)
- [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-11-04 21:46:55 -06:00
Dotta 9c6993f0aa test(evals): pin corrected chat catalog and restore retained attachments (#19135)
## Thinking Path

> - Paperclip uses real Product E2E journeys to verify agent work.
> - The trusted TestOps controller must bind the reviewed source and
retain inspectable evidence.
> - The last uniform attempt exposed bounded observation and
evidence-retention defects. Its original outcomes remain unchanged.
> - The reviewed successor corrects those boundaries with the original
model, requests, counts, and clocks.
> - Its private framework report stores canonical attachments once. The
controller must validate and restore those references before normal
reporting.
> - This PR ports that reader support and pins the qualified source in
one infrastructure change. It does not merge the full catalog or its
core repair PRs.

## Linked Issues or Issue Description

Refs #19127, #19083, #19086, #19084, #19093, #19095, #19100, #19112.

**What happened?**

The last uniform attempt retained real failed outcomes. It also lost the
multipart-question original when evidence packaging exceeded its
unchanged physical byte allowance. Review found independent boundaries
in skill navigation, announcement observation, timeline attribution,
hire history, credential questions, and team visibility.

**Expected behavior**

The next run must execute the same ten requests against one reviewed
source. The controller must retain complete original evidence, validate
private attachment references, and report the actual outcome. Historical
failures and missing-original UNKNOWN grades must remain unchanged.

**Steps to reproduce**

Use the focused source controls linked above. The private framework
control uses a real failed Playwright test and a 140 MiB attachment.
Legacy duplicate carriers hit the old cap. Canonical original evidence
passes both seals and strict archive restoration. The controller
restores derived files and the existing TestOps exporter preserves the
failed result.

**Paperclip version/commit**

Qualified candidate: `155dd1bc1c4b85ae107f6a0cd429720caa281367`. The
controller port is based on current master. The full candidate catalog
stays on its own immutable branch.

**Deployment mode**

Existing AWS/TestOps job 100, plan 102, branch master. This PR does not
dispatch a run.

## What Changed

- Pin the published qualified source and its exact launcher and
descriptor fixtures.
- Preserve current manifest history. Update twelve declaration fields
across eleven cases: oracle versions and skill source-file provenance
only. Preserve all 244 identities, 242 canonical declarations, queries,
setup, human/native counts, clocks, profile, model, retry policy, and
global cap of 8.
- Port the exact source-owned compact framework helper and
private-transfer reader. Keep the three existing required
source/controller protocol helpers byte-identical.
- Validate both sealed inventories before restoring registered
attachments into the derived selected report tree. Verify exact bytes
and hashes. Preserve seals and unregistered evidence.
- Keep deep JSON, decoded-body, sensitive-key, path, and original/final
status checks. Plain-text bodies and registered plain files fail closed
if existing diagnostic redaction would change them; JSON remains under
structured inspection. Keep all existing physical byte, entry, ZIP,
time, privacy, and archive bounds.
- Preserve registered clean metadata and attachment bytes. Reject
content that needs privacy redaction instead of silently rewriting
immutable evidence.

## Verification

- 131 existing Node pin, selection, admission, adapter, reconciliation,
and security controls pass. The explicit new target assertion and drift
negatives remain active.
- 86 current-controller controls pass. They cover legacy reports,
privacy and static assets, canonical reference guards, both seals,
strict archive restoration, derived files, the actual report normalizer,
and the actual TestOps/Allure exporter. The original failed result stays
failed; screenshot and trace hashes resolve.
- Actual P1 controls reject both an unknown password in a decoded
plain-text body and an unknown command token in a registered text file.
Parent code fails both controls; corrected code passes. The composed
source passes 87 affected controls, fresh server declarations, and full
E2E typechecking. The old cfe head completed all 49 CI jobs without
adverse conclusions, but its review found this real privacy defect. That
CI result is not credited to this successor.
- The existing report-lock preflight returns already-reviewed at
`60f4c06bca47af3ab9d74281f2ef2e1ff559d566b862ba51c2fbe6c8e5bac35b`.
- The existing source SDK guard confirms 506 registered inputs,
unchanged registry
`efa70621e9fb42aa185f7ee616a1a726aa3eccb367e67e28817cedf26ef2ade8`, and
unchanged runtime pins. No registry renewal or SDK build was needed.
- Source launcher SHA-256:
`2b9a6953ee51f0ea0dbbd475b0491d9a6c39a1d6835eeaa912e0dbb7cf987724`.
Descriptor SHA-256:
`e026d5c000102f8d50397dc59055d187388304f91dbca9a6ccfbe747004cd16d`.
- No model call, evaluation dispatch, evidence download, reporting
retry, core merge, or permission change was performed. Full current-head
CI and review are pending. Separate source PR failures remain disclosed;
local controls do not establish universal source CI readiness.
- Seven cases have verified passing historical attempts. A uniform
passing ten-case run remains unverified. The old lost multipart-question
original remains UNKNOWN.

## Risks

This changes a trusted evidence reader and the source selected for
future measurements. The new helper is included in the controller import
closure. Compact references require matching originals; missing,
foreign, changed, unsafe, or redaction-required evidence fails closed.
Legacy reporter formats remain valid. A single canonical evidence set
can still exceed a bound. Current-head CI and material review must pass
before normal protected merge. Actual AWS/TestOps evidence remains
required afterward.

## Model Used

OpenAI `gpt-6.1-sol`, with reasoning, code editing, and tool use. The
host does not expose the 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
- [ ] 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
2026-11-04 18:20:22 -06:00
fb96537e28 test(ui): verify disconnect recovery through browser outages (#18832)
## Thinking Path

> - Paperclip lets people manage agent work through the board.
> - Deploys can interrupt reads and writes while people use the board.
> - Component tests cannot prove the browser keeps task content and
saved drafts through a reload.
> - The read and cache changes need a regression suite against the built
app.
> - This pull request drives those journeys through temporary API
failures.
> - CI discovers the new suite through the existing e2e shard plan.

## Linked Issues or Issue Description

**What happened?**
Outage recovery lacked one browser suite covering retained content,
write recovery, cached reloads, access errors and sign-out clearing
together.

**Expected behavior**
Keep loaded task content visible through a 20-second API outage. Show
one connection banner and its recovery state. Save comments once and
retain document edits. Restore approved reads after a reload. Keep real
error responses readable and clear query records on sign-out.

**Steps to reproduce**
Open a task or settings. Return 503 with `tenant_app_unavailable` from
browser API requests for 20 seconds. Type a comment, edit a document, or
reload. Restore the API and compare the visible result with the saved
server state. Repeat with real 403/404 statuses and sign-out.

Stacked on Refs #18825, which depends on Refs #18822. Related
durable-write foundation: Refs #17960.

## What Changed

- Add `disconnect-resilience.spec.ts` with ten browser cases for
comments, a queued comment across reload, document autosave, cached
settings/sidebar/task reads, legacy Inbox reloads, 403 and 404
responses, sign-out clearing, restored-draft conflict detection, and
first-socket outage control.
- Assert one connection banner, readable recovery, no transient error
boxes or raw codes, retained task text, one saved comment, and the saved
document after reload.
- Use the real local server and isolated embedded PostgreSQL. Intercept
browser API traffic for outages. Control the logout/session response for
the sign-out test. Create no agents or model runs.
- Register realtime interception before navigation. Track both ends of
current sockets, close them at outage start, and keep reconnects
unavailable through the HTTP outage deadline. Preserve normal close
forwarding and close tracked pairs during teardown. The regression
captures the first browser socket without waiting for history or open,
then checks that the outage closes it.
- Prepare complete server-derived experimental settings and workspace
preferences before the legacy Inbox navigation. Its route callbacks
serve per-test snapshots across reloads, avoiding reads from disposed
route.fetch responses.
- Document the direct test command. The existing CI e2e shards already
discover this file exactly once; no workflow or package script is added.

## Verification

- Current head `228c1b68d30` is merge-ready: all 54 check runs completed
(52 successful, one skipped, one neutral), the legacy Snyk status is
successful, and both required gates pass. The single failed-jobs debug
rerun in run `41752978283` passed on attempt 2, including Runner package
job `126328280650` and `verify` job `126332119116`. Greptile Apex
reviewed this exact head at 5/5 with zero unresolved threads; the branch
has no merge conflicts. The three-PR stack is awaiting operator merge
approval.
- Original attempt 1 of current-head CI run `41752978283` had 46
successful jobs, one skipped and two failed: Runner package tests and
the downstream `verify` gate. GitHub reports lost communication with the
Runner host; the test step was cancelled, its log returns HTTP 404, and
no Runner diagnostic artifact is available. The underlying test outcome
and disconnection cause are unknown. One failed-jobs retry with debug
logging was accepted after verifying the unchanged current head and
passed on attempt 2. No source change was made; earlier passing CI and
local tests do not certify this incomplete Runner result. Current-head
CI now passes; the earlier disconnection cause remains unknown.
- Preceding head `6531caccf62` reached merge-ready: all 54 check runs
completed (52 successful, one skipped, one neutral), the legacy Snyk
status was successful, and both required gates passed in run
`41749512329`. Greptile reviewed that exact head at 5/5 with zero
unresolved threads. Current head `228c1b68d30` carries later
account-preference and bulk-selection fixes and now has its own passing
current-head CI.
- All 23 built-UI outage/write/loading cases pass in 4.5 minutes on
exact current head `228c1b68d30`: ten outage, six durable-write and
seven loading cases. The run used bundled Chromium, a fresh
local-trusted server and isolated embedded PostgreSQL on macOS
arm64/Node 25.6.1. Owned temporary server and database stopped.
- Current integrated head `228c1b68d30` contains cache revision
`fe4f682c879` and read head `09d1db29dea`. The exact application source
passes all 1,198 focused tests across twenty-eight files, UI typecheck
and both guards. Seventeen new cases cover restored-account settings,
owned crown cleanup and pending bulk selections; sixteen fail the
previous source and one preserves denial compatibility. All three
browser specs pass standalone strict checking. All 23 current-head
browser cases pass in 4.5 minutes.
- Application revision `9c1a10f25d9` passed all 1,137 focused tests
across twenty-one files, UI typecheck and both guards. Exact preceding
application/spec head `4fec693ec94` passed all 23 built-UI
outage/write/loading cases in 4.6 minutes and standalone strict checking
of all three specs. It used bundled Chromium, fresh isolated PostgreSQL
and local-trusted auth on macOS arm64/Node 25.6.1. Owned test processes
stopped.
- Preceding integrated head `870aa709657`, containing cache
`cbb891dd37d`, passes all 23 built-UI outage/write/loading cases in 4.6
minutes: ten outage cases, six durable-write cases and seven loading
cases. It used bundled Chromium, the built UI, a fresh local-trusted
server and isolated embedded PostgreSQL on macOS arm64/Node 25.6.1.
Owned test processes stopped.
- The earlier head `763fe431b74` passes the affected legacy Inbox
outage/reload case (34.3 seconds; 50.8 seconds including startup) and
strict three-spec checking after the response-snapshot fix. The
preceding head `973a12d77f4` passed all 23 built-UI outage/write/loading
cases in 4.6 minutes: ten outage cases, six durable-write cases and
seven loading cases. Its first-socket regression fails the previous
helper because that socket stays open. The run used bundled Chromium,
the built UI, fresh isolated PostgreSQL and local-trusted auth on macOS
arm64/Node 25.6.1. That earlier isolated callback revision was verified
with its affected case; the later application/spec head `4fec693ec94`
also passes the full suite. Owned test servers and databases stopped.
- The current base gives known skills/app errors priority over sibling
loading. All 60 affected tests and both application UI typechecks
passed. Its twelve new regressions failed the preceding source. All 47
recovery-worker tests and seven related Runner fixture variants also
passed during the historical CI audit; those focused checks do not claim
a full current server/Runner suite.
- All 22 outage/write/loading cases passed in 4.7 minutes on preceding
integrated head `b7deaaee5da`, including direct cache revision
`97c0bc3966f`. The run used the built UI, bundled Chromium and a fresh
local-trusted server with isolated embedded PostgreSQL on macOS
arm64/Node 25.6.1. It covered all nine outage, six durable-write and
seven loading cases. The owned temporary server and database stopped.
- All 1,038 focused tests passed on that direct cache revision, with UI
typecheck and guards. Six regressions failed the previous source: online
retries could trigger a hidden-tab worker reload, and sign-out failed
without crypto.randomUUID. Both modes and stamp states now pass.
Standalone strict checking passes for all three browser specs.
- The restored cached-A/draft-B/server-C test asserts zero replay
PATCHes and retains the conflict. The queued-comment case holds fresh
session verification after general API recovery and asserts zero POSTs
until release. Denial, logout and cached-navigation cases require saved
records. Sign-out seeds several company records to exercise native
Storage key reordering. Healthy navigation waits for
conversation-history readiness.
- Earlier runs exposed real cached-header, storage cleanup and replay
defects in the base. Those failures and corrected fixture assumptions
remain in the discussion. A prior run passed 21/22 while real sockets
remained available during simulated HTTP failures. A diagnostic trace
established the contradiction. The first repair gated new sockets, but
review identified the first pre-existing socket still escaping. This
revision intercepts before navigation and closes existing pairs too. The
new regression fails the preceding helper, and all 23 current cases pass
without weaker assertions. Shared-memory exhaustion prevented two
earlier diagnostic startups; only unused segments from completed owned
test databases were removed.
- All six separate cross-organization link/upload variants passed on an
earlier integrated base. Standalone strict checking of that unrelated
spec reports five existing errors in its shared fixture; this PR does
not claim that check passes.
- CI on older head `53d979e384c` failed the legacy Inbox case with
`apiResponse.json: Response has been disposed` inside a route.fetch
callback. Its other 25 cases passed and one skipped. The seven other
browser shards succeeded; the aggregate only reports that child failure.
The new snapshot callbacks remove those fetched-response lifetimes.
Original CI evidence remains recorded in the discussion.
- Greptile Apex reviewed exact current head `228c1b68d30` at 5/5 with no
actionable findings and zero unresolved threads (summary updated
2026-11-04 at 01:26:14 UTC). The branch has no merge conflicts.
Current-head CI now passes; the earlier disconnection cause remains
unknown. Controlled local outages do not prove hosted authentication or
a real Cloud restart/deploy.

Commands run:

```sh
pnpm exec playwright test --config tests/e2e/playwright.config.ts tests/e2e/disconnect-resilience.spec.ts --grep 'a legacy Inbox reload retains' --reporter=list
pnpm exec playwright test --config tests/e2e/playwright.config.ts tests/e2e/disconnect-resilience.spec.ts tests/e2e/disconnect-write-recovery.spec.ts tests/e2e/task-loading-frame.spec.ts --reporter=list
pnpm exec tsc --ignoreConfig --noEmit --strict --target ES2022 --module NodeNext --moduleResolution NodeNext --skipLibCheck tests/e2e/disconnect-resilience.spec.ts tests/e2e/disconnect-write-recovery.spec.ts tests/e2e/task-loading-frame.spec.ts
```

## Risks

The suite adds about three minutes to one e2e shard and depends on
current accessible UI controls. It uses controlled outages and logout
responses. A passing local run must not be treated as real deployment
acceptance. There are no production behavior, schema, dependency, or API
changes in this PR.

## Model Used

OpenAI `gpt-6.1-sol` through Codex, with xhigh reasoning effort, tool
use, and code execution. The context window size is 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
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for related PRs and linked them above
- [x] I have described the issue following the bug report template
- [x] I have not referenced internal/instance-local Paperclip issues or
links
- [x] My branch name describes the change and contains no internal
ticket id
- [x] All 23 built-UI cases pass on current head `228c1b68d30`
- [x] All three browser specs pass standalone strict typechecking on the
current head
- [x] The current application source passes all 1,198 focused tests, UI
typecheck and both guards
- [x] I have added tests and updated relevant documentation
- [x] I have considered and documented 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: devinfoley <139239+devinfoley@users.noreply.github.com>
Co-authored-by: Paperclip <noreply@paperclip.ing>
Co-authored-by: Bender (Fable) <bender@agents.paperclip.ing>
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
2026-11-04 16:11:02 -08:00
DottaandClaude Opus 5.5 ac57b183f0 fix(evals): run campaign cells when TestOps selection is skipped (#19053)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - The Runner Full-Stack E2E workflow runs the paid Product E2E cells,
including the Product regression TestOps plan
> - #18983 added an optional `testops_selection` job and made `catalog`
depend on it
> - That job is skipped in every ordinary manual or scheduled campaign
> - GitHub's implicit `success()` also fails when an ancestor job was
skipped, so every job below `catalog` was skipped
> - Since #18983 merged, ordinary campaigns run no cells: the merge
reports every selected cell as "No result artifact was uploaded"
> - This pull request gives each job below `catalog` an explicit status
condition
> - The benefit is that ordinary, nightly and branch-targeted campaigns
run their cells again, and TestOps campaigns are unchanged

## Linked Issues or Issue Description

Refs #18983, #19000

**What happened?**
Run https://github.com/paperclipai/paperclip/actions/runs/41914430034
selected 20 Product regression cells with the `id` input. `catalog`
passed. `daytona_image`, `build_runner_artifacts`,
`build_remote_provider_pack` and every matrix job were skipped. The
merge failed with 20 "No result artifact was uploaded" rows.

**Expected behavior**
An ordinary manual campaign runs its selected cells when
`testops_selection` is skipped, as it did before #18983.

**Steps to reproduce**
Dispatch `runner-full-stack-e2e.yml` on `master` without `testops_case`
or `ALLURE_JOB_RUN_ID`. The scheduled daily campaign has the same path.

## What Changed

- `daytona_image`, `build_runner_artifacts`,
`build_remote_provider_pack`, `test`, `test_recurring` and
`test_manual_private` now start with `!cancelled()`.
- Each of those jobs now requires `needs.<job>.result == 'success'` for
each of its real dependencies. A failed or skipped build still skips the
cells, as before. The existing schedule, cadence and evidence-route
conditions are unchanged.
- A new regression test parses the workflow. It requires every job below
`testops_selection` to use a status function and to require each real
dependency result.

## Verification

- `node --test tests/runner-e2e/product-regression-testops.test.mjs`:
15/15 pass.
- Negative control: the new test fails against the current `master`
workflow.
- `daytona-image.test.ts`, `workflow-target.test.ts` and
`workflow-timeout.test.ts` pass. `workflow-security.test.ts` has 5
failures. The same 5 fail on unchanged `master` (they concern
`pr-trusted.yml` and `chat-catalog-testops-case.yml`).
- A workflow change takes effect only from `master`, because paid
campaigns run only from the default branch. After merge, dispatch an
ordinary `id=` campaign and confirm the cells run.

## Risks

- Low risk. The conditions keep the previous failure propagation: a job
runs only when each direct dependency succeeded and the run is not
cancelled.
- `catalog` success already implies `authorize` and `target_lock`
success, so those are not repeated.

## Model Used

- Claude Opus 5.5 (`claude-opus-5-5`), via Claude Code with tool use 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

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

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-04 17:41:18 -06:00
DottaandClaude Opus 5.5 23cd123ff8 fix(e2e): retain the closed cause code of a journey cleanup failure (#19079)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - The Product E2E journey harness runs the QA staging smoke plan and
reports each case to TestOps
> - Each case runs a journey, then releases its owned target resources
(cleanup)
> - Three recent cleanup failures had a passed journey and all checks
passed, but each result only says `target_cleanup_failed`
> - The adapter throws an error with a closed identifier code, and the
harness discards that code, so no one can find the failing cleanup step
> - This pull request keeps the identifier-shaped cause code as an extra
cleanup phase
> - The benefit is that the next cleanup failure is diagnosable from
TestOps without private runner files

## Linked Issues or Issue Description

**What happened?**
QA staging smoke cleanup failures show only `target_cleanup_failed`.
This occurred for `question-answer-resume` (launch 2390), and for
`company-access-isolation` and `create-skill-studio` (launch 2693). In
each case, the journey and all behavioral checks passed. The private
runner report is deleted with the runner, and the adapter error code is
not kept in the retained result. The cause is not known.

**Expected behavior**
A cleanup failure keeps a closed, identifier-shaped cause code (for
example `fixture_cleanup_not_confirmed`). The result never keeps the raw
error message.

**Steps to reproduce**
1. Run a Product E2E journey with a target session whose `release()`
throws an error that has a `code` property.
2. Read `normalized-results.json`.
3. Before this change, the cleanup phase only contains
`target_cleanup_failed`.

**Paperclip version or commit**
master at c99bcd89fe.

## What Changed

- `tests/runner-e2e/product-journeys/launch.ts`: when target release or
stop-only recovery fails, also record `cause.<code>` as a failed cleanup
phase. The code must match `^[A-Za-z][A-Za-z0-9_]{1,79}$`. Other values
are ignored. Timeouts keep their existing codes. `result.error` stays
`target_cleanup_failed`.
- `tests/runner-e2e/product-journeys/campaign.test.ts`: add a regression
test. It checks that an identifier code is kept, that the raw message is
not kept, and that a free-form code is not kept.

## Verification

- `npx vitest run --config tests/runner-e2e/vitest.config.ts
tests/runner-e2e/product-journeys`: 46 files, 1235 tests passed.
- Negative control: with the old `launch.ts`, the new test fails. With
the change, it passes.
- `tsc -p tests/runner-e2e/tsconfig.json` shows no errors in the changed
files. (This worktree has unbuilt workspace packages, so other unrelated
errors appear.)
- The Paperclip Cloud TestOps exporter already publishes phase codes
that match its closed code pattern as step messages. A `cause.*` code
matches that pattern.
- Not verified live: QA staging smoke uses a pinned harness revision
(`QA_SMOKE_HARNESS_SHA`). The new phase appears in TestOps only after
the pin moves to a revision that contains this change.

## Risks

- Low risk. The change only adds a phase entry when cleanup already
failed. Pass and fail grading does not change.
- An adapter could put private data into an error `code`. The strict
identifier pattern limits this to short identifier strings.
- Report consumers that count cleanup phases see one more failed cleanup
phase.

## Model Used

- Claude Opus 5.5 (`claude-opus-5-5`), Anthropic, via Claude Code with
tool use (shell, browser, code editing). Extended reasoning was used.

## 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

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

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-04 17:41:03 -06:00
DottaandClaude Opus 5.5 b1a71044af fix(evals): observe chat handoff replies and restarted task pages (#19073)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - The Product regression TestOps plan runs 20 Product E2E cells
through `runner-full-stack-e2e.yml`
> - The full 20-case TestOps launch on `master` 4740d251 passed 13 of 20
> - Four failures came from the eval's observation, not from the product
> - Three Agent Chat handoff cases raced the product's completed-handoff
reply turn, and the run-count contract treated that reply as an
unexpected run
> - One continuation case waited for `DOMContentLoaded` after a server
restart, which the dev server can leave pending while the page is
interactive
> - This pull request makes the eval observe those two behaviors
explicitly
> - The benefit is that these cases measure the product again, and the
handoff cases now also prove that the result returns to the chat

## Linked Issues or Issue Description

Refs #14408, #19053

**What happened?**
TestOps launch https://paperclip.testops.cloud/launch/2694 (GitHub run
https://github.com/paperclipai/paperclip/actions/runs/41915965118)
failed these cells:
- `agent-chat` `multi-repository`, `clarify-reuse`, `plan-handoff`:
"Declared total provider-run bounds". Each final run ledger has exactly
one extra run. That run is the source chat's `chat_task_completed` turn,
with `chatCompletionUpdates` naming the finished task.
- `continuation` `completed-action-resume`: `page.goto: Timeout 30000ms
exceeded` waiting for `domcontentloaded` right after the deliberate
server restart. The server log shows the page loaded and called the API
during that wait.

**Expected behavior**
A completed handoff returns to the source chat (#14408). The eval must
observe that reply, require it, and count it. After a restart, the eval
must wait for the rendered task, not for a browser load event.

**Steps to reproduce**
Run the cells listed above on `master` with the Product regression
TestOps lane.

## What Changed

- `chat-flow.ts`: after the delegated task is `done`, the handoff branch
waits for the source chat's completion-reply turn
(`chat_task_completed`, correlated by `chatCompletionUpdates[].id`). It
requires exactly one such turn, `succeeded`, and exactly one agent
comment created by that turn.
- `chat-cases.ts`: the declared run counts include that one reply turn:
`multi-repository` 2 → 3, `clarify-reuse` 3 → 4, `plan-handoff` 4 → 5.
The minimum and maximum stay equal, so a missing reply or an extra run
still fails.
- `catalog.test.ts`: the catalog run-count total changes from 385 to 397
for these three cases across their profiles.
- `continuation-flow.ts`: `open()` uses `waitUntil: "commit"` with a 60
s navigation limit, then requires the rendered task thread
(`waitForTaskChatRendered`). This matches the existing restart handling
in `chat-flow.ts`.

## Verification

- `npx vitest run --config tests/runner-e2e/vitest.config.ts
tests/runner-e2e/chat-flow.test.ts tests/runner-e2e/continuation.test.ts
tests/runner-e2e/catalog.test.ts
tests/runner-e2e/kimi-qualification.test.ts
tests/runner-e2e/non-execution-wake.test.ts
tests/runner-e2e/product-regression-testops-catalog.test.ts
tests/runner-e2e/lifecycle-live.test.ts`: all pass.
- `tsc -p tests/runner-e2e/tsconfig.json`: no errors in
`tests/runner-e2e`.
- The retained ledgers from run 41915965118 show the reply turn:
`multi-repository` 3 runs, `clarify-reuse` 4 runs, `plan-handoff` 5
runs, each with one `chat_task_completed` run on the chat issue.
- Live single-case TestOps runs against this branch: see the PR
comments.

## Risks

- Changed eval conditions: the three handoff cases now also require the
completion reply. A product regression that drops the reply now fails
these cases, as intended.
- The continuation navigation allowance changes from 30 s
(`domcontentloaded`) to 60 s (`commit`) plus a rendered-thread check.
That is an observation deadline, not a product latency requirement. The
rendered-thread check is stronger than the old load event.
- Three other plan failures are not changed here. They are product
failures: the agent creates `human_only` confirmations, and
`resolve-from-comment` then refuses to record the user's explicit text
approval (`interaction_human_only`).

## Model Used

- Claude Opus 5.5 (`claude-opus-5-5`), via Claude Code with tool use 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
- [ ] 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: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-04 17:40:58 -06:00
2ccc7d37ef feat(ui): retain approved reads across outage reloads (#18825)
## Thinking Path

> - Paperclip lets people manage agent work through the board.
> - The board already retains loaded reads during a temporary server
failure.
> - Reloading the page removes that in-memory data.
> - A deploy can then leave a returning user without the shell or recent
tasks.
> - This pull request saves an explicit, limited set of reads in the
browser.
> - Cached identity supports display while fresh session checks protect
writes.

## Linked Issues or Issue Description

**What happened?**
A reload during an API outage loses the board's loaded reads. An
automatic worker update can also reload a hidden tab while a write is
pending.

**Expected behavior**
Show the cached shell and recent tasks during a temporary outage. Limit
saved content by user, company, age and build. Clear it on sign-out.
Wait for a fresh session before sending account-bound writes. Defer
automatic reloads while work is pending.

**Steps to reproduce**
Open a task and settings while online. Return 503 from the API and
reload. Restore the API. Sign out and confirm that saved query records
are gone. Discover a worker update while offline or during an autosave
and confirm that it waits.

Stacked on Refs #18822. Related durable-write foundation: Refs #17960.
The outage browser suite follows in a separate test PR.

## What Changed

- Persist an exact read allowlist through TanStack Query dehydration and
hydration. Save shell preferences, company/sidebar data, agent/project
lists, plugin UI metadata, the first inbox page, and 20 recent tasks.
Task UUID and identifier reads share one recent-task slot.
- Namespace records by user and company. Retain eligible reads across
normal memory garbage collection, expire each read after 24 hours, and
discard them after a build change. Unstamped builds disable hydration
and persistence while retaining sign-out cleanup. Use the existing
instance-wide plugin contribution query in the user's root record.
- Exclude session credentials and bootstrap data, embedded plan
documents, comments, preview work products, provider credentials and
environment values, browser capabilities, pairing data, other queries,
and mutations. Restore only display identity from session data. Preserve
safe agent provider/model display fields and configuration object
shapes. Apply the projection on save and restore.
- Clear saved reads on sign-out, cross-tab account changes, and
definitive session denial. Keep revocation working on plain HTTP without
crypto.randomUUID. Use per-user revocation revisions to reject delayed
writes and stale records. Preserve a newer account. Remove every
UUID/identifier projection and nested inbox copy of a denied task.
- Detach shared GETs when the account changes or signs out. Load
complete, freshly authorized agents before opening bulk settings from a
display-only roster. Retire a pending bulk-editor result or error when
row, select-all or clear changes the selection, including a
clear/reselect of the same agent.
- Require a fresh server lookup before account-bound writes, pending
task creation, or mounted autosaves resume. This includes automatic task
read receipts, inbox archives, workspace preferences and primary-agent
choices, with optimistic archive changes gated too. Cancel the old write
scope when the verified user changes. Release completed archives through
account-independent cleanup without restoring old cached rows; an old
operation cannot clear a newer hide flag. Retry unconfirmed read
receipts after a fresh session succeeds for the original account, and
remember confirmed receipts across refreshes. Track pending reads per
task so opening another task sends its receipt immediately; revisiting
reuses an outstanding receipt and its original account scope.
- Defer a hidden-tab worker reload until connectivity, mutations,
durable sends, and autosaves are safe. Synchronously count each
unresolved operation across online rate-limit retries. Release a
cancelled target’s unused dirty token when an editor changes tasks; keep
stored drafts, admitted saves and queued retries. Cover autosave
debounce, newer edits, navigation and undo.

## Verification

- Current head `fe4f682c879` is merge-ready: all 54 check runs completed
(52 successful, one skipped, one neutral), the legacy Snyk status is
successful, and both `ci / verify` and `ci / e2e` pass in run
`41752927822`. Greptile Apex reviewed this exact head at 5/5 with zero
unresolved threads; the branch has no merge conflicts. All three PRs now
meet the merge-ready bar; the stack remains unmerged pending operator
approval.
- Greptile Apex reviewed exact current head `fe4f682c879` at 5/5 with no
actionable findings and zero unresolved threads (summary updated
2026-11-04 at 01:24:40 UTC). Both settings-account and pending-selection
findings are fixed, replied to and resolved. The branch has no merge
conflicts. Current-head CI now passes in run `41752927822`.
- Seventeen new cases cover settings restored from actual saved query
records, matching/changed/signed-out identities, denied verification,
late crown responses without overwriting newer reads, and bulk-selection
changes during successful/failed reads. Sixteen fail the preceding
source and one preserves denial compatibility. Both settings paths reuse
the existing account-bound mutation guard; its optional explicit
QueryClient supports the workspace hook’s existing detached-host mode.
Primary-agent optimistic updates begin only after verification and
cleanup checks ownership and the cache revision.
- Earlier CI run `41749456480` on prior head `2cf7516f18c` has one real
server test failure: the owned-runtime case in
`idle-completed-history.test.ts` could not reach its HTTP child on port
34757 within 10 seconds (99 refused probes). Its other 1,829 cases pass
and three skip; the only other unsuccessful job is the downstream
`verify` gate. The exact selected case passes locally, and the entire
75-case file passes in 72.19 seconds on the exact `2cf7516f18c` source
tree with isolated PostgreSQL and a real child process on macOS
arm64/Node 25.6.1. The Linux CI startup cause remains unknown; these
local results are not a fix or CI acceptance. One failed-jobs retry with
debug logging was accepted on that unchanged head, then superseded by
the later settings fixes. Current-head CI remains required; no source
change was made for this failure.
- Current cache head `fe4f682c879`, based on read head `09d1db29dea` and
master `683fa4725e9`, passes all 1,198 focused tests across twenty-eight
files, UI typecheck, token gates and the enforcing query-error guard.
Dependent browser head `228c1b68d30` contains this exact application
source and passes standalone strict checking of all three browser specs.
Current-head CI now passes in run `41752927822`.
- Three new navigation regressions fail the preceding application source
and pass with the fix. They open three cached tasks before any receipt
resolves, leave the page before success or failure, revisit an
outstanding read without duplicating it, and recover an older failed
receipt after a fresh session succeeds while a later task remains
pending.
- The fixture repair passes all seven deadline integration cases and the
complete server typecheck, including the server test layer. The old
assertion deterministically fails at 23:59:06.888 UTC; its
one-second-old run also fails the first-second-of-day probe. The
corrected fixture passes noon and both midnight probes. The permanent
three-case coverage uses seeded 2099 clocks.
- Nine new cases cover archive success/failure after sign-out and
another account takes over, both mounted and unmounted; cleanup
ownership when a newer archive uses the same task; session-check 429
exhaustion followed by matching, changed or signed-out identity; and a
failed read receipt followed by a new session read. They verify no
old-cache restoration, toast or navigation, retained newer hide flags,
no failed-check loop and no duplicate confirmed receipt. Seven fail the
previous implementation; two compatibility cases retain account-change
suppression. Initial test error-constructor and query-notification
timing assumptions were corrected before the passing checks.
- The inherited skills/app error-priority fix passes all 60 affected
tests and UI typecheck on both application branches. Its twelve new
regression cases fail the preceding read implementation. The
persisted-cache suite includes 48 cases.
- Six new regressions fail against the preceding application source and
pass with the fix. Actual worker-update and mutation-cache listeners
cannot reload a hidden tab between online 429 retries; the original
create key survives, and the update reloads once after a receipt. Real
self-hosted and Cloud sign-out work without crypto.randomUUID, with
stamped and unstamped builds. Saved reads are removed and account write
scopes are invalidated. An initial test-fixture type annotation error
was corrected before the passing typecheck.
- The 48 cache tests cover actual five-minute memory GC, the 20-task
bound across saved and live reads, original 24-hour expiry, denial
before session verification, unstamped cleanup, cross-tab revocation and
delayed flushes. Private GETs cannot cross account transitions. Bulk
edits require complete current agent data. Undo releases the update
blocker while preserving the Saved indicator.
- All 23 built-UI outage/write/loading cases pass in 4.5 minutes on
exact integrated head `228c1b68d30`, containing current cache revision
`fe4f682c879`: ten outage, six durable-write and seven loading cases.
The run uses bundled Chromium, the built UI, a fresh local-trusted
server and isolated embedded PostgreSQL on macOS arm64/Node 25.6.1. All
three specs pass standalone strict TypeScript checking. Owned temporary
server and database stopped.
- Earlier browser runs exposed and fixed cached-header, native Storage
cleanup and replay/session defects. A prior run passed 21/22 because
real WebSockets contradicted the simulated HTTP outage; the fixture now
closes existing socket pairs and holds new sockets through the same
outage deadline. An older CI run exposed a disposed response in the
Inbox route callback; pre-navigation snapshots remove that lifetime, and
the current full run includes that repair. Earlier failures and their
diagnosis remain in the discussion. The current full run passes. Broader
historical workspace failures remain documented in Refs #18822; this
does not claim a clean full workspace suite.
- Current-head CI passes on `fe4f682c879`. Controlled local outages do
not complete hosted authentication or a real Cloud restart/deploy
acceptance.

Commands for the current cache change and inherited read fix (the
current focused run also includes src/lib/inboxArchiveCache.test.ts and
src/pages/Inbox.test.ts):

```sh
pnpm --filter @paperclipai/ui exec vitest run src/pages/CompanySkills.test.tsx src/pages/apps/AppNotConnected.test.tsx
pnpm --filter @paperclipai/ui exec vitest run src/hooks/useDurableSubmit.test.tsx src/hooks/useDurableAutosave.test.tsx src/hooks/useSignOut.test.tsx src/lib/persisted-query-cache.test.ts src/lib/service-worker-updates.test.ts src/lib/service-worker-cache-policy.test.ts src/lib/pending-send.test.ts src/lib/issue-execution-policy.test.ts src/components/InlineEditor.test.tsx src/components/MarkdownEditor.test.tsx src/components/NewIssueDialog.test.tsx
pnpm --filter @paperclipai/ui exec vitest run src/components/agents/AgentBulkRoster.test.tsx src/components/agents/AgentBulkSettingsSheet.test.tsx src/hooks/useAccountBoundMutation.test.tsx src/pages/IssueDetail.test.tsx src/components/TaskChatThread.test.tsx src/components/TaskChatThread.task-creation-order.test.tsx src/api/client.test.ts src/api/agents.test.ts
pnpm --filter @paperclipai/ui exec vitest run src/hooks/useCoordinatorWorkspaceEnabled.test.tsx src/context/PrimaryAgentProvider.test.tsx src/components/CoordinatorWorkspaceSetting.test.tsx src/components/primary-agent/PrimaryAgentPresentation.test.tsx src/components/MobileBottomNav.coordinator.test.tsx src/components/CoordinatorSidebar.test.tsx src/pages/Issues.coordinator-routing.test.tsx
pnpm --filter @paperclipai/ui typecheck
pnpm check:token-gates
node scripts/check-query-error-rendering.mjs --enforce --summary
```

## Risks

This deliberately saves task content on the local browser for up to 24
hours. The allowlist excludes credentials and ephemeral capabilities.
Local storage can be disabled or full; persistence then fails without
blocking the app. Restored data can be stale and never grants server
access. A user or access change clears cached account reads and
invalidates pending writes. The browser outage suite and real hosted
deploy acceptance remain release requirements. There are no migrations
or new dependencies.

## Model Used

OpenAI `gpt-6.1-sol` through Codex, with xhigh reasoning effort, tool
use, and code execution. The context window size is 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
- [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 described the issue in-PR following the bug report template
- [x] I have not referenced internal/instance-local Paperclip issues or
links
- [x] My branch name describes the change and contains no internal
ticket id
- [x] The focused local tests for this change pass
- [x] I have added tests and updated relevant documentation
- [x] I have considered and documented 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: devinfoley <139239+devinfoley@users.noreply.github.com>
Co-authored-by: Paperclip <noreply@paperclip.ing>
Co-authored-by: Bender (Fable) <bender@agents.paperclip.ing>
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
2026-11-04 15:40:30 -08:00
Dotta 071b4dd5c3 fix(evals): preserve continuation restart and approval boundaries (#19076)
## Thinking Path

> - Paperclip manages work done by AI agents.
> - Product E2E journeys test that work through the UI and public APIs.
> - A continuation must retain completed work across a server restart.
> - A human-only plan request needs a recorded human decision.
> - The current fixtures retain an old Vite client and dismiss the plan
request before sending a comment.
> - This change uses the existing restart guard and approves the exact
current plan through its UI.

## Linked Issues or Issue Description

No separate issue exists. The failures are retained in [the original
complete Product
run](https://github.com/paperclipai/paperclip/actions/runs/41915965118).

**What happened?**

`completed-action-resume` reached its intended completed-child and
pending-question state. Its navigation then hit the original 30-second
limit after a server restart. The retained trace shows the old Vite
client polling during listener replacement. The existing chat restart
wrapper unloads that client, but the continuation callback did not use
it.

`revision-preserves-approval` saved the revised plan and final output.
Its exact current human-only confirmation remained pending. The fixture
had clicked Dismiss to enter a plain approval comment. A comment does
not resolve that card, so the final pending-work checks correctly
failed.

**Expected behavior**

Unload the old client before the existing restart. Use the real Confirm
action on the exact current plan revision. Require its saved human
acceptance before the normal continuation settles. Preserve all original
final checks and limits.

**Steps to reproduce**

Run those two existing continuation cases from source `4740d251`. The
original run preserves both failures. The focused controls below require
no provider credentials.

**Paperclip version or commit**

Original failure source: `4740d251b7032e714d33039ba66a56948238c38f`.

**Deployment mode**

Isolated local Product E2E servers in GitHub Actions.

## What Changed

- Route only the continuation restart callback through the existing
`restartChatServer` wrapper.
- Select the one pending confirmation for the exact saved plan revision.
Recheck it before the UI action.
- Click its scoped Confirm button. Require the same target, accepted
outcome, human resolver and timestamp in the saved receipt.
- Preserve the generic chat Dismiss behavior, ordinary reply cases,
original prompts, models, run bounds, grading and deadlines.
- Add focused unit and browser controls for the approval boundary.

## Verification

- The original full run retains these two failed grades. Cleanup passed
in both; that does not make either case pass.
- Focused continuation unit controls: 44 passed across four files. The
final new helper controls also passed 3/3.
- Three distinct controlled browser checks passed: the existing
old-client restart guard, the exact current human-only Confirm action,
and rejection of a changed revision without any approval POST.
- The browser controls use local HTTP fixtures. They do not prove a
fresh provider journey passed.
- All six files match the tested handoff hashes. `git diff --check`
passes.
- Local harness typecheck reached six diagnostics from stale cached
dependency declarations. The missing exports are in unchanged
adapter-utils and Runner code. No owned-file diagnostic remains. No
source or lockfile workaround was used. Fresh CI typecheck, build and
tests remain required.
- Fresh real Product acceptance has not run for this repair. The
original 20-case result remains 13 passed and 7 failed.


Current-head CI passes at `335683b741df5a3d0b76d035e105f0b44eda832d`:
required `ci / verify` and `ci / e2e` are green. [CI
run](https://github.com/paperclipai/paperclip/actions/runs/41922544434).
Greptile is 5/5 on this head. Ponytail is 4/5 with a ship
recommendation; its checkpoint warning was resolved with the dominating
awaited snapshot/push proof. No source changed after these checks. Real
changed-source journey acceptance remains pending.

## Risks

- The browser controls model the restart and approval boundaries; the
original real cases must still run after delivery.
- A changed or stale confirmation now fails before an approval. A
dismissed card or an agent-authored claim cannot satisfy human
acceptance.
- This fixture correction grants no new product permission and changes
no provider or scenario limit.

## Model Used

OpenAI `gpt-6.1-sol` in Codex, with `max` reasoning effort. The runtime
reports a 475,000-token context window. Used reasoning, code editing,
shell tools and provider-free browser controls.

## 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
#` 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
2026-11-04 17:39:10 -06:00
a3313f6944 fix(ui): complete read recovery and enforce query error rendering (#18822)
## Thinking Path

> - Paperclip lets people manage agent work through the board.
> - The board reads task, agent, settings, plugin, and run data from the
server.
> - A deploy can interrupt those reads after content is already visible.
> - Local error branches can replace that content with an error or show
raw codes.
> - This pull request moves the remaining reads to the shared recovery
behavior.
> - The query-error guard prevents new local error patterns from
returning.

## Linked Issues or Issue Description

**What happened?**
Loaded lists, settings, task panels, and manual reads could clear their
content or show errors during a server restart. Some reads also disabled
the shared retry policy.

**Expected behavior**
Keep loaded content during a temporary failure. Show the shared
connection banner. Retry reads after recovery. Replace content after a
real access denial or missing resource, with readable copy.

**Steps to reproduce**
Open a task, settings page, or run log. Return 503 with
`tenant_app_unavailable` from the API. Restore the API and check that
content refreshes. Repeat with 403 and 404 to check the failure state.

Related merged work: Refs #15754, Refs #15772, Refs #17960. This change
covers remaining reads and enforcement. Browser persistence and the
outage browser suite follow separately.

## What Changed

- Repair an existing PostgreSQL deadline fixture at UTC boundaries. A
daily cap defers a heartbeat until both its original interval and the
next UTC day allow it. Keep the counted run in its seeded day and cover
noon, just before midnight and the first second after midnight with
explicit clocks and real PostgreSQL. Production scheduling is unchanged.

- Integrate the saved list, settings, shell, task, and manual-read
recovery changes against current master. Preserve the current task,
Inbox, and run-log structure.
- Add `useResilientFetch` for component-local reads. Preserve loaded
data, cancel stale requests, and retry through the shared connectivity
policy. Keep browser and pairing capabilities in memory.
- Retain run log chunks across stream changes and catch up after
recovery without duplicate chunks or stalled requests.
- Keep genuine authorization and missing-resource failures visible.
Translate known single-word codes such as `forbidden`. Show known skills
and disconnected-app failures before sibling loading states. Keep Retry
bound to its failed request.
- Make the query-error guard enforce by default and run it in the CI
policy job. Document the narrow exceptions and the read recovery
contract.
- Invalidate pending OAuth discovery when the operator leaves setup or
its context changes. Keep reserved-popup cleanup bound to the current
attempt.

## Verification

- Current read head `09d1db29dea` is merge-ready: all 59 check runs are
completed (54 successful, three skipped, two neutral), the legacy Snyk
status is successful, and both required `ci / verify` and `ci / e2e`
gates pass. Greptile Apex reviewed this exact head at 5/5 with no
unresolved threads; the branch has no merge conflicts. The current CI
run is `41748339602`.
- Current read head `09d1db29dea` includes master `683fa4725e9`. The
latest change touches only the existing server deadline test fixture.
Application source remains the previously verified `86376fa751e`
revision: all 60 affected skills/disconnected-app tests and both
application UI typechecks passed, along with token gates and the
enforcing query-error guard. Those UI suites were not repeated for this
test-only repair.
- The fixture repair passes all seven deadline integration cases and the
complete server typecheck, including the server test layer. The old
assertion deterministically fails at 23:59:06.888 UTC; its
one-second-old run also fails the first-second-of-day probe. The
corrected fixture passes noon and both midnight probes. The permanent
three-case coverage uses seeded 2099 clocks.
- Twelve new regressions fail against the previous implementation. Both
skills variants and disconnected-app pages show either request's 403 or
429 while the sibling pauses or remains fetching. Permission failures
stay visible. Retry stays usable for its failed request and recovers
independently. An initial test-fixture query-key typo was corrected
before the passing run. The finding is replied to and resolved. Greptile
reviewed prior application revision `86376fa751e` at 5/5 with no new
actionable findings or unresolved threads. The current test-only head
has now received its own Apex 5/5 review with no unresolved threads, and
its CI is successful as recorded above.
- The preceding OAuth fix passed all 237 setup tests on both application
branches. Its ten regressions prove that Back, Cancel, unmount, or
context changes retire initial discovery without creating a connection,
caching old identities, navigating an abandoned popup, or closing a
newer attempt.
- Earlier master integration `e992f770339` passed all 309 tests across
eight affected Slack, recovery, retry, submission and task files, plus
UI typecheck, token gates, enforcing query-error scan and seven guard
tests. The integration preserves Slack workspace reconnect and shared
recovery, readable execution errors, source-inspection company scoping,
and current submission behavior. Newly inherited retained-file recovery
controls keep cached data through transient failures and hide it after
definitive denial.
- The preceding cache head `97c0bc3966f` passed 1,038 focused
cache/write/editor/account/task/API tests. All 22 built-UI
outage/write/loading cases passed in 4.7 minutes on exact browser head
`b7deaaee5da`, with strict checking of all three specs. The latest
skills/app rendering fix is covered by its affected component suites;
those broader cases were not repeated for this separate read path.
- Historical broader UI, CLI and build results and unresolved aggregate
server/DB/adapter failures remain in the PR discussion. Interrupted CI
runs were audited and recorded separately; they are not counted as
passes. Controlled local outages do not prove hosted authentication or a
real Cloud restart/deploy. Real hosted acceptance remains required after
merge and deployment.

Commands for the latest fix:

```sh
pnpm --filter @paperclipai/ui exec vitest run src/pages/CompanySkills.test.tsx src/pages/apps/AppNotConnected.test.tsx
pnpm --filter @paperclipai/ui typecheck
pnpm check:token-gates
node scripts/check-query-error-rendering.mjs --enforce --summary
```

## Risks

This migration touches many read surfaces. The main risks are initial
loading, request cancellation, retained authorization state, and run-log
paging. The tests cover those states. There are no server, schema,
dependency, or API contract changes. The follow-up browser suite and
hosted deploy acceptance are required before release acceptance.

Recovered commits retain their original authors. If squash-merging,
preserve `Co-Authored-By: Bender (Fable) <bender@agents.paperclip.ing>`
and the Paperclip trailer.

## Model Used

OpenAI `gpt-6.1-sol` through Codex, with xhigh reasoning effort, tool
use, and code execution. The context window size is not exposed. Saved
source commits keep their original authorship.

## 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 described the issue in-PR following the bug report template
- [x] I have not referenced internal/instance-local Paperclip issues or
links
- [x] My branch name describes the change and contains no internal
ticket id
- [x] The affected local tests pass; broader limitations are recorded
above
- [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 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: devinfoley <139239+devinfoley@users.noreply.github.com>
Co-authored-by: Paperclip <noreply@paperclip.ing>
Co-authored-by: Bender (Fable) <bender@agents.paperclip.ing>
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
2026-11-04 14:07:18 -08:00
DottaandPaperclip 52b4b3ccd7 test(evals): pin native credential delivery and worker receipt fixes (#19042)
## Thinking Path

> - Paperclip must deliver agent work through ordinary human controls.
> - The latest three-case run retained three failed originals.
> - The personal value was saved, but the native OpenCode child did not
receive the configured task environment.
> - A worker proof also relied on legacy process identity fields outside
that environment contract.
> - Timeline and credential checks had independent review defects that
could reject truthful outcomes or miss unsafe instructions.
> - This PR pins the reviewed fixes together and keeps all prior grades
unchanged.
> - A new AWS measurement must still prove the real outcome.

## Linked Issues or Issue Description

Refs #18963, #18967, #18968, #18971, #18972, #18977, #19027, #19031.
Follows merged #18995. This is the next infrastructure pin, not another
core implementation PR.

The latest launch 2657 retained FAILED originals for timeline,
approved-tool replay and personal secret. The personal journey reached
secure UI save and a worker wake, but the worker reported no credential
and made no endpoint call. These are failed attempts, not new passes.
Six of the selected ten cases have independent passes across prior
attempts. The uniform final ten and the full catalog remain unqualified.
No old result was regraded.

## What Changed

- Pin immutable candidate `c6cc59282a45ed3c79880a220f7f60aa3ac1d6a4` on
`codex/chat-credential-destination-contract-candidate-20261104`.
- Retain the frozen candidate baseline. Add the accepted failed-action
completion feedback hint, canonical configured environment delivery to
OpenCode, actual native worker output receipt checks, timeline
attribution controls, and credential clause safety checks. The feedback
change leaves the existing acceptance gate in place.
- Declare exactly seven oracle-version changes: timeline v5 to v6;
personal v5 to v6; company v4 to v5; secure API key, least-scope
delivery, secret proposal and vault reference each external v1 to v2.
The four external cases have explicit overrides; the shared default is
unchanged.
- Sync the manifest rows, explicit changed-field records, descriptor
snapshot and expected target. Preserve all 244 identities, original
queries, human/native counts, clocks, model, profile, launcher bytes,
privacy limits and the existing 196/244 qualification gate.
- Include the reviewed retry cancellation readiness fixture repair from
`815d47e4b5d7756367d2c5e2da656b640273eac2` in this infrastructure PR
only. It awaits the first scheduled batch before polling its state. Its
production behavior and assertions are unchanged. This test repair is
absent from the model candidate.
- Keep the core PRs, including #19027 and #19031, unmerged. A normal
merge of this pin does not merge those PRs.

## Verification

- Pin-local checks: all 189 existing manifest, TestOps API, adapter,
reconciliation and streaming controls passed. The reviewed 815 fixture
repair passed its owning real-PG control (one selected test). A
temporary delayed-first-batch control failed with the old observer and
passed with the new observer. Batch limits, assertions, drain wait and
overall budget are unchanged. The original CI cause remains unknown.
- Final candidate: 89 credential/receipt consumer controls passed. The
exact Runner TypeScript build, 68 driver controls and one owning
failed-action PG control passed before the later helper-only changes.
Their runtime inputs remain byte-identical; those results are reused
explicitly, not claimed as new executions on every source commit.
- Real pinned OpenCode 1.18.34 executed a canned local-provider bash
call. Synthetic `PUBLISHING_API_KEY` reached its child in a 2.89-second
passing control with zero paid provider calls. This proves
server-to-bash inheritance; driver spawn controls cover the preceding
projection boundary. Actual AWS secure-entry, worker delivery and
privacy acceptance remain pending.
- **The latest local candidate declaration loader is NOT GREEN.** It
exceeded its unchanged 30-second limit in both a combined run and an
isolated run. Five other declaration/contract checks passed. Both
failures remain recorded. No timeout was widened and no further retry
occurred. Descriptor and definition modules match the earlier passing
5aa source; only the transitive credential helper changed. Prior
242-declaration evidence supports unchanged definitions only, not a
claim that these failed executions passed.
- The snapshot matches the candidate and exactly seven oracle-version
leaves differ from source 249. All 244 identities, queries, run/human
counts, clocks, model, profile, launcher and privacy limits remain
unchanged. The SDK guard reports 506 unchanged inputs, unchanged runtime
pins and registry
`efa70621e9fb42aa185f7ee616a1a726aa3eccb367e67e28817cedf26ef2ade8`. The
driver is outside those SDK roots. No SDK renewal occurred.
Reporting-lock and whitespace checks passed.
- Genuine exact-head reviews: source 19e3 is 5/5 with no unresolved
threads; current pin 988 is 5/5 with no unresolved threads. The prior
pin 4/5 and resolved P1 remain historical. Current exact-head normal CI
41917215227 completed successfully: 48 successful jobs and one selector
skip, including final verify job 126888275415. Windows 41917215440
succeeded. The full PR rollup is 56 successes and three intentional
skips, with no pending or failed checks. Older green heads do not
qualify this head. Paperclip has only an earlier-head 5/5 assessment,
which is stale for this head and receives no current assessment credit.
- Six of ten cases have independent passes across prior attempts. Launch
2657 retains three FAILED originals; no grade was changed. The next
measurement is the exact uniform ten, cap eight and zero automatic
retries. No uniform-ten or full-catalog acceptance is claimed.
- The local-tests checkbox below covers only the 189 pin controls and
owning fixture control. It does not claim all candidate or repository
tests are green. Full local repository checks were not repeated for this
infrastructure diff. Core PRs remain unmerged. No model call, eval
dispatch, private archive read, fleet change or merge occurred for this
update.

## Risks

Environment delivery crosses a real provider process boundary, so secret
isolation remains part of the next actual AWS acceptance. A worker
receipt must match an actual successful native run and key-authenticated
endpoint call; a copied boolean does not qualify. Oracle safety and
attribution changes can alter acceptance, so balanced negatives remain
required. No current uniform-ten pass is claimed. Normal CI and genuine
exact-head review must finish before protected infrastructure merge.
Root owns the next TestOps Submit, with the original model, limits, zero
automatic retries and maximum eight concurrent case chains.

## Model Used

OpenAI `gpt-6.1-sol` through Codex. Capabilities used: source analysis,
mechanical integration, local code execution and PR preparation. The
host does not expose the context-window limit. The evaluated model
remains OpenCode/OpenRouter `deepseek/deepseek-v4.1-flash-1017`.

## 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-11-04 15:52:12 -06:00
DottaandPaperclip c99bcd89fe fix: preserve Product TestOps evidence and CI readiness (#19000)
## Thinking Path

> - Paperclip manages agent work through governed product workflows.
> - Product E2E tests check those workflows through the app and Runner.
> - A trusted reporter sends retained results to TestOps.
> - Free-form metadata and a short upload observer can lose safe, valid
evidence.
> - UUID navigation can also discard task metadata before the canonical
query returns.
> - Hermetic CI files start child processes that need CPU capacity
within their readiness limits.
> - This change closes the reporting contract, retains authenticated
core aliases, and reserves CI CPU capacity.
> - Original case identities, conditions, assertions, verdicts and
deadlines remain intact.

## Linked Issues or Issue Description

Refs #18983. This addresses its late [metadata disclosure
finding](https://github.com/paperclipai/paperclip/pull/18983#discussion_r4470789114)
and [upload readiness
finding](https://github.com/paperclipai/paperclip/pull/18983#discussion_r4470790366).

**What happened?**

The reporter accepted model IDs and matcher names through syntax
filters. A secret-shaped string could pass those filters. First-task
results also use their top-level model field for an observed alias.
Treating it as configured metadata can reject valid retained evidence.
The upload observer stopped after 22 seconds of waits.

[Required CI on the earlier
head](https://github.com/paperclipai/paperclip/actions/runs/41886885193)
also found two real browser title failures and five native package
readiness failures. A deterministic control reproduced metadata loss
during UUID-to-identifier navigation. A separate fixed-resource control
reproduced startup deadline failures with four concurrent hermetic
fixtures, while one and two fixtures passed.

**Expected behavior**

Reject unknown transmitted metadata before creating upload files.
Preserve every original matcher verdict and attempt receipt. Observe
server processing without rerunning the product. Keep authenticated task
metadata visible through canonical navigation. Reserve capacity for
hermetic child processes without changing the original readiness
deadlines.

**Steps to reproduce**

Use a secret-shaped model ID or cleanup state in retained evidence,
return an observed first-task model alias, or let upload processing
settle after 40 seconds of virtual time. Hold the canonical core query
pending after an authenticated UUID read. For the CPU control, run the
same providerless startup/recovery fixture alone, four times
concurrently, and twice concurrently under a fixed 4-vCPU quota and its
original 8-second readiness limit.

## What Changed

- Bind configured model receipts to each exact declared case model. Four
first-task cases use captured agent configuration; their observed
aliases and fallback text remain digest-only. A missing capture stays
null / Not recorded. The other 16 cells use their configured profile
model. Reject wrong or unknown configuration before any upload file
exists.
- Keep the existing model distribution: 18 Codex cells on `gpt-5.6-sol`,
configured-repository case 9 on its existing `gpt-6.1-sol` override, and
task-workspaces case 54 on `openrouter/deepseek/deepseek-v4-flash-0731`.
The repository override exists at the [original canary
source](https://github.com/paperclipai/paperclip/blob/86814c6550f52e99ede150a883bdc773cbb540e3/tests/runner-e2e/catalog.ts#L1148).
No model configuration changes.
- Allow only existing Matcher kinds, closed failure classes, and cleanup
states `passed`, `failed`, or `not_started`. Publish each matcher's
kind, ordinal, original boolean verdict and SHA256 path receipt. Full
conditions remain in the linked original workflow artifact; raw dynamic
path bytes do not enter TestOps.
- Observe the same upload for at most 55 seconds of poll waits. Product
scenarios, provider retries and scenario deadlines do not change.
- Retain task core data under only the authenticated response's own UUID
and identifier core keys. Preserve existing canonical data. Keep
arbitrary references and full-detail keys empty until their own reads.
- Retain a first-failure trace for the existing Cloud recovery test.
Keep its assertions, timeout, retries, mock data and artifact policy
unchanged. This adds diagnosis evidence; it does not claim to fix that
separate Cloud title timeout.
- Reserve half the available CPUs for Runner package CI workers, with
the existing upper cap of four. A 4-vCPU host uses two workers; an
8-vCPU host still uses four. Local defaults and test selection do not
change.

## Verification

- Reporting controls first reproduced the two original gaps. All 14 Node
contract tests now pass. Unknown configuration creates neither a result
directory nor an export summary. A model valid for a different selected
case is also rejected. Original functional failures and earlier
accounting receipts survive.
- The catalog compatibility test passes for all 20 selected cells, exact
model tuples, real pure grader outputs and actual
`projectFirstTaskResult` shapes. It covers observed aliases, fallback
text, absent evidence and wrong or secret-shaped configured metadata.
These are contract controls, not live journey passes.
- Virtual-clock controls accept a correct result that settles at 40
seconds and reject a persistently wrong verdict after 55 seconds. They
make no product or provider calls.
- Two new core-cache controls failed before repair. The query/cache
suites now pass all 8 tests. They hold canonical refresh pending and
verify title/company retention, newer canonical data, full-detail
enrichment and unrelated keys. UI typecheck and token gates pass.
- The unchanged exact UUID cross-company link/upload browser test passed
once after repair: 5.8-second scenario, 32.0-second complete command.
The unchanged exact Cloud task-entry diagnostic passed once: 5.4-second
scenario, 23.3-second complete command. Its original canonical-only
timeout remains unexplained. All five Cloud tests still collect after
the trace setting.
- The providerless Linux control used the retained Runner and compiled
controller from source `3a2249dd`, with a fixed 4-vCPU quota and
original 8-second readiness limit. Solo passed 1/1; four concurrent
fixtures failed 4/4; two concurrent fixtures passed 2/2. At each
failure, Rust had accepted command 2 but startup was still pending;
checkpoint and published status agreed, one connection was
authenticated, no replay backlog existed, and the sidecar had not
launched. Passing controls preserved the expected startup failure
through controller replacement. No network or credentials were
available.
- That control uses Linux amd64 emulation and Node 24.21; hosted CI used
Node 24.22.1. It supports the worker-cap change, but does not prove that
the original `m5n.xlarge` host caused every CI failure. The original red
attempts remain recorded.
- Actual config-load controls verify 1 CPU → 1 worker, 2 → 1, 4 → 2, 8 →
4 and 16 → 4, with no local, timeout or retry override. The isolated
policy change preserves the same 297 test-file inventory; integration of
current master `89703c3ff7` retains all 298 current native package
files. The original PR package/native command plans remain unchanged.
- Final head `877e28da32f2d2f0d12906c89aff085e2c6ea943` passes both
required checks, `ci / verify` and `ci / e2e`, in [CI run 41897677652,
attempt
2](https://github.com/paperclipai/paperclip/actions/runs/41897677652/attempts/2).
The native package passes 4,950 tests with 10 existing skips. All eight
browser shards pass; the Cloud shard passes all 41 tests, including all
four unchanged recovery cases.
- Attempt 1 preserved 46 successful jobs but its one-file heartbeat
recovery shard hit the original 20-minute job limit without a named
assertion or completion verdict. Its cause remains unidentified. One
explicitly bounded debug replay retained those 46 successes and ran only
that leaf and its dependent rollup. The unchanged file passed all 412
tests (346.91-second file, 371.34-second Vitest command, 7m11s job).
Source, cases and deadlines did not change. This establishes
intermittency, not a causal repair. The original timeout and debug pass
both remain recorded.
- Fresh [Greptile
5/5](https://github.com/paperclipai/paperclip/pull/19000#issuecomment-6637604918)
and [Ponytail
5/5](https://github.com/paperclipai/paperclip/pull/19000#issuecomment-6637489454)
reviews name exact head `877e28`. The single review thread is resolved.
Live TestOps bootstrap and complete 20-case acceptance remain held until
reviewed delivery. CI and focused controls do not count as product plan
passes.

## Risks

- Future model or Matcher kind changes require a reviewed
reporting-contract update.
- TestOps shows a closed Matcher kind and ordinal. The path digest binds
the original condition in retained evidence.
- Core alias data retains the existing authenticated query-client and
server company boundaries. It never becomes full-detail evidence.
- Fewer CI workers can increase one job's duration. The full suite must
verify the final policy. The paid evaluation matrix and its parallelism
do not change.
- The original Cloud title timeout and the first-attempt heartbeat CI
hang do not have proven causes. Current unchanged assertions pass, but
this does not establish repeatability. The Cloud test now retains its
first-failure trace. A successful upload or focused control alone cannot
establish a complete product pass.

## Model Used

OpenAI Codex with reasoning, tool use and code execution. The host does
not expose the exact model ID or context window 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
#` 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-11-04 14:41:28 -06:00
DottaandPaperclip 513c03cb3e fix(e2e): configure supported rolling agents with warm policy (#18994)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Rolling tests must exercise the lifecycle they claim to cover.
> - The warm lane selected a warm environment.
> - Its profiles also set an explicit per-turn agent policy, which took
precedence.
> - The test then waited for a live workspace that per-turn cleanup had
correctly retired.
> - This pull request sets warm agent policy for providers admitted by
the production warm capability.
> - The matrix now checks effective lifecycle and preserves per-turn
coverage for every qualified native profile.

## Linked Issues or Issue Description

Builds on merged #18982 for the source controller dependency link. This
PR now targets master.

**What happened?**

The warm rolling fixture built a Codex agent with `lifecycleMode:
per_turn` and an environment with `runnerLifecycleMode: warm`. The
explicit agent policy won. The initial task completed, its disposable
workspace retired, and the fixture waited for a live file before it
reached deployment.

**Expected behavior**

Warm rolling, legacy migration, remote-file and controller-outage cells
must create actual warm agents. Only providers supported by the
production managed warm-session capability belong in that lane. All
qualified native profiles retain per-turn coverage.

**Steps to reproduce**

Build the old warm Codex cell's agent and environment and compare their
lifecycle policies. The new effective-policy regression fails on the old
catalog and passes on this branch. No duplicate exact-scope warm-fixture
PR was found.

## What Changed

- Share the production managed warm capability filter and explicit warm
agent policy across rolling, legacy migration, remote-file and
controller-outage suites.
- Check effective agent and environment policies and update matrix
coverage/counts.
- Read completed warm turns from the exact saved snapshot while
independently requiring the retained, bound workspace location.
- Keep both rolling lanes separate from the outage simulation and
exercise their assembled supervisor requests.
- Version the corrected definitions and keep every qualified native
profile in the per-turn lanes.

## Verification

- Baseline regression: failed against the unchanged catalog; retained
before the fix.
- Fixed catalog/controller selection: 39 checks passed.
- The first real warm-policy attempt completed and saved its workspace
but timed out because the file oracle demanded live content; retained
trace responses prove the API returned the correct saved snapshot with a
retained lease.
- A new regression fails on the previous reader and passes after
separating saved file source from retained versus released location.
Focused catalog, reader and rolling checks: 81 passed.
- The next warm attempt reached replacement and exposed a second fixture
defect: warm also selected a SIGKILL outage, which the supervisor
rejected alongside rolling mode. The failure remains retained; its four
owned sandboxes, temporary key and local bucket were deleted.
- An outage-selection regression failed before the fix; 57
outage/supervisor checks pass afterward, including assembled requests
for both rolling lanes. The fresh warm Codex run passed all 56 checks in
8.5 minutes: original run/session/runner/lease retained, authenticated
takeover, both predecessor homes removed, later native continuation and
saved file readback. Two replacement receipts recorded 742 ordinary
reads and 75 writes, all 75 read back, with zero HTTP probe failures. A
transient `native_workspace_sync_out_failed` phase recovered before
successful finalization and remains retained. This source-lane result
does not claim released-image or hosted Railway qualification.
- The invalid earlier attempt was interrupted before deployment. Its
four archived disposable sandboxes were deleted and verified absent; its
temporary key and local bucket were removed.
- Broad local typecheck reached stale shared database declarations in
this checkout's linked build dependencies. The fixture's own type error
was corrected; clean-head CI remains required. No full build is claimed
locally.
- An incidental report-catalog test selected by a substring filter
failed to generate its normalized output. That failure is retained
separately; the focused catalog/controller checks pass.

- Review follow-up: fixed the same policy conflict in the base
file-storage, legacy migration and controller-outage suites. The roster
now has 822 valid cells; unsupported warm combinations remain covered
per-turn. Updated the explicit supervisor-request control to use a
supported warm provider. Focused catalog, file-reader, migration,
rolling and supervisor checks pass (133 checks).
- Earlier full CI passed at dd5aa71 using the built-in GitHub-hosted
fallback after self-hosted runner shutdowns. That result does not
qualify this new head; fresh CI and review are required. The final head
now has a 5/5 review and passing full CI (run 41901807639, attempt 2).
Attempt 1 hit two unrelated port collisions: the unchanged managed Codex
credential lease test and CLI company-server startup on a busy requested
port. Both passed on one failed-job retry. Those failures remain
retained.

## Risks

This changes test setup and coverage. It does not change agent runtime
defaults or provider capabilities. Warm cells use the production
capability boundary, while every qualified native profile keeps its
per-turn cell.

## Model Used

OpenAI Codex, exact model ID `gpt-6.1-sol`, with reasoning, tool use and
code execution. The host does not expose 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 linked existing issues or described the issue in-PR
following the relevant issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links
- [x] My branch name describes the change and contains no internal
ticket id or instance-derived details
- [x] I have run the relevant tests locally; failures and limits are
retained above
- [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 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-11-04 14:40:45 -06:00
DottaandPaperclip 3bd52a9fa0 test(evals): pin task-history discovery and governed handoff repairs (#18995)
## Thinking Path

> - Paperclip must complete work through ordinary human and agent
controls.
> - The paired timeline attempt omitted a real human handoff, although
the other ten checks passed.
> - The agent used the always-exposed active-task history tool as if its
comments were a status audit.
> - The tool now states its actual scope and directs chronology and
handoff questions to the existing discovery and API tools.
> - A separate approved-tool attempt preserved permission and write
boundaries, but paired Markdown emphasis caused a false outcome
rejection.
> - The reviewed oracle normalizes that formatting before the existing
outcome checks and retains balanced negatives.
> - This PR pins those corrections with the already reviewed personal
secure-handoff admission repair for one new representative batch.

## Linked Issues or Issue Description

Refs #18962, #18968, #18971, #18972, #18977. Follows merged #18976.

The original paired results remain FAILED. Result 4412 omitted the
actual human handoff; this is a real answer gap, not a date-oracle
excuse. Result 4411 correctly handled the first rejection with no writes
or Trust action and rejected agent permission, but the observer misread
paired inline emphasis in the truthful outcome. The personal-secret
result 4378 remains FAILED at admission; secure save and worker proof
were not reached. No prior grade is rewritten and no new native pass is
claimed.

## What Changed

- Pin immutable candidate `249b487a2d2451763913038cc009f7090580d1f1` on
`codex/chat-catalog-human-answer-admission-candidate-20261104`.
- Extend exact prior source `b1119630003785c9e26e14c763859125642ad756`
with only the accepted timeline-discovery and formatting corrections: 12
source, test and generated files, with 72 additions and ten removals.
- Use the canonical `get_task_history` description in the actual exposed
semantic catalog. It reads only bounded active-task comments; calling
`get_task` does not change that active scope. It is not a status or
assignment audit. Progress and handoff questions must discover the
company timeline or issue activity, then use the existing API call.
- Regenerate semantic catalog and protocol projections on this frozen
candidate. Preserve all non-description fields, schemas and authority
boundaries. Do not copy newer master catalog or document-schema changes.
- Normalize paired inline emphasis before approved-replay outcome
checks. Declare only that oracle as app-review v6. Keep timeline v5,
personal v5 and company v4.
- Retain the reviewed personal completion-context, addressed-human,
optional-note and rendered-placeholder safety controls. Actual private
save, owner isolation, audit, authorized worker delivery and native
continuation remain required.
- Update only the existing manifest, expected pin and descriptor
snapshot in this infrastructure PR. Preserve all 244 identities,
original requests, run/human counts, clocks, model, launcher bytes,
privacy limits and qualification holds.

## Verification

- The combined candidate passed 542 existing owning controls across 19
suites, including catalog contracts, consistency and 242 lazy
declarations with no fixture callbacks. The manifest retains two legacy
tasks, for 244 identities.
- Candidate Runner checks passed: 15 semantic consumer tests and 12
catalog tests. The owning Runner TypeScript compiler passed after the
existing eval-kernel prerequisite built. The first compile reported
missing ignored eval-kernel output; the repair used candidate-owned
ignored dependency links and output only. No repository type or
acceptance rule was changed.
- All three generated checks passed: semantic-action catalog, semantic
contracts and protocol manifest. Deep comparisons prove each generated
catalog differs only in `get_task_history.description`. The seeded
fixture changes only its catalog hash, and the protocol manifest changes
only the hash of that fixture. The compiled canonical catalog hash
matches the fixture. The candidate import conflict added only
`getTaskHistoryAction`; no unrelated newer document-schema import was
copied.
- Both owning fixes cleared fresh exact-head Greptile 5/5 with no
actionable threads before this publication: timeline
`7f6ba9686b5edba005a49cd15c0d0b52248178dc` and approved replay
`0015a79c1e0a3af5292edf4a61aa9bab8f381899`. The personal prerequisite
`789bec74a0f43011723fff45596ef9d084bfaba7` also cleared exact-head 5/5
and all 12 threads before its earlier integration.
- All 131 existing pin, TestOps contract/API, adapter, reconciliation
and streaming controls passed. The descriptor snapshot matches the
actual candidate bytes. The only new declaration change from the prior
candidate is app-review v5 to v6. Whitespace checks passed.
- The SDK source guard reports 506 unchanged inputs, runtime pins
unchanged, registry
`efa70621e9fb42aa185f7ee616a1a726aa3eccb367e67e28817cedf26ef2ade8`. No
SDK registry or runtime certificate renewal occurred. The existing
reporting-lock guard returned `already-reviewed` with lock
`60f4c06bca47af3ab9d74281f2ef2e1ff559d566b862ba51c2fbe6c8e5bac35b`.
- Historical CI results remain recorded. Head 73ea had a server-5
cancellation with exact AWS Spot-reclamation proof. Head 16134 had 44
successful jobs, three failed leaves and dependent verify failure, plus
one selector skip. Two failed hosts had exact Spot termination proof;
server 11 had two real deadline PostgreSQL failures. After an initial
libzstd setup block, the unchanged four-test suite passed locally on
exact merge `70e68bff5fb89251f769671ce9ab949ab5bf7fc9` in 33.69 seconds
with its original deadlines and assertions. This does not establish the
CI cause. One recovery POST returned HTTP403; zero replications were
accepted.
- Prior head c95 finished with 41 successful jobs, six failures, one
cancellation and one selector skip. Four leaves had exact
Spot-termination proof; three of their execution logs were unavailable.
Server 11 instead had a real `live-recovery-work` next-deadline
assertion failure, and server 4 had a real workspace-health
connection-refused failure. Dependent verify failed. Windows passed. No
replay or claimed test fix erased those results; their two assertion
causes remain unresolved.
- Exact head `1e89df928f7ccb43bf7af3b814f2c2207d75883a` now has
successful normal CI run 41888521175 (attempt 2: 48 successful jobs and
one selector skip) and successful Windows run 41888521015. The first
attempt retained 46 successes, the failed Typecheck leaf and failed
dependent verify, plus one selector skip. Typecheck reported runner
shutdown without a TypeScript diagnostic; its Spot request reported no
capacity, while the later EC2 termination reason was
Client.UserInitiatedShutdown. One authorized unchanged-head targeted
recovery reran only Typecheck and dependent verify; both passed. This
does not claim a code fix or establish the cleanup caller. All other
successful results were carried forward, not fresh remeasurements.
- Current exact-head Greptile and Paperclip assessments are both 5/5
with no actionable findings; Paperclip check conclusion is neutral, but
its final assessment completed and states Ship. Security checks passed
and no review thread is unresolved. Full repository build/typecheck/test
were not repeated locally for this three-file metadata change. A fresh
actual-serving source, reporting-lock and selection guard remains
required after a normal merge and before a new Submit.
- No model call, eval dispatch, secret mutation, private archive
download, fleet change or merge was performed by this update. The single
targeted CI recovery is recorded above. Separate core PRs remain
unmerged.

## Risks

The discovery description may change tool choice; its effect on the
missing handoff remains unproved until a new native attempt. Formatting
normalization can affect outcome admission, so existing positive and
negative semantics remain required. The personal secure-entry and worker
phases are still unproved. The next representative set is timeline,
approved-tool replay and personal secret. Company selection remains
gated on personal secure-entry and worker proof. The uniform ten-case
regression remains pending, and the full 244-case catalog remains
unqualified.

## Model Used

OpenAI `gpt-6.1-sol` through Codex. Capabilities used: source analysis,
isolated mechanical integration and local code execution. The host does
not expose the context-window limit. The evaluated model remains
OpenCode/OpenRouter `deepseek/deepseek-v4.1-flash-1017`.

## 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-11-04 13:00:37 -06:00
DottaandPaperclip 3a2249dd57 fix(runner): retry proven ingress bootstrap failures (#18981)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Native execution must retain its admitted model and execution
authority during recovery.
> - A sandbox provider can reject Runner endpoint acquisition before the
Runner gets a credential.
> - The old error path loses the structured HTTP status and leaves that
startup failure ambiguous.
> - A zero counter in an old checkpoint cannot prove that no credential
was issued.
> - This pull request adds a versioned producer proof and carries closed
provider status through the existing RPC.
> - A proved transient startup failure uses the existing retry budget. A
terminal proved-unused run can settle its accounting.

## Linked Issues or Issue Description

Refs #18018 and #18934. Those changes restore existing checkpoints and
ready retained environments. This change covers endpoint acquisition
before Runner dispatch. A search of related public PRs found no
duplicate implementation.

**What happened?**

A provider HTTP 502 during Runner endpoint acquisition becomes an
untyped worker error. Native recovery treats it as ambiguous and stops
without retrying. The run's native usage receipt also stays pending
after startup ends without model work.

**Expected behavior**

Retry a structured transient endpoint failure only when the complete
current controller checkpoint proves that this exact run never issued a
Runner credential. Preserve authentication, configuration, Stop,
ownership and provider-progress gates. Settle zero usage only under the
existing terminal accounting owner.

**Steps to reproduce**

1. Use the controlled endpoint in the Daytona ingress integration test
to return HTTP 502.
2. Register the actual native Runner driver and persist its bootstrap
journal through the encrypted checkpoint writer.
3. Observe the old terminal ambiguous disposition instead of bounded
startup recovery.

**Paperclip version or commit**

Reproduced on the pre-change master source. The original regression used
the production native driver, a real HTTP fault, a real durable control
plane and local Postgres. The new contract additionally tests the pinned
Daytona SDK and real worker RPC.

## What Changed

- The controller owns a v2 persisted state with retained origin and
credential history. Current readers still accept v1. Older writers
reject v2. Restore and checkpoint decoding do not add missing history.
- The proof validates the complete bootstrap journal, all six identity
fields and every delivery, credential and progress control. The server
rechecks its fingerprint under the current controller claim before retry
or accounting changes.
- Daytona and the SDK carry a closed acquisition phase and HTTP status
through the existing ingress RPC. Both public error wrappers omit
response bodies and causes, including Pino cause serialization.
- Only structured HTTP 429 or 5xx ingress failures can use the existing
three-attempt startup budget. HTTP 401/403, configuration and unknown
errors do not gain retry authority.
- A terminal proved-unused run wakes existing accounting and records
zero provider work. It does not create a semantic result, prove physical
termination or release an unknown process/workspace hold.
- The normal automatic second attempt rechecks its exact claim, frozen
execution and matching complete local/encrypted journal before admitting
absent remote Runner state. It keeps the original pending bootstrap
command IDs. A proved unused Codex home can rematerialize sealed skills.
Full raw local state is checked before streaming-event or policy
projection.
- Normal saved-state readers and the existing E2E journal evidence
matcher accept the closed v1/v2 set. The separate legacy no-launch
witness is unchanged. Technical docs describe the contracts.

## Verification

Current head: `cd38f70409cdb8664e14bfbf4efa208f468a0419` (final delta
adds only fixture artifact preparation). Production files are unchanged
from the independently reviewed `93c8a33520` source. Full repository
typecheck and build passed at `96417acb58`; the affected server
typecheck also passes after the final two-line fixture delta. Focused
protocol, raw-proof, real retry, SDK and RPC acceptance pass on this
source. Earlier broad suite counts are listed with their limits below:

- Durable Runner protocol: 187 tests.
- Native executor, driver, startup/accounting and redaction: 1,211
tests, including real Postgres and encrypted checkpoint persistence.
- Normal saved-state restore/projection compatibility: 21 focused cases.
- SDK: 209 tests.
- Standalone Daytona: 544 tests; 8 opt-in live tests skipped.
- Explicit standalone `pnpm -C
packages/plugins/sandbox-providers/daytona exec vitest run --config
vitest.sdk-ingress.config.ts`: 6 cases with real pinned SDK 0.203.0 and
worker RPC ingress acceptance. These include lookup 502/401/403/400,
private-preview 502 after successful lookup/refresh, missing credentials
and private-response exclusion.
- E2E journal evidence: 4 cases across both supported formats, with
wrong ownership, missing stimulus and unknown-schema controls.
- The exact historical controller source rejects a new v2 checkpoint at
decode and restore. A v1 control is accepted. This verifies the
downgrade fence with the actual older parser.
- Startup controls cover issued and pruned credentials, old/truncated
journals, provider progress, exhausted retry accounting, and
checkpoint/Stop/controller-claim races. Race cases retain the current
execution and pending usage.
- New exact admission controls: 19 cases through encrypted persistence
and cold restore. They cover current/stale/expired claims, Stop, pause,
model/trust/account changes, prior progress, issued/pruned credentials,
adopted/old/truncated state, local/canonical fingerprint mismatch,
hidden delivery, unsupported work and company scope. Two additional
red/green cases prove that raw local stream progress and missing event
policy are rejected before lossy checkpoint projection. No case mutates
run, claim, result or accounting state.
- Actual native executor, scheduler and Rust Runner retry: 2 cases.
Codex uses its fake app server. OpenCode uses the real proxy and fake
OpenCode HTTP server with the frozen DeepSeek model and allow permission
configuration. Each path launches no Runner on attempt 1, starts one
Runner and provider on attempt 2, reuses both original command IDs,
commits one accepted result, validates the persisted local workspace,
records nonzero synthetic native usage and settles accounting once. No
zero-work accounting flag survives.

The controlled SDK and protocol tests use local source, isolated
PostgreSQL, a private HTTPS preview and fake provider servers on macOS
arm64 with Node 24.22.2. They create no hosted sandbox and make no model
call. The root workspace intentionally omits standalone provider
dependencies; the explicit SDK target fails if its pinned dependency is
absent and has no conditional skip. They do not qualify hosted rollout
or repair an old unmarked checkpoint. The first full local typecheck
found missing checkout SDK links from an install with scripts disabled;
the repository link helper repaired that setup.

Current-head Linux CI typecheck and build pass. Independent final review
checked 12 source scopes and six raw-proof controls with no remaining
finding. Fresh Greptile review is 5/5 with no unresolved thread.

The full Runner CI suite found two older control-peer test doubles
missing the new proof method. Both now return no proof, with all 27
permission, ordering and cancellation assertions retained and passing.
The new Cargo-dependent native retry suite uses the existing Rust-cached
CI lane. All 39 lane coverage controls pass and prove complete,
duplicate-free suite coverage. The first full test run stopped at an
admitted chat Retry polling failure. CI also found a stale
retained-allocation fixture, now repaired on master by #18984, and a
canceled runner job. A real SDK suite initially relied on a dependency
absent from the root workspace; the explicit standalone target now owns
that acceptance.

The separate Product E2E support run had 12 failures in four untouched
files. All 12 reproduce on the original clean base with independent
dependencies, compiled base source and verified workspace resolution.
These concern workflow expectations, cleanup timeout arguments, a
profile snapshot and operating receipts. They are not passing
acceptance.

The later full local repository test command stopped at a 15-second
timeout in the unchanged GitHub pre-allocation retry `controller` case.
That exact case passed in isolation with unchanged assertions. The broad
Runner run initially omitted `test:typescript:prep` and lacked debug
fake-provider binaries. Required preparation then passed 370 + 44
package contract cases (11 skipped); the prepared full package run
reported 4,932 passed, 9 failed and 13 skipped. All failed families then
passed with unchanged assertions in isolation: 8 ACPX controller tests
and 2 credential controls. The paired original-base ACPX control also
passed. The full-run failures remain recorded; they are not passing
full-suite evidence.

The first Rust-cached native CI run found a missing generated OpenCode
proxy in a fresh checkout. The fixture now runs the existing verified
provider-entrypoint builder. Removing the generated proxy reproduces the
exact ENOENT before the fix; both real retry cases pass after the fix
from the same absent-artifact state.

All current-head CI gates pass, including the aggregate verification
check. Linux native CI passes all 10 suites: 177 tests pass and 14
opt-in cases skip. Both real provider retry cases pass. The full Runner
package passes 297 suites and 4,950 tests, with 1 suite and 10 tests
skipped. The CLI workspace groups pass 4,762 and 286 tests. The first CI
attempt had Runner shutdowns in the Runner package, Canary and three
general server jobs. One unchanged CLI shard also hit child-server
startup and dense ZIP deadlines. Both CLI files passed unchanged in
isolation: 18 tests. One bounded rerun of unsuccessful jobs and their
dependents passed. The original failures remain recorded.

## Risks

- Older controllers reject newly written v2 state on downgrade. Current
controllers retain v1 restore support, but old or unmarked state cannot
gain this new proof.
- An older plugin that omits structured ingress evidence remains held.
The server and provider must use the new producer contract for this
recovery path. The Docker `cloud` target builds the SDK, server/Runner
and standalone Daytona producer from one source tree. The default
`production` target does not build the standalone producer. Hosted
rollout must confirm the new image and active image-owned plugin worker;
a registry version alone does not prove its source. An npm-installed
producer needs an explicit matching artifact upgrade.
- This prevents future proved startup failures. It does not release
historical accounting based on an old checkpoint, change retry budgets,
replace a model or weaken sandbox isolation.
- Zero model usage is separate from process termination, saved files and
resource release. Those owners keep their existing gates.

## Model Used

OpenAI Codex with tool use and code execution. This runtime does not
expose the exact backend model ID or context window to the agent.
Read-only independent agents reviewed checkpoint compatibility and
SDK/RPC error boundaries.

## 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 (affected suites; full
local run limits are recorded above)
- [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-11-04 12:16:51 -06:00