mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-11-03 17:51:58 +01:00
DottaandPaperclip
5d40e75253
## Thinking Path > - Paperclip lets people manage AI agents and inspect their work. > - The chat catalog reports each original Product E2E case to TestOps. > - TestOps creates scheduled result rows before a case runs. > - Those rows have identity fields but no status property. > - The publisher currently mistakes any case row for an uploaded outcome. > - This PR distinguishes scheduled membership from an outcome after strict identity checks. > - Each case can upload once and wait for processing without changing its grade. ## Linked Issues or Issue Description Refs #18647, #18666. **What happened?** A real TestOps launch had all three scheduled result rows before any model case started. Each row had the expected case, project, launch and job-run identity. Its status property was absent. The publisher treated the row as already uploaded, skipped its only POST and then rejected readback. **Expected behavior** A fully bound scheduled row permits the first immutable case upload. It does not count as an outcome. Readback waits within the existing bound until the original status and exact attachments are ready. **Steps to reproduce** Run the new scheduled-row control against the parent API. It rejects before sending the initial result. Fixing only that initial check still rejects the first scheduled readback after one POST. ## What Changed - Share the strict result-detail identity check between initial inspection and readback. - Recognize an absent status property as scheduled only after that check. Present valid statuses, including unknown, stay readback-only. Malformed statuses and foreign identities fail closed. - Keep scheduled full-catalog readback unready within the same poll and deadline bounds. Keep the final status, evidence and attachment checks unchanged. - Calibrate three planned rows, delayed and permanent processing, unknown outcomes, wrong job/source and explicit-null status. Retain the once-only upload and uncertain-response controls. Use the registered legacy full-name alias in the fixtures. ## Verification - The real-shape parent control fails with `result_mismatch` after the first upload is suppressed. - A controlled initial-only fix sends one POST and still fails on scheduled readback. The final two-seam fix passes. - All 77 focused controls pass: `node --test tests/runner-e2e/chat-catalog-testops-streaming.test.mjs tests/runner-e2e/chat-completion-testops-api.test.mjs tests/runner-e2e/chat-full-catalog-testops-adapter.test.mjs`. - Both changed files pass Node syntax checks. `git diff --check` passes. - All local controls use synthetic data and mocked HTTP. No local app, database, native build or provider runs. - The affected live run was cancelled during build after metadata proved no original case had started. Its build instance is terminated. No original grade was changed or inferred. - Latest-head GitHub CI is green: 48 successful jobs and one skipped. Typecheck, build, browser and required aggregate checks passed. - The first CI attempt failed a heartbeat scheduling test’s five-second idle wait after its 51-admission assertion passed. Its six direct owners were byte-identical to the prior passing CI. One same-head failed-job recovery passed the server shard and required aggregate; all 46 earlier successful jobs were carried unchanged. The original failure is preserved, and its underlying cause remains unresolved. No heartbeat source, fixture or timeout was changed. - Live streaming qualification remains pending. No user command or documentation contract changes. ## Risks - The observed JSON distinction is status-property absence, not a result-stage or UUID field. Those fields are not used. - A scheduled row must match the current project, launch, case, registered full name, job run and GitHub source URL. It never qualifies as passed or complete. - The same 12-poll and time limits remain. A permanent scheduled state fails. A present outcome never causes another POST. An uncertain write still uses GET-only reconciliation. - Backend handling of uploaded scheduled rows still needs live qualification. Duplicate, foreign and final-coverage guards remain; this PR does not assume server deduplication. - Earlier dispatch and cancelled setup records remain separate. The first integration HTTP 500 cause is still unknown. No in-flight legacy workflow is changed or rerun. ## Model Used OpenAI `gpt-6.1-sol`, with tool use and code execution. The session does not expose a context-window size. The independent source peer uses the same model family. ## 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>