# Human-Mediated Orchestration Lane Operating Packet V01 Issue: [#366](https://github.com/pinklon/ai-capability-discipline/issues/366) References: - [#364 Add exported-issue planner integration report v01](https://github.com/pinklon/ai-capability-discipline/issues/364) - [PR #365 Add exported-issue planner integration report v01](https://github.com/pinklon/ai-capability-discipline/pull/365) - [#362 Add live read-only GitHub issue export to committed planner fixture v01](https://github.com/pinklon/ai-capability-discipline/issues/362) - [#360 Add GitHub issue-body work payload template v01](https://github.com/pinklon/ai-capability-discipline/issues/360) - [#358 Add read-only queue planner and parallelism report v01](https://github.com/pinklon/ai-capability-discipline/issues/358) - [#356 GitHub Issues queue-backed agent work engine MVP](https://github.com/pinklon/ai-capability-discipline/issues/356) - [#287 Queue-backed multi-agent work engine evaluation](https://github.com/pinklon/ai-capability-discipline/issues/287) - [#277 Backlog triage dependency and supersession workflow](https://github.com/pinklon/ai-capability-discipline/issues/277) ## Purpose This operating packet tells Tony and Codex how to use the GitHub Issues queue planner lanes safely for human-mediated repo orchestration. It converts the orchestration stack into a manual operating workflow that can interpret planner reports, decide which work may proceed, and preserve issue, branch, validation, and closeout discipline. The packet connects: - the work engine MVP from PR #357 - the read-only queue planner from PR #359 - the issue-body work payload template from PR #361 - the read-only GitHub issue export fixture from PR #363 - the exported-issue planner integration report from PR #365 ## Non-Autonomous Boundary This packet is not autonomous execution. It does not create a worker loop. It does not create polling, scheduled execution, webhook-triggered execution, external queue infrastructure, Linear integration, Jira integration, a custom database, or MCP server behavior. Planner output does not trigger implementation. A planner lane is evidence for a human decision, not permission for an agent or worker to start work. Packet logic must not mutate live GitHub issues or PRs. It must not mutate labels, milestones, assignees, comments, issue state, PR state, branch state, or merge state. This packet must not mutate source registries, Preview source sets, Production source sets, Cloudflare configuration, Cloudflare Access/WAF, provider/model configuration, runtime retrieval semantics, browser-side provider calls, browser-side current-source retrieval, or package authority. ## Inputs The operator may use these inputs: - the exported planner report from `scripts/github_issues_exported_planner_report.py` - the committed exported issue fixture `validation/fixtures/github_issues_exported_planner_fixture_v01.json` - the queue planner fixture and report semantics from `github_issues_queue_planner_v01.md` - issue-body work payload fields from `github_issues_work_payload_template_v01.md` - work engine state, claim, lock, lease, validation, and closeout concepts from `github_issues_agent_work_engine_mvp_v01.md` - live GitHub issue or PR inspection performed manually by Tony or Codex during normal repo ceremony The packet itself does not require live GitHub access for validation. ## Required Planner Report Source The required report source is the exported-issue planner integration report pattern from PR #365. A human operator starts from the report's serial lane, safe-parallel lane, blocked lane, owner-decision lane, high-risk gated lane, rejected-before-planning records, validation requirements, closeout requirements, source issue metadata, and non-mutation confirmations. The report is advisory. It must be re-read against current repo state before any branch or child issue is opened. ## Lane Meanings The serial lane means the item has ordering, shared generated artifact, shared file, stale claim, or sequencing risk that requires one-at-a-time handling. The safe-parallel lane means the item may be eligible for a separate child ticket when file scope, branch scope, dependencies, labels, validation contract, closeout requirements, and claim evidence do not collide with active work. The blocked lane means the item cannot proceed until a named dependency, open PR, missing artifact, or required closeout condition is resolved. The owner-decision lane means Tony must make or record a decision before work starts. The required output is owner decision evidence, not implementation. The high-risk gated lane means the item touches a protected or high-risk boundary and requires explicit owner approval plus a separate high-risk ticket before any implementation. Rejected-before-planning records never enter lane handling. They require repair, clarification, or rejection before planning can be trusted. ## How To Handle Serial Lane Serial lane work must be handled one item at a time. Before starting, Codex must verify the active branch, worktree status, relevant open PRs, and any files or generated artifacts named by the payload. If serial work touches generated artifacts, context-pack mirrors, validation receipts, source registry artifacts, source-set posture, release artifacts, or closeout semantics, the operator must finish and close the current serial item before starting the next serial item. Serial lane output may become a child ticket only after the operator confirms the ordered prerequisite, branch name, file scope, validation commands, and closeout receipt requirements. ## How To Handle Safe-Parallel Lane Safe-parallel lane work may proceed only through a separate child ticket and a separate branch. The operator must confirm that touched files or domains do not overlap with active branches, open PRs, current uncommitted work, or protected generated artifacts. A safe-parallel candidate is approved for work only when: - required labels are present on the child issue at creation - the payload includes validation commands - the payload includes closeout receipt requirements - no dependency is open or ambiguous - no branch, file, generated artifact, source registry, source-set, Cloudflare, provider/model, runtime retrieval, browser-side retrieval, or package-authority collision exists - no owner decision is pending If any evidence is stale, missing, or unclear, the candidate stops and moves to owner clarification. ## How To Handle Blocked Lane Blocked lane work must not start. The operator records the blocking dependency, the evidence source, and the condition required to unblock. If the blocker is an open PR, unresolved issue, missing validation receipt, missing generated artifact, or unclear closeout state, Codex stops at the blocker and does not create implementation work from the blocked item. The only allowed next step is a human-mediated dependency resolution ticket or owner clarification, when Tony explicitly asks for it. ## How To Handle Owner-Decision Lane Owner-decision lane work requires Tony's explicit decision before any child implementation ticket, branch, or file edit. The decision record must include: - the question Tony answered - the selected option or instruction - the date of the decision - the issue, PR, receipt, or chat evidence where the decision was captured - the boundaries Tony preserved or changed If the decision changes hard boundaries, Codex must stop and produce a revised plan before implementation. ## How To Handle High-Risk Gated Lane High-risk gated work requires explicit owner approval and a separate high-risk ticket. The gate is not satisfied by planner lane membership, issue labels, or an inferred relationship to a completed parent. High-risk examples include source registry mutation, Preview source-set mutation, Production source-set mutation, Cloudflare changes, provider/model changes, runtime retrieval changes, browser-side retrieval, package authority changes, protected release artifact changes, and issue/PR closeout semantic changes. Until Tony approves a high-risk ticket, Codex must not create a branch or edit files for the high-risk item. ## How To Handle Rejected-Before-Planning Records Rejected-before-planning records cannot start work. They are not safe, serial, blocked, owner-decision, or high-risk candidates until their payload defects are repaired and re-exported. Rejected records require one of these outcomes: - repair the source issue payload through a separate owner-approved issue update path - ask Tony for clarification when the intended work is unclear - leave the record rejected and document the reason in the closeout receipt Rejected records must not be silently converted into child issues. ## How To Prevent Duplicate Work Before creating a child issue, Codex must inspect existing open and closed issues and PRs for the same title, objective, parent issue, allowed files, branch name, and validation contract. If a duplicate candidate exists, Codex stops and reports the existing issue or PR. If the duplicate state is ambiguous, Codex uses `owner clarification required` and does not create a new issue. Duplicate prevention is required even when the planner marks an item safe-parallel. ## How To Prevent Branch/File Collision Before starting a ticket, Codex must verify: - local branch name - local HEAD - clean worktree - open PRs that touch the same files - active branches that may touch the same files - generated artifacts affected by the planned files - source registry, source-set, release, or package-authority surfaces in scope If branch or file collision exists, the work must stop. The operator can resolve the collision only through an explicit owner decision or by waiting for the colliding work to close. ## How To Use Claim/Lease Evidence Manually Claim and lease evidence is manual evidence, not an automatic lock. A claim is useful only when the operator can point to a current issue, branch, PR, timestamp, actor, and expected expiration or closeout condition. Codex must treat stale, unclear, expired, or conflicting claim evidence as a stop condition. It must not infer that a stale lease is free to take without owner confirmation or deterministic repo evidence. When a claim is current and clear, Codex records it in the child issue or PR body and preserves it in the closeout receipt. ## How To Start A Codex Ticket From A Safe Lane To start a Codex ticket from a safe lane, Codex must: 1. Confirm the planner report item is in the safe-parallel lane. 2. Confirm the item was not rejected before planning. 3. Confirm no duplicate issue or PR exists. 4. Confirm no branch or file collision exists. 5. Confirm required labels exist and will be present at issue creation. 6. Confirm validation commands and closeout receipt requirements are present. 7. Create one child issue for the bounded work. 8. Create one branch from a synced `main`. 9. Implement only the declared scope. 10. Run validation and preserve closeout receipts. If any step is unclear, Codex stops before mutation and asks for owner clarification. ## How To Stop When A Gate Is Unclear When a gate is unclear, Codex must stop and report `owner clarification required`. Unclear gates include missing validation commands, missing closeout receipt requirements, ambiguous owner decision, duplicate candidate, branch collision, file collision, stale claim, protected issue state, high-risk boundary, source registry impact, source-set impact, Cloudflare impact, provider/model impact, runtime retrieval impact, browser-side retrieval impact, package-authority impact, or issue/PR closeout semantic impact. Stopping is the correct result. Codex must not fill gaps by assumption. ## How To Document Owner Decisions Owner decisions must be documented in the relevant issue, PR, validation receipt, or architecture packet. The record must distinguish between: - owner approval to plan - owner approval to create a child issue - owner approval to edit repo files - owner approval to cross a high-risk gate - owner approval to merge or close An owner decision does not carry across gates unless it says so explicitly. ## How To Preserve Closeout Receipts Every ticket started from a planner lane must preserve closeout receipts. At minimum, the closeout receipt records issue URL, PR URL, branch name, commit SHA, validation results, generated artifact status, final residue scan, boundary confirmations, related issue states, and whether label repair was needed. If generated artifacts are touched, context-pack and mirror validation must be included. If the known local static-server bind restriction appears during full validation, the privileged rerun result must be recorded clearly. ## What Must Remain Manual Owner Approval Manual owner approval remains required for: - high-risk gated work - owner-decision lane work - reopening or reclassifying protected closed issues - changing issue or PR closeout semantics - source registry mutation - Preview source-set mutation - Production source-set mutation - enabling, disabling, retiring, promoting, or applying sources - Cloudflare CLI/API use - Cloudflare Access/WAF changes - provider/model configuration changes - runtime retrieval semantic changes - browser-side provider or current-source retrieval - package-authority changes - OKF implementation - Google SDLC implementation - autonomous worker design ## What Must Never Be Delegated To An Autonomous Worker Yet No autonomous worker may yet decide lane eligibility, create issues, create branches, edit files, run validation from planner output, mutate GitHub state, mutate labels, mutate source registries, mutate source sets, use Cloudflare, change provider/model configuration, change runtime retrieval, change package authority, merge PRs, close issues, or interpret owner approvals. A future controlled worker would require a separate owner-approved issue, explicit identity and permission model, dry-run mode, mutation authority, transition validation, claim and lease renewal behavior, failure handling, review gates, closeout semantics, rollback evidence, and receipts. Until that separate work exists, Tony and Codex remain the human-mediated orchestration control plane.