PaperClipAI/doc/plans/2026-10-20-dependable-everyday-work.md

Dependable everyday work

Acceptance

Codex and Claude must finish ordinary engineering tasks through both the board and Slack, including authorized repository setup, automatic continuation, questions, restart recovery, follow-ups, Stop, and accessible result delivery. Normal rollout continues. Each core cell needs three fresh successful attempts at a recorded candidate revision and deployed staging proof; failed attempts remain evidence. A provider success or a green task badge is insufficient.

Delivery and ownership

The implementation lead owns the composed journey. The first repair slice owns task-outcome presentation, monitor publication provenance, and complete question cards. The second slice owns the six Product E2E journeys and explicit daily selection, reusing the existing campaign accounting and reporting pipeline.

Boundary	Required evidence	State
Yielded monitor presentation	Explanation retained; no false completion or duplicate question	Repair and focused checks pass
Monitor conversation lineage	Exact scheduling receipt; current authorization; no unrelated channel disclosure	Repair and database checks pass
Free-text question card	Prompt, context, and Respond visible; answers stay private	Repair and database checks pass
Repository preparation	Authorized context; automatic successor; retained workspace and tools	Same-agent continuation repair and composed regressions pass; live proof pending
Finalization recovery	Saved result survives; zero repeated completed provider turns	Saved-summary repair and database checks pass
Migration and follow-ups	Configuration retained and subsequent work delivered	Qualification pending

Qualification matrix

Six journeys, each on Codex and Claude through Slack and the board:

1. Repository task with independently verified accessible output.
2. Projectless task, repository preparation, automatic continuation, output.
3. Legacy-to-native conversion retaining configuration, followed by useful work.
4. Necessary free-text question, answer, and exactly one continuation.
5. Restart during finalization, recovery, and exactly one final delivery.
6. Active follow-up, Stop, later resumption, and retained context.

Use production instructions, recorded runtime configurations, immutable remote images, isolated tasks, and a dedicated test channel. Negative checks cover revocation, forged lineage, duplicate wakes, stale settings, and restricted workspaces. Keep source, runner, model, settings, evidence, timing, cost, and attempt identity with every result. Never infer historical qualification from the presence of a fixture.

Baseline

Source base: 8b4ab65b1c3d863d282752e83307943720a5c85c. Private incident evidence stays outside the public repository. The serving container build record independently matches the source base above. Runner artifact and historical successful deployment still require independent capture. Workspace and lifecycle changes identify changed execution paths, not an established single introducing cause. The earlier staging settings regression already has a merged repair; verify it rather than duplicating that change.

Verification record

The original source fails four composed database regressions: monitor origin, yielded completion, question body, and saved-summary recovery. The initial response-resolver regression also fails independently on the original source. The repaired six-file cohort passes 148 checks against real disposable PostgreSQL, including existing monitor scheduling, revocation, and recovery boundaries. Workspace typecheck passes. Full build, full suite, review, and live qualification remain separate gates. No deployed acceptance is claimed here.

The repository repair adds current-task pending-repository eligibility and uses the existing same-agent status decision and wake queue. Five composed server suites pass 100 checks, and the shared provider continuation driver passes 12. Server typecheck passes. These results include long conversation lineages, cycles, broken ledger receipts, current-task repository ownership, and completed repository rejection. Explicit completion and review modes remain distinct from an unfinished standard-task yield. They do not establish the live matrix.

A fresh local provider pilot exposed a separate repository authorization defect: the native API retained the local-board identity while the workspace fence expected its older null representation. A native-tool/HTTP/PostgreSQL regression reproduces the rejection before the fix. The repaired authorization cohort passes 78 checks, including revoked membership, changed sponsor, and restricted child workspace cases. A committed setup blocker now ends the E2E attempt immediately instead of consuming its remaining deadline. The failed pilot remains evidence; these regressions do not replace a fresh provider run.

The next provider attempt passed that identity boundary and staged its repository, but then submitted a system blocker instead of yielding. The provider-facing completion description had omitted the saved workspace continuation. The server also accepted a repository_checkout_pending blocker that cited the exact pending repository on the active task. The repair clarifies the existing completion tool and rejects this report before acceptance with the normal yield action. It does not rewrite an accepted result or create another recovery mechanism. Real access restrictions, approvals, dependencies, paused tasks, cancelled tasks, changed run ownership, and failed or unrelated repository receipts retain their gates.

The real PostgreSQL completion regression fails before the repair. The repaired completion/context cohort passes 50 checks, the runner cohort passes 107, and E2E support checks pass 38. Server, runner, and E2E typechecks pass. Copilot v54 binds the changed shared completion guidance; v53 remains a historical identity. The three development pilot failures remain retained. These checks do not count as the required staging matrix, and a fresh provider run remains necessary.

The fourth development attempt reached a successor through a monitor fallback, then failed before provider startup while applying Git exclusions to the task root. It is a failure of the required same-agent journey, even though a successor started. The log records Git's exact non-repository error. A real-Git and database reproduction shows the same error for a declared plain task directory containing inert Git metadata. The original attempt did not retain that metadata's contents or establish which component created it.

The next narrow repair lets only an explicitly declared plain task root proceed past Git's exact non-repository result. It leaves the existing files intact. Configured checkouts keep strict validation, real Git roots still receive the exclusion, linked metadata stays rejected, and missing Git stays an error. The repair's Git and authorization cohort passes locally. Fresh provider remeasurement and the monitor-fallback defect remain open.

Two additional Product E2E journeys now cover configured repository delivery and real legacy-to-native conversion followed by verified work. Each checks a fresh fixture-owned source file, its hash and Git commit, retained configuration and instructions, the actual native provider/model, and a registered download visible after reload. A third explicit selection replays automatic repository setup with the recorded Codex and Claude models. All twelve new cells declare development API-key authentication and per-turn lifecycle differences. None counts as staging subscription, warm lifecycle, Slack, or the complete 24-cell milestone. Fresh provider measurement remains required; catalog registration is not acceptance. The fifth development attempt uses the recorded Codex model. It has no monitor, but selects a response wake and then reaches productive-continuation recovery. Its next admission still fails at Git setup. The first plain-root regression had used a task_directory strategy that the runtime does not persist. The production runtime records project_primary, task ownership, and a task_session source. A corrected real-database reproduction fails with that recorded representation. The repair now checks those current ownership/source fields and absence of a root repository or configured project source. Shared and isolated task directories are covered; configured, agent, worktree, and adapter-managed roots stay strict. The second Git helper caller was inspected, but is not established as this attempt's cause. The fifth failure remains retained, including the distinct response-wake selection. Live same-agent acceptance is still open.

That fifth attempt also exposes an independent completion-validation gap: a provider can report an unsatisfied objective, leave remainingWork empty, and yield to response_wake without any pending response. The existing gate checked only blocking remainingWork entries. A real-database reproduction accepts that invalid report before repair. The same gate now also checks an unfinished objective. Current questions, approvals, pause holds, conversations, and authorized external response waits retain their earlier checks. No accepted result is rewritten.

Review then found that shared-workspace restoration relabeled a retained task source as project_primary before repository admission. A new regression performs first workspace preparation and reuse against the real database; it fails at the source transition before repair. The corrected path retains task_session for an explicitly repository-free task directory, including its absent repository and ref instead of inheriting organizational defaults. Configured source pointers keep project classification. The composed regression also stages a repository through the real service and prepares verified bytes on the reused task root, with only remote clone transport replaced by an owned local repository. The queued sixth campaign was cancelled during its build, before provider execution, when this review finding made that candidate an uninformative paid retry.

The necessary-question journey now extends the existing continuation flow. Four explicit development cells require a visible free-text prompt and context, one real user answer retained on the unchanged question, an exactly bound provider resume or semantic successor, and an independently read exact saved confirmation with a visible link. Calibration preserves the existing continuation and question suites. These cells use production instructions and the recorded models, but retain explicit API-key/per-turn differences and do not count as Slack or staging qualification. Actual provider measurement is still required.

October 21 Stop qualification findings

The corrected live observer reached a real active provider, saved the follow-up, received the matching Stop acknowledgement, and observed the required quiet interval. A later real resume message was saved but could not start work. The retained run has a complete priced receipt with accounting still pending.

A real PostgreSQL regression reproduces the receipt-before-coordinator-closure race: the accounting worker goes idle before closure and is never signalled again. The repair adds accounting to that existing committed closure signal. It does not infer zero cost or relax budget admission. Partial receipts remain held; a later complete receipt settles one ledger entry without provider replay.

A second real-database regression shows that the old queue path could admit a follow-up saved before Stop. The repaired native path, like the legacy path, requires a later user message while preserving earlier undelivered input. Both reproduced failures remain retained. Fresh actual-model acceptance and deployed staging proof remain required before closing these repairs.