O02 Specify attempt identity and result lifecycle #103

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

Parent: #101

Proposed accountable owner

E

Dependencies and qualifying boundary

O01; 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

Reviewed transition table for exact revision, attempts, actual inputs/transforms/outputs, terminal results and protected immutable storage. 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 #21 merged RFC 0010 at 952518820f8f7984414acbedba9dcc8d7082f394; Codex PR #23 merged the record of the bounded prototype-scope approval at current Codex main 4e704b2d5e3c341d651ef8b88387606670629015.
• Platform PR #53 merged the synthetic in-memory prototype at f66b755b797aa5d5b4dee5f7da9f6995c3e98f75. Its pre-merge exact-head validation was 35 focused tests, 754 full tests, and 326 Comic Manifest conformance cases.
• Codex PR #24 merged at 40fa385b1bee274cb683cf1e0e9809f496031031 from head b0de1822e22c3cdac0f729e3fe3547b5937114db, adding Draft RFC 0012's proposed no-output failed-result representation. Exact-head CI #42 passed on Node 22/24. The PR reports no semantic tests; final version/schema ID, compatibility classification, normative adoption, runtime/consumer support and release remain undecided. Independent re-review confirmed the prior no-output validation finding fixed. This proposal does not satisfy O02's contract-owner decision.
• Post-merge Codex CI #40 and Platform CI #115 passed on Node 22 and 24.

These merges and CI establish technical draft/prototype progress. RFC 0010 remains Draft, and its proposed lifecycle/integrity semantics have not been adopted as a stable contract. The issue's reviewed-transition and contract-owner acceptance criteria remain pending; keep this issue open and its completion checklist unchecked.