Skip to content

Epic: qualification, handoff reliability, and operational evidence through v1.5.0 #979

Description

@jeffhuber

Part of roadmap #900. Implements revisions 1, 2, and 4 from the completed hosted-Devin campaign; coordinates revision 3 with Slack #903 and revision 5 with the live roadmap/feature scorecards.

Outcome

Before Code Mower expands supervised hosted execution, qualification is role-specific, every takeover proves source-writer quiescence, contribution history and reviewer exclusion agree, and release evidence distinguishes completion, provider exit, billing settlement, stored metadata, and fresh aggregate views. Default setup remains Claude + Codex; Devin is a bounded optional builder. This is a completion epic, not an umbrella implementation PR.

The campaign delivered 3/5 hosted-Devin samples. #865 and #935 were completed separately by Codex #971/#973; the final #935 recovery was user-cancelled before delivering a change. Preserve that outcome and the corrected malformed-request explanation. Settled campaign billing remains unavailable, not zero. Final scorecard.

PR map and sequencing

“Planned PR” means no PR exists yet. Each implementation row gets exactly one PR in the OSS repository; the named builder is a proposed lane assignment, not an active session. Reviewers must be qualified, independent of all contributors to the current diff, and valid under repository policy. If no eligible reviewer exists, stop for one explicit owner action rather than self-gating.

Unit Issue / PR Planned builder Dependencies Completion gate
R1 accurate commands and live roadmap docs #965 / merged #981 Code Mower Claude current released interfaces before v1.4.1 #915
R2 optional review defaults #967 / merged #980 Code Mower Codex independent before #915
R3 role-specific qualification and admission #975 / merged #987 Code Mower Codex existing capability/policy contracts; coordinate docs after #965 before #915; then supervisor #977 and Board qualification #951
R4 effective authority and migration reporting #955 / merged #988 Code Mower Claude #975 before #915; then #951 and Slack setup #922
R5 quiescent, capable, consistent takeover #962 / merged #984 Code Mower Codex existing #751/#906 contracts before #915 and #963; then any automated takeover integration
R6 contributor lineage and reviewer exclusion #963 / staged children #990 (#994) → #991#992; unaccepted #989 preserved and #993 closed without merge Code Mower Codex core/producer; integration assignment pending #962 and #975; contract → publication → atomic consumer activation before #915; then local Board producer #949 and supervisor #977
R7 independent operational acceptance evidence #976 / merged #985 Code Mower Codex existing lifecycle/campaign/cloud facts before #915; consumed by #950/#951/#920/#923
R8 verify existing hosted aggregate freshness #974 / evidence-only verification roadmap orchestrator / hosted service operator existing accepted receipt fresh visibility verified before #915; rechecked for #923

A confirmed hosted defect under #974 becomes a narrowly scoped implementation child and one separate hosted PR, recorded here before work begins. No defect or PR is invented from a transient stale response. Unavailable settled provider billing is reported as a limitation; it does not become a fabricated zero-cost result or an unbounded wait.

Dependency and ownership boundaries

Acceptance and release checkpoints

R6 now uses three staged PRs rather than the original one-PR unit: #990 pure contract, #991 trusted delivery/publication, and #992 atomic admission/status/labeler/runner integration. A deterministic checkpoint at preserved unaccepted #989 head 0706c53922f67168dfbb6d2a6493a031a9b0f205 confirmed a cross-surface label-mutation inconsistency after 25 bounded same-session repair/completion rounds. The repair loop is stopped; its passing tests/CI do not override that invariant failure. The decomposition centralizes pure contracts and defers automatic label movement until all consumers use the accepted policy. #963 remains the outcome umbrella and closes only after all stages plus the final consumer matrix pass.

Each implementation child records exact PR/head, eligible independent audit, P0/P1/P2 resolution, focused/relevant tests, CI, authoritative gate, privacy, and accepted outcome. The epic closes only after all eight checklist items have completion evidence; v1.4.1 #915 and final v1.5.0 #923 require this closeout. Record missing measurements as unavailable, preserve user cancellation separately from implementation failure, and retain all historical campaign evidence.

Paid execution limits

This plan establishes no new provider-create allowance. Each future live campaign needs an explicit initial and aggregate ACU cap, one stable private binding per delivery episode, exact PR/head collection, and no automatic retry after uncertain outcomes. Permit at most one or two explicitly budgeted recovery creates before splitting work or changing builders. Use well-scoped bounded Devin tasks for observation canaries; use qualified Codex/Claude builders for cross-cutting recovery and orchestration. Record elapsed time, orchestrator/owner interventions, all deliberate creates, observed and settled usage coverage, and outcome separately.

Active completion target

Owner priority moves this entire stabilization epic ahead of Graphify publication #915. All seven implementation children and #974 freshness verification must have accepted completion evidence before v1.4.1 is declared complete. #914 Graphify implementation runs concurrently where source ownership is independent. The original v1.4.0 artifacts remain immutable; stabilization changes ship in the subsequent verified v1.4.1 package. Board #945, including service lifecycle #961, is the next active release after v1.4.1. Slack remains later scope.

The timing in the table above is strengthened by this target: #975/#955/#962/#963 and #974 are now required before #915, not merely before their later consumers. Unknown settled billing remains explicitly unavailable and is not an indefinite completion dependency.

Current accepted evidence and adoption follow-up

Latest accepted progress

#976 completed through #985 at reviewed head 7afb76361c175f2f4bffbba19888df2bb1ec76c1, merged as f452bc918d222427edb94b954c4e3d988022de69; independent Claude PASS, focused/package checks, full Python CI matrix and authoritative gate passed. Published-package inclusion remains #915. #974 is closed with separately verified stored receipt and fresh authenticated aggregate visibility; no duplicate upload or hosted defect was invented. Seven of eight epic units are accepted (#965/#967/#962/#975/#976/#974/#955). #962/#984 passed independent Claude review on 4764c745e8e56953407025455bf8ce4011dca7af, all CI/gate checks, and the actual installed-Codex containment rehearsal; merged as cbd454e0ab883dc4c442c8ef82eec3dd80fe4752 after writer quiescence and lease release. #975/#987 passed independent Claude review on 498b37143a5034526a6133f9276bff8b0e9c5560, 3,565 local tests with 12 skips, all CI/gate checks, and merged as c542536d68a5774d5c7db5d2f33a0e860e908872 after writer quiescence and lease release. #955/#988 is accepted with independent exact-head Codex PASS and all focused/full/CI/gate checks, merged as db4506d2b3232e4c6a7c5683251eeb536b2b8355. Only #963 remains, now staged through #990/#991/#992; unaccepted #989 does not satisfy it.

#990 is now accepted through the smaller Codex-authored #994 at reviewed head 6b1642d561ee46987870f492f95d4222179d2374, merged as e818a3b639dfe903bdc16aff3674af98a5a08233. The complete 80,246-byte, 10-file diff passed independent Claude review with zero P0–P3 findings; all 14 artifact parts were verified from exact raw Read results. Owning checks passed 30 tests and 214 subcases; canonical full discovery passed 3,688 tests with 16 skips, guards and all CI/authoritative gate checks passed. Writer and review processes were quiescent; the broker lease was released from held and independently observed absent before merge. #993 is closed without merge; #989 remains superseded evidence. #991 starts from this accepted base, followed by #992. Seven of eight epic outcomes remain accepted until the whole #963 consumer contract passes.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestepicEpic tracking issue

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions