Low frequency thread monitor

低频巡检 Skill

Purpose

Monitor a background Codex thread with minimal reads, no interruption, and low wasted waiting time.

This skill is monitoring only. It does not authorize writes, approvals, closure, gate unblocks, active promotion, or PROJECT_B consume/display changes.

Use it for ordinary non-Goal controller windows that still need to keep background work moving. It complements Goal mode; it does not replace durable Goal workflows.

State Model

Keep these states separate:

• Foreground monitor state: the controller is active, waiting, checking, absorbing, blocked, or done.
• Background worker state: the worker is running, finalizing, completed, failed, blocked, or asking Owner.
• Governance state: self-report, review, absorption, approval, and routing are separate steps.

Pending next check means the monitor is still active, even if no foreground text is being generated.

Hard Rules

1. If the target thread is still running and a next check is scheduled, the monitor is still active. Do not send a final answer that closes, archives, marks complete, abandons, or replaces the monitoring window.
2. Use a wakeup, automation, timer, or thread-continuation mechanism for the next check when available. If unavailable, say that limitation and the exact next check time, but do not claim monitoring is complete.
3. Do not nudge or steer a running thread with messages like "continue", "hurry", "are you done", or "report progress".
4. Read only recent status while monitoring. Use turnLimit: 2 or 3 and includeOutputs: false by default.
5. Use includeOutputs: true only for failure diagnosis, a small cited final output, or an explicit Owner request.
6. Stop polling only when a final report, failure, blocker, handoff, or Owner-input request is visible.
7. After completion, read the final report seriously, then check named artifacts and governing fact files only as needed before recommending the next allowed action.

If you dispatch the worker yourself, ask it for one final completion/failure report. Do not ask it to send routine progress updates unless the task boundary requires them.

Non-Interruption

Do not message the worker while it is reading, writing, reviewing, researching, self-checking, or producing a final report.

Send a follow-up only when:

• The Owner changes the task boundary.
• The worker is about to violate a hard boundary.
• The worker asks for Owner input.
• The worker reports a blocker/failure needing bounded clarification.
• The final report is complete and the next authorized step requires a new prompt.

Completion Test

Terminal states:

• Final report matching the requested output shape.
• Clear completed status plus final answer.
• Clear failure or blocker report.
• Clear handoff saying the thread cannot proceed.
• Owner-input request.

Not terminal:

• "正在执行", "继续读取", "正在核查", "还在跑", "我会继续".
• Tool progress without a final report.
• Partial checklist or draft status.

Timing Goal

Minimize expected wasted waiting time:

wasted_wait = next_monitor_read_time - worker_completion_time, when the worker finishes before the next read

Do not use a fixed rule like "always wait at least 5 minutes". Choose the next read from task size, elapsed time, latest status, and estimated remaining time.

If only 1-2 minutes likely remain, check in 1-2 minutes. Do not round up to a generic 8-10 minute interval.

Timing Table

Latest evidence	Next check
Final report, failure, blocker, or Owner-input request visible	Immediately read/absorb; stop polling
Finalizing, final self-check, preparing final report, writing summary, "马上/快完成/最后核查"	1-3 minutes
Very small task, elapsed time already near expected finish	60-120 seconds
New quick handoff/status/readonly confirmation	90 seconds-3 minutes
Small planning or small file review, no near-finish signal	3-5 minutes
Normal file review, bounded write, or self-check in middle work	4-7 minutes
Long review/research/source gathering/platform rules/video/audio/many files in middle work	8-15 minutes
Repeated long-running work with clear progress and no near-finish signal	15-30 minutes
Idle with no final report	2-4 minutes once, then light diagnostic read
Owner asks for status	Read once immediately, then reschedule from this table

Normally avoid intervals under 60 seconds. Do not poll every few seconds merely to see whether the thread is active.

Near-finish override: when the latest status implies final packaging, final answer writing, or short self-check, the next check is 1-3 minutes. Scheduling 8-10 minutes in this state is a monitoring error.

Adaptive Rule

Classify the task:

• quick_readonly: handoff confirmation, small status check.
• file_review: readonly review over local files.
• bounded_write: limited write plus self-check.
• absorption: Control Hub or Knowledge Hub registration/absorption.
• planning: route planning, schema planning, strategic design.
• research: web/platform/source research.
• media_learning: video/audio download, transcription, learning-card work.
• long_review: complete-chain review, large audit.

Use known or estimated P25/P50/P80 completion milestones when available.

When still running at elapsed time t:

1. If latest status is near-finish, ignore class defaults and check in 1-3 minutes.
2. If t is before P25, schedule near P25, respecting the minimum gap.
3. If t is between P25 and P50, schedule near P50 or in 2-5 minutes, whichever is sooner.
4. If t is between P50 and P80, schedule near P80 or in 3-7 minutes, whichever is sooner.
5. If t is past P80 but progress is normal, widen the interval in proportion to task size.
6. If progress appears stopped or idle without final report, do one light diagnostic read.

If uncertain, use:

next_interval = clamp(estimated_remaining_time / 2, minimum_gap, maximum_gap)

Suggested clamps:

Situation	Minimum	Maximum
Near-finish	60 seconds	3 minutes
Quick/small task	90 seconds	5 minutes
Normal review/write	2 minutes	7 minutes
Long research/review	5 minutes	15 minutes
Repeated long progress	10 minutes	30 minutes

Evidence Scope

Before terminal state: read only enough to determine running / completed / failed / blocked / asks Owner.

After terminal state, read in this order:

1. Latest 1-3 turns or thread status.
2. Final answer/report.
3. Artifact paths named in the report.
4. Actual artifact files if needed.
5. Governing fact files if routing, gates, or permissions depend on them.
6. Older transcript only if the final report is missing, vague, or contradictory.

Avoid whole legacy transcripts, long tool outputs, and worker reasoning history.

Status Format

While still running, use interim wording, not a final completion answer:

低频巡检中，不是最终结论。
目标窗口还在执行。
下一次巡检：约 HH:MM。
当前动作：等待，不打断窗口。

If environment cannot keep the monitor alive:

目标窗口还在执行。当前环境无法自动保持巡检窗口活跃；建议下一次巡检时间：HH:MM。监控未完成。

After terminal state:

我低频读了一次窗口。当前状态是：已完成 / 已阻塞 / 失败 / 等 Owner。
现在能确认：...
还不能确认：...
下一步建议：...

Control Hub / Knowledge Hub Safeguards

• Worker self-report is not approval.
• Review pass is not automatic authorization.
• Absorption record is separate from work result.
• Candidate, active, display, and consume states must not be merged.
• Next action must come from the current fact source, not chat memory.