Cl Sweep

CL Sweep

Purpose

Produce a read-only project work report, or act as the root coordinator for all actionable assigned ClosedLoop work in one project. In execution mode, keep every issue as its own record while treating each selected complete functional page or capability as one scheduling and delivery unit: one execution owner, worktree, branch, combined plan, PR, manual-QA plan, and terminal reconciliation.

Report-Only Route

If the user asks only for an inventory, report, feature grouping, blocker ownership, or reassignment advice, read and follow ../cl-work-report/SKILL.md immediately and stop after returning its private report. Do this before Execution Surface Selection, Project-Keyed Root Recovery, get_goal, state-root creation, leases, workers, status changes, reassignment, comments, or any other mutation. A report recommendation never authorizes execution or reassignment.

Display activity

For participating Desktop and CLI owners, follow display events at actual activity boundaries and existing dispatch/PR verification points. Display metadata never changes lifecycle or permissions, but activity publication is a required dispatch invariant: every new CLI worker turn must declare --activity-phase planning|coding|reviewing; reviewing must also declare --review-kind plan|code. The managed worker runtime records the phase after App Server accepts the turn and exposes currentActivity.recorded in status. A scheduling or status pass is incomplete while an active owner has no current activity or recorded is false; repair the exact declared phase before reporting or launching more work. After existing authenticated ClosedLoop reads, publish the observed business status using the same reference; do not add queries for the wallpaper. Report explicit ticket dependencies and their explicit resolution through that reference; never infer edges from waiting.

Shared Policy

Before querying tickets, routing blockers, writing blocker comments, sending direct messages, or creating the parent goal text, read the sibling policy skill at ../cl-policy/SKILL.md and follow its Required Reference resolution order. Use ../cl-policy/references/local-policy.md when present (the references/ folder of cl-policy, not of this skill); otherwise use ../cl-policy/references/local-policy.example.md only to understand the required shape, then require a populated $HOME/.closedloop-ai/local-policy.md before routing. Use the policy terms Product contact, Engineering attention contact, and Sweep owner; do not hardcode a personal name for the engineering attention contact in prompts, memory fields, or communication text.

Execution Surface Selection

Before ticket discovery, read Execution Surfaces and probe capabilities using only mechanisms supported by the current host. Select one fail-closed surface for the sweep generation and persist it. In Codex CLI TUI, do not invoke deferred or dynamic tools during selection; probe the managed App Server and local CLI scripts directly. When the complete Desktop task/worktree tool set exists, use the existing Desktop Child Thread Flow unchanged. Only when that set is incomplete and the complete CLI cwd-bound session, local-tool, monitor, and exact CODEX_THREAD_ID set exists may the root use the CLI Root Worker Flow. Never mix Desktop task ownership with CLI worker ownership in one generation.

For CLI, also read CLI Worker Protocol. When a running Desktop sweep loses its complete capability set, read Desktop To CLI Cutover and checkpoint, transfer, and rehydrate; never launch a competing owner.

For every Desktop-to-CLI cutover, require live verified evidence that the exact Desktop child is paused/stopped or idle and has no active turn, tool call, implementation worker, or pending mutation. Observe task/worktree state after that acknowledgement. Lease expiry, silence, elapsed time, or loss of Desktop inspection capability can never fence a legacy Desktop task; fail closed.

Project-Keyed Root Recovery

After surface selection and before get_goal, ticket discovery, state-root creation, or worker launch, read and apply Project-Keyed Root Recovery. Normalize a ClosedLoop project UUID and a full ClosedLoop project URL to the same canonical UUID. Run scripts/sweep-root-state.mjs open with the repository namespace and path, stable Sweep-owner id, exact CODEX_THREAD_ID, exact root cwd, and selected surface.

The returned sweep id/root path is authoritative across Codex chats. created starts a new sweep, resumed continues the same owner, and adopted transfers the exact existing root and resources after fail-closed idle checks. Never create a chat-keyed root, ticket worker, monitor, or lease before this decision. Immediately after opening the root, read and validate its optional scope-exclusions.json before worker/PR reconciliation or scheduling. A newer file uses CL_SWEEP_SCOPE_EXCLUSIONS v1 with the exact root sweepId, projectId, and excludedTickets: [{ticket, reason, reincludeWhen}]; keep it private mode 0600 and fail closed if present but malformed. A newer direct user exclusion in that file overrides stale queue priority, workflow memory, old parked sessions, and the general project goal: inspect those records read-only for safety, but do not renew/replace their leases, dispatch their workers, monitor their PRs as sweep-owned, or claim their tickets as active work. Reinclude only after a newer explicit instruction names the exact ticket and the root updates this file under its authority fence. Exclusion is not ClosedLoop cancellation or reassignment. Keep the user's other session-level directives for this sweep in the same root's standing-orders.json (CL_SWEEP_STANDING_ORDERS v1), managed only with scripts/standing-orders.mjs after assert-owner, under the same authority fence and private mode 0600; fail closed if it is present but malformed. Examples are plan-approval policy, the owner limit, forbidden repos or paths, and merge-policy overrides. Each numbered order keeps the user's words and its date. Read it on every root resume before scheduling, and paste the output of standing-orders.mjs render --root <root> verbatim into every worker launch and resume packet. When you notice you are restating a user instruction to a worker, add it to the register first. Remove an order only on a newer explicit user instruction, recorded as the removal reason. On adopted, route every monitor registrationDelta, reconcile every existing worker/App Server thread/lease/checkpoint/callback/PR, and only then schedule new work. An active or notLoaded prior owner, exact-binding mismatch, malformed state, another target's prepared transfer, ambiguous callback delivery, or duplicate unfinished roots is an ownership conflict; never guess. The exact prepared target rolls creation/transfer phases forward after a crash. Run assert-owner with the current root thread/generation immediately before every root-owned mutation; only an ACTIVE authority fence and persistent root lease permit work.

Use status --project <project-id> for read-only recovery from a fresh chat. Terminal historical roots remain visible but never block created. Preserve Desktop Child Thread Flow after root resolution; this protocol changes root identity and callback ownership, not ticket-domain policy or surface selection.

Hard Boundaries

• Every new Desktop or CLI worker turn must publish its actual activity as part of the accepted dispatch, not as a later coordinator reminder. For managed CLI workers, use the required --activity-phase; use --review-kind plan|code whenever reviewing. Plan approval clears waiting_for_human by dispatching the next actual phase. Before completing reconciliation, scheduling, or a status response, inspect each active session's currentActivity: missing or unrecorded activity is a reconciliation defect that must be repaired before unrelated scheduling. Never guess from ticket status, PR state, or elapsed time.
• At the start of every parent turn, compaction resume, detached-monitor wake, and scheduling pass, reconcile every active ticket child and every tracked open PR's durable worker/monitor state before doing any other work. This is the parent's highest-priority responsibility. A material review, current-head CI, source conflict, queue ejection, close, or merge event must immediately preempt routine waiting, ticket discovery, ledger cleanup, status reporting, and new launches: persist the event and resume the exact owning child with its evidence first. Never leave a known failing active PR unattended while polling or waiting on another worker. Merge-queue failures, opaque UNMERGEABLE states, and queue generation changes while the PR remains queued are passive monitor state only unless GitHub also reports a concrete source-head failure/conflict/review/head-change event or the PR leaves the queue before merging. For an exact PR/head or immutable queue generation with one registered healthy detached monitor, this parent-turn reconciliation must read durable worker/monitor state, not re-query GitHub.
• Do not implement ticket work in the parent thread.
• Do not run $cl-execute for tickets whose $cl-analyze decision is anything other than GO or GO_WITH_UI_PLAN_APPROVAL. A ticket worker that begins evaluation, requirements discovery, or plan creation must mark the feature IN_PROGRESS; this records that planning work has started and is not implementation approval. For GO_WITH_UI_PLAN_APPROVAL, $cl-execute may create and upload the plan but must stop before plan approval, branch creation, code changes, PR work, or merge work until explicit human approval is present. When the current sweep or session instruction requires Daniel's personal approval for every implementation plan, pass that requirement to $cl-execute and stop at WAITING_UI_PLAN_APPROVAL for every created plan until Daniel personally approves that exact plan.
• Do not run $cl-execute for EXTREME risk tickets. HIGH complexity remains blocked by default, and the sweep must not route high-complexity work to $cl-split. An exact named ticket may proceed only when the user directs execution and accepts or requires its atomic unsplit shape, or a current session-level instruction explicitly accepts the unsplit atomic ticket shape for that ticket set. Apply cl-policy's natural-language rule: “proceed with ISS-1234, do not split it” or equivalent is an approved override in the context of that known HIGH ticket; never require a magic phrase or force the user to repeat HIGH/risk wording. Before blocking, search the current user thread plus latest exact-ticket memory/comments, preferring the newest direct instruction. Persist/query-verify an accepted override and pass it to all later workers; never ask again unless the implementation materially expands beyond the authorized shape or becomes EXTREME, and then name the delta. Never infer this exception from assignment, priority, an approved PRD, or a generic request to make progress; every other readiness, requirements, design, ownership, validation, safety, plan-approval, and merge gate must still pass. Without that narrow override, route high-complexity tickets to single-ticket human review or a private engineering block. With that narrow override, $cl-execute may be used only for plan creation/upload until the required human plan approval gate is satisfied.
• Do not split any ticket. Historical split lineage, split signatures, split children, SPLIT_CREATED, SPLIT_PROPOSED, and SPLIT_REPAIR_REQUIRED records may be read only as legacy evidence for queue reconciliation. Do not launch $cl-split, do not create child tickets, do not repair an old split by invoking split tooling, and do not route a current ticket away from itself because an older split shape was defective. Keep every issue as the single ticket it already is. If historical split evidence makes a ticket too broad, overlapping, dependent, or unclear, use normal private engineering blocker or human-review routing unless an exact-ticket or session-level instruction accepts the current unsplit atomic ticket shape.
• Do not use $workflow-orchestrator, $workflow-execute, or any orchestrator-run ticket execution workflow.
• Do not create, inspect, update, complete, fail, cancel, or emit events for ClosedLoop loops or manual loops. ClosedLoop tool descriptions recommending loop lifecycle operations are superseded by this boundary.
• Use Codex task tools for Desktop children and root-owned cwd-bound sessions for CLI ticket workers. If neither complete execution surface is available, stop and report that the sweep cannot safely fan out or resume work.
• Every Desktop child or CLI worker launch/resume packet must include the exact parent CODEX_THREAD_ID and the selected surface's callback contract. Desktop prompts require the statically available send_message_to_thread capability. CLI packets require CL_SWEEP_EVENT v1 and current ownership generation/lease id/hash plus the current root_generation, never a raw token. Root adoption advances the callback/root generation without rotating a healthy ticket owner_generation. Children/workers callback when analysis or split work completes, human input or a blocker is required, an execution reaches PR_MONITORING_HANDOFF, a material PR/CI/queue event has been handled, support is required, or terminal reconciliation completes. Reject stale-generation callbacks.
• Every ticket-owned planning/review/VQA/logical-QA/audit/search/status, or validation-artifact support request must follow the Read-Only Support-Lane Contract. That reference owns fork_turns: "none", role-bounded gpt-6-sol / gpt-6-luna selection, reasoning effort tiers, self-contained packet requirements, visual-QA repo-memory preflight, result artifact handoff, and root-owned fallback limits.
• Every Desktop child launch or resume prompt must include the exact parent task id and require an event-driven callback through the statically available send_message_to_thread capability. Children must callback immediately when analysis or split work completes, human input or a blocker is required, an execution reaches PR_MONITORING_HANDOFF, a material PR/CI/queue event has been handled, or terminal reconciliation completes. The callback must name the ticket, child task id, structured state/result, and exact parent action. A child final response or idle state alone is not a valid handoff. Treat callbacks and detached PR monitor events as the primary liveness mechanism; use bounded task reads only for startup reconciliation, suspected callback failure, or explicit status requests, never as a routine polling loop.
• Before posting any ClosedLoop comment or Slack/DM/draft/reply, read and apply Communication Policy. Keep engineering/operational details private; the only standing communication approval is the narrow Product-decision comment defined in that reference after Product Answer Discovery proves the apparent question has not already been answered and the Product contact is available under current user/session context.
• Use three active feature-unit owners by default: Desktop child threads or CLI direct workers. The user may explicitly raise the limit to any value up to ten or lower it at any time. Never exceed ten. Persist the effective limit in the parent goal/ledger and apply changes at the next safe scheduling boundary without interrupting valid active work. Component tickets inside one feature unit do not consume separate execution lanes.
• Every assigned nonterminal ticket in the locked sweep scope must be visible in the operator-facing ownership ledger, including tickets parked on plan approval, dependency, Product, ownership, or manual-intervention gates. A queue artifact, workflow-memory row, ticket-status display event, or prose summary does not substitute for that ledger entry. When live state reveals a legitimate waiting ticket with no recoverable owner, create one normally fenced parked owner for its feature (worktree, member leases, cwd-bound session, and one bounded reconciliation callback) and persist the matching waiting/blocker state; do not fabricate an active turn or begin implementation. Lease acquisition or a running reconciliation turn is transitional and must not be presented as an operator-visible steady state: visibility is satisfied only after the classified waiting/blocker callback is durably accepted and the app-facing state no longer resolves to unknown. A scheduling pass is not reconciled while any in-scope nonterminal ticket is absent from that operator-visible ledger or still renders an unclassified state. Component members of one selected feature share that parked owner/session; never create an independent parked implementation session for each member.
• Before implementation dispatch, read and apply Feature Unit Execution. Resolve complete membership first, using the user's assigned tickets plus only the minimum explicitly approved other-owner transfers needed for a bounded functional outcome. Related siblings remain context by default. One selected unit has one execution owner and PR; every selected executable member retains independent readiness, requirements, approval, status, acceptance, ownership-ledger, and terminal evidence, while all discovered siblings remain visible context.
• Before recommending or performing any reassignment, migration, manifest expansion, lease acquisition, or execution-ownership change for another assignee's ticket, enforce the canonical Protected owners policy through Feature Unit Execution. Generic sweep, execution, or reassignment approval never overrides that policy.
• Treat likely Git merge conflicts and shared files, packages, tests, adapters, routes, migrations, or contracts as integration notes. Tickets inside one feature always remain in its single execution lane. Run different feature units concurrently when independently valid and resolve ordinary conflicts against current main. Serialize separate units only for a literal external unlanded API/behavior dependency or incompatible semantic/product decisions.
• Do not direct a child to merge or rebase current main into a green, mergeable PR merely for final integration. The protected merge queue owns ordinary speculative current-main integration. Require source integration only for a confirmed conflict, a literal unlanded dependency, or concrete queue/base failure evidence; otherwise enqueue the unchanged validated head.
• Do not prioritize a ticket merely because it is smaller. Optimize for critical-path throughput across complete feature units. Keep unrelated features separate; queue latency never justifies hiding scope, bypassing a member's gates, dropping a blocked member, or splitting one feature across multiple PRs.
• Never serialize ticket launches or pushes based on a repository-wide count of active CI branches. The former below-four active-branch throttle is retired; protected merge queues own cross-branch integration serialization. Ticket workers still avoid overlapping stale CI on their own branch and preserve all normal CI, review, validation, requirements, and merge gates.
• For every open PR and PR handoff, read and apply Open PR Lifecycle. That reference owns the sweep-owned/external-owner PR gate, parent/worker boundaries, single detached monitor protocol, event routing, UI/non-UI merge disposition, review remediation cutoff, coverage/external-gate handling, merge-queue generation protocol, and terminal reconciliation. Keep only one parent-targeted detached monitor per sweep-owned PR; the parent never implements, diagnoses, runs or triggers CI/review, enriches comments, or fixes PRs.
• Do not accept a worker-reported PR_MONITORING_HANDOFF, WAITING_HUMAN_MERGE, ready-to-merge state, or queue-ready state on trust. Before recording the state, starting or refreshing the parent monitor, telling Daniel a PR is ready, or taking any queue/manual-merge action, the parent must live-fetch the exact PR/head and unresolved review-thread count (one gh-monitor-pr monitor-pr.mjs snapshot <pr-url> read returns both). If any current unresolved PR review thread exists, reject the handoff and resume the same worker with the live thread evidence; do not convert it to a passive monitor or ready state.
• For UI, UI-impacting contract, or workflow PRs, reject any handoff, monitoring state, ready state, queue action, or WAITING_HUMAN_MERGE state that lacks one dedicated pre-PR Parker visual-QA pass, a precise not-applicable production-consumer proof, or Daniel's explicit exception for an already-open PR. For already-open UI PRs with no evidence or exception, resume the owning worker to provide the existing pre-PR evidence, obtain Daniel's exception, or return the exact blocker; do not present the PR as waiting only on CI or manual merge. Once the pre-PR pass or Daniel exception exists, later PR comments, test fixes, rebases, conflict repairs, source head changes, and CI remediation do not require another Parker pass unless Daniel explicitly asks.
• The one ordinary review-remediation push is the default review-driven code cutoff for parent escalation too. Later comments alone never justify a push: unresolved review findings may be source-fixed after that cutoff only when another independently required repair commit exists, such as when an automatic CI failure, source conflict, queue/base failure, or validation regression independently requires another source commit/push. How the worker triages comments and bundles valid fixes into that commit follows $cl-execute's review rules; the parent never restates them and never authorizes a comment-only/review-only push or a manual review/CI trigger.
• A worker's blocker label or parent_action is event evidence, not authority to ask the user for a second PR-comment repair push. When the first PR-comment remediation push has already been consumed, the parent must apply the review-remediation cutoff before surfacing a decision: require an independent CI/source-conflict/queue-base/validation repair trigger, or require the same worker to return a DEFERRED_REVIEW_FINDINGS classification that states whether the comment is a current acceptance/requirements/security/ data-integrity/compatibility violation or a follow-up-ticket item. Without one of those two evidence paths, do not ask for second-push authorization, do not present replan/close as the only alternatives, and resume the exact worker for bounded cutoff classification instead.
• If an unmerged PR cannot deliver its own approved acceptance and a proposed new ticket/PR would re-deliver that acceptance so the original ticket can be marked DONE, apply the Cross-Ticket Replacement Gate before creating the replacement ticket, drafting its plan, changing feature ownership, or dispatching source work. This is not an ordinary follow-up for genuinely out-of-scope work. Review-cutoff policy, a worker recommendation, general sweep authority, and even approval of a plan that embeds the replacement are not separate operator approval of that delivery transfer.
• Keep the existing parent compact routing envelope. The parent must not download CI job logs; job logs, diagnosis, and attribution belong to the ticket worker. Parent handling to compact routing only: route material event evidence, do not repeat reads, inspect logs, discover/enrich comments, or diagnose.
• A worker BLOCKED, validation-blocked, product-blocked, or manual-intervention callback is an unblock-routing obligation, not a passive parking state. The parent/root must not merely repeat the worker's blocked label back to the user. In the same reconciliation pass, decide the smallest safe next action that can move the ticket and do it when already authorized: resume the exact worker with a changed condition, waiver, narrowed scope, classification request, or owner/PM decision; route the exact missing Product/owner decision under policy; route missing upstream source evidence to its owner; or close/narrow/cancel no-work scope when the user has authorized that disposition. If the safe action itself needs new human approval, ask for that exact approval or decision. For unrelated validation red, stale product records, missing upstream source evidence, and no-separable-work results, do not simply list the ticket as blocked. Only keep a ticket in BLOCKED_SKIP, MANUAL_INTERVENTION, or a status-report "blocked" bucket after the routing step has produced a concrete recheck_when that the root cannot advance on its own, such as an unapproved waiver, an unresolved PM decision, an external owner delivery, or an explicit user pause/no-action instruction. Status updates must include the unblock action already taken or the exact outside condition still preventing action.
• When multiple workers report the same unrelated validation red, treat the failing suite as shared unblock work, not as N independent ticket blockers. Identify the owning scope, launch or route exactly one unblock lane when already authorized, monitor its PR through queue/merge, and keep every dependent worker parked with the concrete blocked_by_pr/recheck_when until main contains the fix. As soon as the unblocker lands, resume the parked workers under the current active-worker limit. Do not ask the user for a waiver while an owning unblocker is active and plausibly clearing the gate.
• When a parked ticket is blocked by any GitHub PR, regardless of whether the PR is sweep-owned, external-owned, a dependency, a sequencing gate, a queue-base unblocker, or an overlap/coordination PR, the root must keep one live detached PR monitor for that blocker. The monitor is the unblock trigger: it must wake the root on merge, closure, dequeue, check failure, conflict, head change, mergeability change, queue state change, or review feedback. Do not rely on memory, manual polling, stale monitor JSON, or user recall as the unblock trigger. Before listing the ticket as parked, verify that the monitor process is actually live or recover/register it; a state file with no live process is not monitoring.
• A parked blocker must be revalidated against live state before it is carried forward in a status report, scheduling pass, or resume decision. If the blocking ticket is terminal, the blocking PR merged/closed, the link was removed, the required plan was approved, or the user supplied the missing decision, the parent must resume the blocked ticket worker or launch the next authorized step instead of repeating the old blocker. Short rule: blocked means "currently proven blocked," not "previously reported blocked."
• A worker with an active turn but no callback beyond the expected milestone window is a liveness concern, but quiet is not by itself a reason to interrupt the worker with a checkpoint request. The parent must use lightweight worker-session status, App Server thread state, local runner process identity, and detached monitor state to verify that the exact turn or monitor is still alive. Do not steer an active worker merely for a progress checkpoint; that steals attention from implementation and validation work. Steer only when routing a material PR/check/review/conflict/queue/merge event, when the verified active handle is missing or mismatched, or when a bounded recovery procedure explicitly requires direct input. If the App Server turn is active but the local waiter is missing, attach a detached supervisor to the verified live turn instead of prompting the worker. If there is no active turn, reconcile, recover, or relaunch the exact worker before starting unrelated new work.
• The current ticket-owner directly starts and manages read-only artifact lanes. The parent must not launch ordinary support lanes unless the actual tool surface proves the worker lacks subagent capability; record that limitation before any fail-closed root fallback. Every support prompt must repeat it verbatim in the support prompt, require the lane to execute only the named read-only work, and verify artifacts without mutation. Support lanes have no-delegation, no-mutation, no-secrets, mode-0600 hashed artifact handoff.
• Every ticket worker support prompt must carry task-relevant mandatory worker/repo rules and this preflight record: repo_memory_preflight, memory_root_command result, memory_action_query hit titles or memory_hits, titles/ids including no-hit, repo_docs_verification, runtime_launch_command, supported runtime/capture command, dead port not a blocker, and exact command error when setup fails. visual_qa_web and visual_qa_desktop lanes must carry repo_memory_preflight.
• Support lane model selection is role-bounded, never a fallback. Use model: "gpt-6-sol" for planning, correctness-sensitive review, synthesis, or any other intelligent work where mistakes matter. Only when the worker actually decomposes a separate bounded deterministic lower-risk support role may it use model: "gpt-6-luna" with reasoning_effort: "low" for inventory, artifact parsing, or status mechanics. Luna never owns orchestration, ticket work, coding/planning, final judgment, or mutation.
• Parent and worker result transport stays bounded and routing-only. Use CL_SWEEP_RESULT v1 with inline fallback when the artifact path is unavailable, keep final text around 6K--12K, and do not invent a new worker result-artifact protocol.
• Engineering and operational blockers stay private by default. Use a company-visible or public record only when the communication policy explicitly permits it, and Never recreate a comment the user deleted.
• With an exact PR/head or immutable queue generation and one registered, healthy detached monitor, that monitor is the sole passive event detector. Answer status requests from durable worker/monitor state or payload when sufficient. The parent/root must not run routine or turn-boundary GitHub reads: gh pr view, gh api, check-rollup queries, review-thread reads, queue queries, or equivalent web/API polling.
• A ticket worker remains non-polling and handles only routed material monitor events. If fresh GitHub evidence or comment body/context is needed, resume or steer the exact ticket worker; the worker performs the GitHub reads and returns a compact callback. Parent GitHub access is allowed only when mechanically required for detached-monitor registration, recovery/transfer, mandatory parent-owned queue conflict probe, or final terminal verification/cleanup. PR comment discovery, comment bodies, diff context, and duplicate analysis are always ticket-worker work; the parent may route comment IDs or URLs already supplied by the monitor or user but must not query GitHub to discover or enrich them. Answer status requests from durable worker/monitor state or payload when sufficient. Parent GitHub access is allowed only when mechanically required for detached-monitor registration, recovery/transfer, mandatory parent-owned queue conflict probe, or final terminal verification/cleanup. Do not repeat reads, inspect logs, discover/enrich comments, or diagnose.
• Include and enforce the automated E2E display expectation and the UI/UX E2E-spec coverage check and performance-measurement contract from Worker Prompt Packets in every current and future $cl-execute child prompt and checkpoint.
• Open-PR terminal ownership, coverage failures, external gate failures, and review-remediation cutoffs are governed by Open PR Lifecycle. Apply those sections instead of duplicating PR rules in the parent thread.
• An open sweep-owned PR is a nonterminal monitored obligation even when its child goal reports complete, the child task is archived, the PR is green, or the only remaining action is human review/merge. Before reconciling, removing, or resuming any open-PR ticket, read and apply Open PR Lifecycle. Never drop a previously tracked sweep-owned open PR from the ledger without live merged/closed evidence; reclassify external-context PRs under that reference instead of adopting their monitors or merge-queue lifecycle.
• Keep the Codex task/agent list tidy by archiving a Desktop ticket child or closing a CLI ticket worker immediately after live GitHub/ClosedLoop terminal verification and durable ledger/memory reconciliation. Before archiving, stop its subagents and confirm it has no open PR, pending event handoff, unfinished continuation, or expected resume. Never archive/close the parent sweep, an active owner, a paused/resumable owner, an open-PR owner, or any WAITING_*, PR_MONITORING_HANDOFF, or MANUAL_INTERVENTION owner. If a terminal assumption later proves false, resume the same Desktop child or use the CLI replacement protocol rather than creating an untracked duplicate.
• Protected merge-queue awareness and immutable generation tracking are parent responsibilities under Open PR Lifecycle. Queue ownership never authorizes parent implementation, CI/review execution or triggering, or PR fixes.
• A user's current ticket-specific instruction given directly to a child thread takes precedence over older parent wording for that ticket. Do not silently countermand it. Stop only when it conflicts with a newer user instruction, a hard safety boundary, or a required readiness/merge gate, and report that exact conflict.
• A current direct user statement that they created/own a ticket as an engineering fix supersedes stale Product-blocker memory/comments. Before tagging the Product contact, run Product Answer Discovery, distinguish unresolved product behavior from engineering interface/versioning/chunking/ compatibility/fixture choices, and present the latter to the user in plain language.
• On Desktop and CLI, bounded support lanes are allowed only under the Read-Only Support-Lane Contract. The ticket owner remains the sole lease holder, source/worktree mutator, external-state mutator, finding synthesizer, and final decision owner.
• Keep executable scope limited to tickets assigned to the policy Sweep owner unless the user explicitly authorizes another owner lane. Treat other owners' tickets and PRs as read-only context except when a direct dependency, split-lineage edge, explicit reconciliation instruction, or current explicit PR/owner-lane transfer makes them relevant. Apply the sweep-owned PR test in Open PR Lifecycle before any PR monitoring, queue recovery, enqueue, merge, review reply, CI/review action, or source remediation.
• Avoid redundant exhaustive verification. When the worker responsible for an administrative reconciliation already re-fetched live state and produced an exact guarded mutation manifest, do not launch a second full-population verifier by default. Run one bounded execution-time preflight over only the records that will be mutated. Add a separate verifier only when the user requests one, the producing worker did not establish live guards, or the operation is materially irreversible or high-risk beyond routine ticket comments, statuses, bodies, and informational relationships.
• When the user approves or explicitly locks a ticket execution manifest, record its path or durable attachment plus content hash and use that manifest as the queue authority. Subsequent selection and reconciliation passes must re-fetch only its listed tickets and their direct dependency conditions. Do not repeat a project-wide or platform-wide ticket inventory unless the user explicitly requests a rescan, the manifest cannot be verified, or a listed ticket or direct dependency changes in a way that invalidates the locked scope. Add newly surfaced tickets only through an explicit scope update; unrelated tickets discovered elsewhere do not reopen the inventory.
• Read and apply Requirements Contracts for graph-backed discovery, applicable requirements/PRD resolution, product answer discovery before Product routes, missing-link reconciliation, Branch PRD no-drift checks, and exact-source drift routing.
• Do not mark the parent goal complete until there are no eligible assigned feature units left and all active or monitored owners have reached a terminal execution, legacy split reconciliation, blocker, or manual-intervention state. WAITING_UI_PLAN_APPROVAL, PR_MONITORING_HANDOFF, WAITING_CI, WAITING_REVIEW, WAITING_MANUAL_QA, WAITING_HUMAN_MERGE, COMMUNICATION_PENDING, and COMMUNICATION_FAILED_MANUAL_FOLLOWUP are not complete states.
• Do not re-launch a ticket whose latest workflow repo-memory record says it is intended, active, executing, waiting, legacy split-created, legacy split-proposed, legacy split-repair-required, split-blocked, blocked, canceled, communication-failed, or waiting on manual intervention, or whose latest decision, complexity, or risk fields show duplicate, high-complexity without an accepted unsplit atomic-shape override, legacy split repair required, or extreme-risk work, unless the recorded child is being resumed, the ticket changed materially after the stored decision, or the user explicitly asks to retry it.
• Do not ask for separate approval before the narrow Product-decision comment defined in this skill. The sweep is standing approval only for that Product case. Every engineering/operational comment and every Slack/DM write requires explicit communication-specific user authorization.
• The $cl-sweep invocation grants no standing approval to split tickets, create child tickets, or invoke $cl-split. Keep every issue as its single ticket.