Skip to content

O03 Specify limits and recovery semantics #104

Open

Description

@andrewperis

Approved backlog tracking only; unassigned. Execution requires separate authorization.

Parent: #101

Proposed accountable owner

E

Dependencies and qualifying boundary

O01; P/H

Root means no additional task dependency after common execution/owner/access gates; it does not authorize immediate execution. Human decisions and passing verdicts are required where specified; closed state alone does not establish acceptance.

Deliverable and acceptance

Bounded job/time/resource limits, injected clock/read/verification interfaces, cancellation and retry/resume rules with failure examples. Contract-owner decision recorded.

Preliminary estimate

0.5–1 focused person-days, including focused tests and handoff.

Common scope and dispatch constraints

Target each execution task at 0.5–2 focused person-days, including its own focused tests and handoff notes. Each row has one reviewable outcome. Estimates are preliminary, not guarantees. Before execution, the owner checks the affected code/content and re-estimates; anything exceeding two days is narrowed or proposed as additional bounded tasks before starting. Discovery tasks finish with evidence and a decision, not an obligation to implement an unknown system. Do not split off mechanical tests or documentation into extra tickets. Before dispatch, record the target repository/files or content set, one bounded supported path, the finite fixture/output matrix, explicit exclusions, and the evidence needed for acceptance. The owner confirms the complete outcome, including focused tests and handoff, fits two focused person-days. If it does not, return a narrower scope or additional proposed issues before execution; do not begin an open-ended implementation under the original label.

All 44 start as unassigned GitHub backlog issues, with a proposed accountable owner below. Approval here creates tracking only. No Paperclip execution tasks or agent dispatch until execution is separately authorized. On dispatch, map dependencies to actual blocker IDs; human approvals must be recorded as explicit gates. Completion of a review task means a verdict exists; downstream work additionally requires a passing verdict or resolved findings. Parent links alone do not unblock work.

Owners: E = Studio Engineer; Q = Studio QA; S = Chief of Staff coordinating editorial/source/publisher decisions. Human creative, canon, private-source and publication authority remains with the relevant human owner. S can draft proposals and prepare decision packets but cannot grant those approvals. For independent Q tasks, findings are posted on the reviewer's own task and the verdict is the deliverable even when adverse.

Contract changes belong in Codex under its owner; runtime implementation belongs in Platform; Studio holds governance and tracking; Universe and Lore hold their respective content. Each issue identifies its target repository/artifact before execution. Each dispatched issue has one accountable owner; C07/C08 require an appointed art owner, C13 proposes andrewperis as the human publisher, subject to explicit acceptance/authority at C11, and C12 remains independent QA. This proposal makes no agent assignment or release authorization.

Common prerequisites: approved execution scope, accepted relevant contracts, authorized tools/data and an actual owner. “Root” means no additional task dependency after these gates. Root tasks produce distinct artifacts and can run in parallel. H = handoff/dependency boundary; P = parallel independent deliverable; R = independent review; G = governance boundary. These explain the splits in addition to the user's preference for smaller tasks.

Source: PER-5 accepted plan revision 6, revision ID 1a89d7f9-8449-4e9c-bb7b-e0e6d191b355. Approval covers backlog creation only. No new hiring, spending, private access, canon promotion or publication authority.

Epic completion boundary

O01, O02, O03, O04, O05, O06, O07, O08, O09, O10, O11, O12 complete synthetic orchestration core v1, not the full epic. Epic closure additionally requires C05 capability mapping, C08 actual assembly proof, C09 production outputs/build-result linkage and C10 passing independent verification, with all discovered integration tasks and applicable Manifest/Platform gates accepted. C09 depends on O12, not epic closure; this avoids a circular gate. No external-generation reproducibility claim follows from pinned-asset processing.

Technical progress — 2026-10-29

  • Codex PR #22 merged RFC 0011 at 3f5549f29faf1ca3e0912e6b8407dbe19310a7e2; Codex PR #23 records the bounded prototype-scope approval at current Codex main 4e704b2d5e3c341d651ef8b88387606670629015. RFC 0011 remains Draft and nonnormative.
  • Platform PR #53 merged the offline synthetic prototype at f66b755b797aa5d5b4dee5f7da9f6995c3e98f75. It enforces retry_after_ms through 86,400,000 ms; pre-merge validation was 35 focused tests, 754 full tests, and 326 Comic Manifest conformance cases.
  • Post-merge Codex CI #40 and Platform CI #115 passed on Node 22 and 24.
  • The current Comic Manifest validator cannot represent the synthetic no-output rate-limit failure as a terminal valid result, so retry remains contract-mapping-blocked and the prototype does not dispatch again. A no-output compatibility proposal was merged as Codex PR #24 at 40fa385b1bee274cb683cf1e0e9809f496031031 from head b0de1822e22c3cdac0f729e3fe3547b5937114db; exact-head CI #42 passed on Node 22/24. RFC 0012 remains Draft: no semantic tests were run, and version/schema, compatibility classification, normative adoption and runtime change remain undecided. The prototype's retry stays contract-mapping-blocked; O03's contract-owner decision remains open.

The merged RFCs and Platform prototype do not satisfy this issue's contract-owner adoption criterion. Keep O03 open and its completion checklist unchecked; retry is not accepted or enabled by this progress update.

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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions