Run an hourly deterministic development watchdog before dispatching CoS agents

Open
#7,819 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript

Research direction

Start with the existing detectors and workflows in server/services/perpetualWork.js, server/services/issueReconcile.js, and server/services/prWatcher.js, then review the dependency on #7818. Trace how scheduled, wake, and manual dispatch currently share ownership and merge gates. Done means the listed zero-inference, concurrency, recovery, pagination, and public-boundary test cases are covered without duplicating existing workflows.

Written by the indexing model from the issue text.

Description

blocked effort:high enhancement model:heavy plan

Problem and evidence

Existing building blocks are fragmented: server/services/perpetualWork.js:257,841 detect claimable work; server/services/issueReconcile.js:572,636,678 gather ownership and release abandoned claims; server/services/prWatcher.js:329,458 already handle pending merges without an agent. PR discovery at prWatcher.js:499-585 uses changed activity and a first-run baseline, which is not a complete invariant that every open PR has an accountable state. Merely enabling a watcher does not establish hourly maintenance or active-agent ownership.

Chosen approach

Register an opt-in programmatic scheduled task with a configurable hourly default and Run Now/dry-run. Reuse existing detectors, reconciliation and merge gates instead of writing another issue selector or merge implementation. Produce one structured snapshot/receipt with source freshness and completeness, available slots, eligible backlog, all open PR dispositions and work decisions. Classify PRs as actively owned, queued for resolution, waiting for CI/review, draft, blocked with reason, untrusted/excluded, or unknown. Revisit old unchanged PRs as well as newly observed activity.

Use the same ownership decision for queued/running/finalizing agents, external claim evidence and reachable peers. Unknown or unavailable peer/forge state is not proof that work is abandoned. Acquire durable per-repository/work-item dispatch ownership shared with existing schedulers and wake requests; revalidate immediately before queueing or merging. Include head SHA in review/merge state, and do not respawn repeatedly for unchanged failed/blocked evidence.

Acceptance criteria

  • Empty, already-owned, pending-CI and unchanged-blocked scans use zero LLM calls and spawn zero agents.
  • Eligible unclaimed work with capacity queues the existing claim workflow; honor labels, dependency state, active claims, cooldowns, provider budgets and project/global capacity.
  • An eligible orphan PR uses the existing resolve/review/merge workflow; deterministic merge is allowed only under existing explicit merge authority and current-head full review/CI gates. Never turn an arbitrary orphan PR into merge-only work.
  • Concurrent hourly/wake/manual scans and process restarts do not duplicate tasks or steal live claims; partial pagination, auth failures and unreachable peers report unknown and defer mutation.
  • Persist bounded decision receipts and explicit blockers; normal lifecycle outcomes use Brain/actionable status, reserving notifications for user decisions.
  • Public-boundary tests cover scan-to-dispatch, competing scans, restart recovery, changed heads, blocked dependency PRs, partial reads, disable and no-op zero-inference behavior.

Dispatch: heavy capability for cross-scheduler races and ownership; high effort for recovery and integration contracts.

Blocked by #7818

Planning scope: issue-only investigation; no implementation or instance configuration was changed. Public examples must be synthetic; do not publish live prompts, transcripts, machine identity, or personal records.

Dominant language
JavaScript
Stars
38
Forks
32
Avg merge
50m
Merged PRs (30d)
985

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from atomantic/PortOS

All issues in atomantic/PortOS

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.