mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-11-13 15:55:46 +01:00
f4337bb5fb
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The chat-feature evals measure whether agents complete real chat requests through the product > - The chat catalog eval harness and its repairs live on the `chat-eval/master-candidate` branch, not on master > - Today's work made 139 of 242 chat evals pass in verified single-case live runs. Each product fix landed on master as its own pull request > - The eval-side changes (setups, graders, fault seams, evidence capture) still exist only on the candidate > - This pull request lands the harness on master. Master stays the source of truth for product behavior > - The benefit is one tree: evals run against master commits, and product fixes reach the evals as soon as they merge ## Linked Issues or Issue Description Refs #19441, Refs #19599, Refs #20270, Refs #20334, Refs #20342, Refs #20344, Refs #20354, Refs #20360, Refs #20373, Refs #20382, Refs #20409 **What existing behavior does this improve?** The chat catalog eval harness and the product it evaluates live on a long-running branch outside master. Eval fixes do not reach master, so master-based eval runs use old setups and graders. **Subsystem affected** `tests/runner-e2e` chat catalog harness, plus a small set of product changes that exist only on the candidate. **Proposed change** Land the harness on master. Every product fix from this eval work already merged to master as its own pull request. Conflicts keep master's product behavior. ## What Changed - Most of the diff (808 of 851 files) is under `tests/runner-e2e/`: chat-catalog domains, scenarios, descriptors, the TestOps manifest, private evidence tooling, and their tests. - Graders now check saved state, setup literals and rendered or clicked links. Many keyword and regex checks on free-form replies are removed. Each changed grader has a bumped `oracleVersion` and calibration tests (a valid reply, a reworded valid reply, and broken variants that must fail). - The shared link helper `hasLink` no longer treats a list link (for example `/COM/issues?view=mine`) as a link to every task without a URL key. - Setup fixes build real state through supported product routes: routine history, agent grants through the board grant route, budget holds with a real cap, and a storage-layer archive fault for `inbox-search.archive-partial-failure`. - Browser boundary journeys (sign-in, chat-disabled, onboarding) now write the standard pass evidence files. - Retargeted cases, approved by the maintainer: `agent-chat.chat-disabled` (Conference Room gate), `agents.restore-instructions` (no saved instruction history), `access.manage-membership` (member permission edits stay board-only). - The private evidence trusted files (`manual-private-handoff.ts`, `manual-private-retention.ts`, `manual-private-report-assets.ts`) are byte-identical to master. - Product files outside `tests/` (43 files, +1,328 −49) carry candidate-only changes that master does not yet have. Most are tests. The main code changes are in `request-human-input.ts`, `heartbeat-run-summary.ts`, `native-completion-feedback.ts`, `native-run-finalizer.ts`, `openapi.ts`, `secrets.ts` and `IssueChatLongThreadPerf.tsx`. ## Verification - `pnpm vitest run chat-catalog-domains chat-catalog-contract.test.ts chat-catalog-consistency.test.ts unit-launcher.test.mjs --testTimeout=180000` in `tests/runner-e2e`: 269 files pass, 3,550 tests pass. - `node --test chat-full-catalog-testops-manifest.test.mjs`: 10 pass. - `node tests/runner-e2e/source-sdk-public-inputs.mjs <HEAD> --check`: no change. - `tsc` for `server` and `tests/runner-e2e`: clean. - Live single-case verification: 139 of 242 cases passed on paid runs, and a person read the saved evidence for each. These are single-case runs, not one full-cohort run. ## Risks - Large diff. Most of it is test-only, but the 43 non-test files change product code paths. Review those files first. - Some graders are now less strict on reply wording. A person must read replies for meaning on those cases. - 42 cases need disposable outside accounts (Notion, Slack, GitHub, Daytona and others) and stay blocked. `access.invite-teammate` stays failing until local agent isolation lands, because the runner's durable state keeps a live invite token. - The paid workflow compares the trusted private-evidence files with master. They are unchanged, so this risk is low. ## Model Used Anthropic Claude Opus 5.5 (`claude-opus-5-5`), with tool use and code execution, in Claude Code. Subagents used the same model. ## 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> Co-authored-by: Paperclip <noreply@paperclip.ing>
98 lines
4.7 KiB
YAML
98 lines
4.7 KiB
YAML
# yaml-language-server: $schema=./catalog.schema.json
|
|
# Planning scenarios; not registered executions or evidence of a pass.
|
|
schema_version: 1
|
|
feature: documents-artifacts
|
|
status: planned
|
|
scenarios:
|
|
- id: documents-artifacts.write-plan
|
|
capabilities:
|
|
- documents-artifacts/documents
|
|
context: >-
|
|
A delegated task has no plan document; the agent is authorized to edit its documents.
|
|
query: >-
|
|
Save a short implementation plan on the website task.
|
|
expected_outcome: >-
|
|
A versioned plan document is persisted on the intended task and linked in chat. Its
|
|
contents reflect the actual request and remain readable after reload. A conversational
|
|
paragraph alone does not count as saving the plan.
|
|
- id: documents-artifacts.restore-document
|
|
capabilities:
|
|
- documents-artifacts/documents
|
|
context: >-
|
|
The task has three plan revisions and the person identifies the previous version as the
|
|
desired content.
|
|
query: >-
|
|
Restore the plan to the version before the last edit.
|
|
expected_outcome: >-
|
|
The prior contents are restored through the document revision path while retaining audit
|
|
history. The agent identifies the resulting current revision and handles any concurrent
|
|
edit explicitly. Restoring text does not retroactively approve that revision or rewind
|
|
executed work.
|
|
- id: documents-artifacts.resolve-feedback
|
|
capabilities:
|
|
- documents-artifacts/annotations
|
|
context: >-
|
|
A review annotation is anchored to the pricing paragraph of a task document.
|
|
query: >-
|
|
Fix the confusing pricing paragraph and resolve my comment.
|
|
expected_outcome: >-
|
|
The agent reads the anchored feedback, edits the relevant document and resolves the
|
|
correct annotation only after addressing it. Unrelated comments remain open. Chat links to
|
|
the updated document and explains the substantive change, with the annotation relationship
|
|
preserved across revisions.
|
|
- id: documents-artifacts.produce-download
|
|
capabilities:
|
|
- documents-artifacts/attachments
|
|
- documents-artifacts/work-products
|
|
context: >-
|
|
The website task generated an HTML file in its authorized workspace.
|
|
query: >-
|
|
Give me a downloadable copy of the website.
|
|
expected_outcome: >-
|
|
The file is registered and uploaded through the product artifact path, with a download the
|
|
person can actually open. Its bytes match the produced work and its source task is
|
|
retained. A local sandbox path or an assertion that a file exists does not satisfy
|
|
delivery.
|
|
- id: documents-artifacts.revise-delivery
|
|
capabilities:
|
|
- documents-artifacts/work-products
|
|
- documents-artifacts/library
|
|
context: >-
|
|
Version one of a website is already delivered and accessible; a second revision is
|
|
requested.
|
|
query: >-
|
|
Shorten the headline and give me a new version, but keep the old one available.
|
|
expected_outcome: >-
|
|
The updated deliverable is a new, separately titled registered version, filed on the
|
|
source work or in the conversation that requested it, and the reply links it beside a route
|
|
to the original, which remains retrievable. The library opens both versions' stacks. The
|
|
agent does not overwrite the only retained copy or label stale bytes as the new revision.
|
|
- id: documents-artifacts.find-artifact
|
|
capabilities:
|
|
- documents-artifacts/library
|
|
- inbox-search/search
|
|
context: >-
|
|
Multiple website drafts exist across authorized projects; a restricted project has a
|
|
similarly named artifact.
|
|
query: >-
|
|
Find the final website files we delivered last week.
|
|
expected_outcome: >-
|
|
The agent searches visible artifact and task records, distinguishes final delivery from
|
|
drafts and returns usable source and download links. It uses the requested time context
|
|
and discloses ambiguity if there is no clear final version. Restricted artifacts and their
|
|
previews remain excluded.
|
|
- id: documents-artifacts.private-download
|
|
capabilities:
|
|
- documents-artifacts/attachments
|
|
- tasks/privacy
|
|
context: >-
|
|
A private task owns an attachment; a second observer lacks access despite knowing the
|
|
download link.
|
|
query: >-
|
|
Share the file from my private launch task with everyone.
|
|
expected_outcome: >-
|
|
The agent explains the source privacy boundary and the authorized sharing step instead of
|
|
publishing the bytes through another task or public URL. The copied download remains
|
|
access-controlled until a legitimate visibility change allows it. Chat contains no
|
|
unauthorized excerpt or alternate delivery that bypasses that boundary.
|