mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-28 12:04:41 +01:00
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Agent Chat lets a person assign work through a conversation. > - Feature and API maps do not prove that a natural request produces the right saved result. > - Product E2E already owns isolated fixtures, browser runs, evidence and cleanup. > - This pull request adds a chat scenario catalog and two real task workflows in that framework. > - Independent checks verify the task, its author, the saved output and the reply in chat. > - The benefit is a small executable foundation for broader chat coverage. ## Linked Issues or Issue Description **What existing behavior does this improve?** It adds real task creation and delegation coverage for Agent Chat. **Current behavior** Existing maps describe features and agent access. Existing chat evals cover specific protocols and handoffs. They do not connect a broad human-request catalog to independent saved-state checks. **Proposed behavior** Keep 244 planned scenarios across 35 feature areas. Promote two requests into the explicit-only `chat-features` suite. One saves a backlog task without starting work. The other delegates an announcement and returns the saved result to the original chat. **Reason and benefit** A successful tool call or confident reply does not prove the requested result exists. These evals check public API state, attribution and browser access after a real model run. **Breaking changes** No API or data schema changes. Chat instructions now require actual relative task links. The local E2E private-state scanner recognizes Codex account ownership metadata while continuing to reject credentials and model-visible identity leaks. **Additional context** Related prior work: #13969 and #13762. This improves verification of the existing Agent Chat roadmap item. It does not add a new core product feature. ## What Changed - Add YAML scenarios with capability IDs, starting context, user requests and expected outcomes. Validate all area files against their schema, global ID uniqueness and exact feature-map capability coverage. - Add two local native Codex subscription cells. Send the exact catalog request once through Chromium. - Seed only prerequisites through public APIs. Use shipped agent instructions and explicit disposable budget policies for unpriced subscription usage. - Check task ownership, creation audit, no premature execution, current worker-authored output, automatic completion delivery and usable links after reload. - Keep private Codex account ownership metadata distinct from bearer credentials. Scan rollout message content, all tokens and published evidence as before. - Teach normal chat instructions to use relative task links instead of invented hosts. Update tests, maps and the runbook. - Repair existing E2E contract drift: include the active Copilot identity in the image digest and update Pi profile expectations. Keep global catalog cardinality in its owning catalog test. Product E2E owns the new flow and grader. Its existing launch and report paths remain in use. The shared scanner change is limited to owner-private temporary Codex runtime metadata. Other callers retain the full secret scan. No UI, endpoint, schema or permission behavior changes. ## Verification - `node scripts/check-maps.mjs` passed: 35 areas and 191 capability IDs. - Product E2E typecheck and focused tests passed before rebase: 225 Vitest tests and 137 Node tests. Conversation service tests passed 40/40. Five existing runner turn-binding regressions passed. - Historical live measurement used real Chromium, server, database and native Codex with no automatic retries. The initial same-definition batch passed 5/6 cells. Backlog passed 3/3; delegation passed 2/3. One CEO startup failed because the runner did not receive a provider turn identity. The cause is unresolved. - An unchanged follow-up passed delegation three times and backlog twice. Combined evidence is backlog 5/5 and delegation 5/6. Each attempt passed cleanup. Later passes do not erase the earlier failure or prove a runner repair. - Earlier failed revisions exposed an invented task hostname, private account metadata false positives and missing funding for unpriced subscription usage. Those led to the specific changes above; the failed records remain retained locally. - The runbook records campaign identifiers and definition provenance. Generated result artifacts are not committed. Historical live results predate this branch rebase; fresh PR-source live evidence and final validation are recorded below. - Full workspace typecheck and production build passed on the rebased branch. Product E2E typecheck passed. - The full Product E2E support suite first reproduced four baseline failures: two missing active Copilot image-identity inputs and two stale Pi/catalog expectations. The narrow contract fixes above resolved them. The full rerun passed 4,282 Vitest tests plus 137 Node tests, with two skipped. Image checks verify mutation changes the hash, unchanged input stays stable, and an input closure without Copilot is unaffected. Original failed logs remain retained. - The repo-wide local Vitest run has reported two failures in unchanged service files. The Workspace connection test passed an isolated recheck and its full file passed 469/469 unchanged. The recovery test hit a 15-second timeout; its full file passed 89/89 unchanged. The run later hit explicit PostgreSQL `semget` resource exhaustion and was interrupted after those observed failures; no final aggregate counts or full local pass are claimed. Its complete available log is retained. No assertion or timeout was weakened. Matching remote server CI passed on the same source. - On clean PR head `39ad80b523ce194c90aafafd077d48dd9a36b4c5`, backlog passed in `local-2026-10-26T19-24-13-014Z`. The parallel delegation fixture failed during PostgreSQL initdb, before browser or model execution; its failed cleanup grade is retained. A disposable standalone initdb probe then passed. No semaphore sets or kernel settings were changed before that probe/recheck. After confirming no remaining fixture process, its private temporary files were removed. - One separate delegation recheck passed in `local-2026-10-26T19-29-24-800Z`, with one attempt, zero automatic retries and successful cleanup. Both passing current-source cells use definition `3f2c9ba2d03e3dcddde47ddab3b43bc52de977f25e256fceae0a24c9128e204b`. The earlier bootstrap failure and the historical provider startup failure remain distinct. These local results omit automatic source-SHA metadata; the clean checkout SHA is recorded here from the execution session. - The later broad local run reported `could not create semaphores: No space left on device`. A bounded cleanup removed 32 current-user PostgreSQL sets with 17 members, marker 537, a dead recorded creator and zero waiters. No live process or kernel limit was changed by that cleanup. The test process group was subsequently stopped; no broad rerun is planned. This direct later resource failure does not prove the precise cause of the earlier live initdb failure. - Review follow-up adds only static catalog validation and documentation of the existing five-minute journey bound. The executable definition is unchanged. Focused catalog/oracle tests passed 28/28; no redundant live run is claimed. - Final head `30fcb36ac9ae1f0270a589dbfafcec91ca6a03f3` passed all required and underlying CI checks in [run 40391402347](https://github.com/paperclipai/paperclip/actions/runs/40391402347), including `ci / verify` and `ci / e2e`. Greptile and Paperclip Review both scored this head 5/5, with all review threads resolved. The static follow-up leaves every executable definition input byte-identical to the live-tested source at `39ad80b`. Normal squash auto-merge is enabled. Actual merge is pending eligible code-owner approval for the owned dependency manifest; no protection is bypassed. ## Risks - Live model behavior can vary. One missing turn-start event remains unexplained; this PR does not claim provider reliability or broad catalog qualification. - Subscription costs are unpriced. Explicit fixture funding admits that usage. Run counts and deadlines remain bounded, but the dollar limit cannot cap unknown cost. - Account identity exceptions apply only to known private Codex runtime files. Token reuse, unknown files and model-visible rollout content remain blocking findings. - Deterministic checks establish saved state, output structure, required brief facts and access. They do not score all prose quality. Initial samples also require human inspection. ## Model Used OpenAI Codex, GPT-6 family, with reasoning, code execution, browser and repository tools. The precise model revision and context window are not exposed to this session. Live eval agents used `gpt-5.6-sol`; that is the evaluated model, not a claim about the authoring 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 local tests; focused suites pass and the interrupted full-run failures are documented 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>
137 lines
8.4 KiB
Markdown
137 lines
8.4 KiB
Markdown
# Chat feature evals
|
|
|
|
`chat-features` promotes two entries from the [scenario catalog](chat-scenarios/README.md)
|
|
into real Product E2E executions. The scope is deliberately small: prove the
|
|
fixture, browser interaction, independent grading and report loop before adding
|
|
more features. Catalog coverage is not live acceptance.
|
|
|
|
| Scenario | Actual user request | Independent outcome |
|
|
| --- | --- | --- |
|
|
| `tasks.create-backlog` | Add a task for Morgan to draft the launch announcement in Launch, but don't start it yet. | Exactly one task, Launch project, Morgan assignee, backlog at creation, no worker execution, usable chat link after reload. |
|
|
| `tasks.delegate-announcement` | Have Morgan write a two-sentence launch announcement using the Launch project brief, save it on the task, and send me the result here when it's finished. | Exactly one task, actual Morgan execution, current worker-authored document grounded in the project brief, task Done, automatic completion response in the original chat, usable result after reload. |
|
|
|
|
The queries are read directly from `chat-scenarios/tasks.yaml`. Context and
|
|
expected outcomes stay evaluator-side. The fixture creates a disposable company,
|
|
CEO, Morgan and Launch project through production APIs; both agents use the
|
|
shipped role instructions. The brief contains a product, date and random invitation
|
|
code absent from the user query. The browser sends one message through Agent Chat.
|
|
The harness never creates the result task, writes the announcement, completes the
|
|
task, or sends a hidden follow-up.
|
|
|
|
## Run the first slice
|
|
|
|
Follow the installation steps in [README.md](README.md#local-commands). The current
|
|
profile is local native Codex using the catalog's recorded default model and an
|
|
explicit `CODEX_AUTH_JSON` login. Load that login privately into the launcher
|
|
environment; do not print it or save it in tracked configuration. The existing
|
|
subscription fixture stages only `auth.json` in the disposable company login slot
|
|
and removes it with the isolated instance.
|
|
|
|
```sh
|
|
pnpm test:e2e:runner:typecheck
|
|
pnpm test:e2e:runner:unit
|
|
pnpm test:e2e:runner -- --list --suite chat-features
|
|
pnpm test:e2e:runner -- --id chat-features.runner-codex-subscription.local.create-backlog --max-automatic-retries 0
|
|
pnpm test:e2e:runner -- --id chat-features.runner-codex-subscription.local.delegate-announcement --max-automatic-retries 0
|
|
```
|
|
|
|
Run creation first and inspect its packaged report before delegation. For initial
|
|
acceptance, run each cell three times against fresh fixtures on the same definition
|
|
revision. Keep every attempt, including failures; a retry does not erase one. A
|
|
fixture or product correction starts a new three-sample measurement. Both cells
|
|
are explicit-only and excluded from `--all`; this does not implement or qualify
|
|
the rest of the YAML inventory.
|
|
|
|
## Bounds and grading
|
|
|
|
Creation expects one accounted native work run; delegation expects three (CEO
|
|
handoff, Morgan work, CEO completion response). Runs have a 120-second timeout
|
|
and attempts a seven-minute deadline. The visible task and completion reply must
|
|
settle within five minutes after the human request, including a five-second stable
|
|
observation. This is an independent journey acceptance bound: three runs may not
|
|
each consume their maximum timeout and still pass. The outer attempt also covers
|
|
fixture setup, reload and link checks, and evidence collection. A failed provider
|
|
run rejects immediately; the historical missing turn-start event was not a
|
|
five-minute poll timeout. Automatic retries are disabled. Company
|
|
and agent budgets are 500 cents each, CEO daily work runs are capped at three,
|
|
Morgan at one, and periodic heartbeats are disabled. Initial production hello
|
|
probes fall outside heartbeat usage and budget accounting; detailed setup tokens
|
|
and cost are unavailable. These limits are not an absolute inference or cash cap.
|
|
Subscription cost coverage must remain explicit in the report.
|
|
|
|
Because this subscription currently reports unpriced usage, setup explicitly sets
|
|
`unpricedUsagePolicy: allow` on the disposable company and both agents through the
|
|
public budget API and verifies all three policies. The 500-cent hard stops remain
|
|
enabled for reported costs; they cannot cap unknown dollar usage. Run caps and
|
|
deadlines remain independent bounds. Without this explicit funding prerequisite,
|
|
the default policy pauses the company after the first unpriced run and cancels
|
|
the delegated worker. Such a pause is not a successful chat journey.
|
|
|
|
`chat-feature.json` retains the scenario ID, capability IDs, grader version,
|
|
saved records, audit attribution, rendered links and individual checks.
|
|
`chat-feature-runs.json` uses the existing native run evidence collector, including
|
|
on failures. Setup evidence records fixture IDs, synthetic brief, readiness and
|
|
saved budgets. Ordinary Product E2E evidence packaging, redaction, cleanup, failure
|
|
classification and dashboards own the result. The definition digest includes the
|
|
query, defaults, flow and grader sources.
|
|
|
|
The grader rejects duplicate tasks, wrong owners/projects/companies, early execution,
|
|
missing audit attribution, missing or stale deliverables, extra human nudges and
|
|
uncorrelated completion replies. Document provenance binds the current revision
|
|
to Morgan's actual run. The completion check reuses `completionDelivery`; a
|
|
handoff promise or a marker alone cannot establish delivery. Chromium verifies
|
|
the task link and reload persistence.
|
|
|
|
The checks establish the specified saved state, two-sentence structure, required
|
|
brief facts and result access. They do not score writing quality or every semantic
|
|
claim in the response. Inspect the retained conversation and announcement before
|
|
accepting the first samples; the existing completion semantic-review rubric still
|
|
applies. Oracle calibration tests exercise both valid evidence and plausible wrong
|
|
outcomes without calling a model.
|
|
|
|
Only after this loop is stable should another scenario be promoted. Keep each
|
|
starting condition explicit: connected versus missing connection, allowed versus
|
|
approval-required, and so on. Reuse the fixture/report infrastructure and add a
|
|
case-specific outcome oracle; do not make all YAML paragraphs executable through
|
|
an unconstrained model judge.
|
|
|
|
## Initial measurement — 2026-10-26
|
|
|
|
Three fresh samples per cell on definition
|
|
`7fb20426ce3f1dd4efeddfb79f231336ea65a16b9c2a73bf6131e997acd74e9d`
|
|
produced **5/6 passes**: backlog creation 3/3 and delegation 2/3. These used local
|
|
native Codex subscription execution with `gpt-5.6-sol`. All six cleaned up
|
|
successfully. Both workflows have successful browser-to-provider evidence, but
|
|
the initial repeatability target is not met.
|
|
|
|
In campaign `local-2026-10-26T15-48-12-199Z`, the first CEO run in delegation
|
|
failed before creating a task: `runnerd did not report the provider turn identity`.
|
|
Retained events show submission and provider startup, followed by the transport's
|
|
turn-start deadline. The precise cause of the missing event remains unresolved;
|
|
the existing machine classification is retained without claiming that the provider
|
|
or infrastructure has been proven responsible. Investigate this before expanding
|
|
the suite. No replacement sample erased this failure.
|
|
|
|
The local `results/chat-feature-acceptance/acceptance.md` records every sample and
|
|
earlier failed revision; its sibling dashboard uses the standard report generator.
|
|
Results are ignored generated artifacts, so retain or publish them through the
|
|
existing Product E2E pipeline when handing this measurement to another machine.
|
|
|
|
### Follow-up measurement — 2026-10-26
|
|
|
|
The unchanged delegation cell subsequently passed three fresh executions:
|
|
`local-2026-10-26T16-50-50-751Z`, `local-2026-10-26T16-54-58-203Z`, and
|
|
`local-2026-10-26T16-58-39-074Z`. The latter two campaigns also ran backlog
|
|
creation concurrently and passed both cells. All five selected executions used
|
|
one attempt with zero automatic retries, retained the same definition above,
|
|
and passed cleanup. Five existing turn-identity, early-terminal and runner-exit
|
|
regressions passed as well.
|
|
|
|
These are green rechecks, not a demonstrated repair of the earlier startup
|
|
interruption: no production code, timing limits or oracle assertions changed,
|
|
and the missing turn-start event did not reproduce. Keep the original failure
|
|
in the history. Across the original final-definition batch and this recheck,
|
|
backlog is 5/5 and delegation is 5/6. The local
|
|
`results/chat-feature-recheck/verification.md` records the follow-up evidence;
|
|
its standard dashboard is explicitly scoped to the latest campaign.
|