investigate: Jules scheduled tasks — what fits, and how Muse manages the schedule #2020

Activity

1. developing-today commented on Oct 29, 2026

   

   developing-todayBot

   on Oct 29, 2026 – with developing.today

   Contributor

   More actions

   CODE-941
2. dezren39 commented on Oct 29, 2026

   

   dezren39

   on Oct 29, 2026

   MemberAuthor

   More actions

   Parent epic: #2055 — fleet expansion & placement program (2026-10-28 directive).
3. github-actions

   assigned

   dezren39

   on Oct 29, 2026
4. dezren39

   added

   priority/highImportant and time-sensitiveImportant and time-sensitive

   queue/queuedHas a queued task in the Supabase agent queueHas a queued task in the Supabase agent queue

   on Oct 29, 2026
5. dezren39 commented on Oct 29, 2026

   

   dezren39

   on Oct 29, 2026

   MemberAuthor

   More actions

   Top priority — ID program wave-1. Drew directed this be picked up in the next runs (2026-10-29): enqueued directly as triage task 3339 in repo-health-code-pilot at queue priority 20 (only breakage-class work at priority 10 outranks it). Wave-1 is the ungated investigations and designs; syntheses and PoCs stay gated on their named inputs. Investigation route: Workhorse.
6. dezren39

   added

   work/assignedQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

   and removed

   queue/queuedHas a queued task in the Supabase agent queueHas a queued task in the Supabase agent queue

   on Oct 29, 2026
7. dezren39 commented on Oct 29, 2026

   

   dezren39

   on Oct 29, 2026

   MemberAuthor

   More actions

   agent-note:v1 — picked up
   Agent: repo-worker-code (openchamber scheduled lane)
   Task: repo-health-code-pilot task 3339 (triage, priority 20)
   Started: 2026-10-29T10:20Z
   Plan: verify premise against current fleet reality, then produce the asked-for fit matrix (Jules scheduled-task shapes vs. the one ~100 actions/day account) plus a proposed first Jules schedule and the Muse-side management design (create/adjust/retire alongside the OpenCode and Muse schedules). Deliverable as a doc under doc/ linked from here, with follow-on issues for anything buildable.
   Not blocked; no competing PR found for this issue.
8. dezren39 commented on Oct 29, 2026

   

   dezren39

   on Oct 29, 2026

   MemberAuthor

   More actions

   🤖 Agent note · picked up

   • Agent: queue worker (repo-worker-code), lane C
   • Session / ID: queue task 3339 (attempt 2)
   • Found via: queue claim — the 10:20Z pickup by the openchamber scheduled lane left no further activity and its queue lease expired; the queue re-claimed the task atomically to this lane at 11:11Z. If that lane resurfaces: this lane holds the task now; stand down on investigate: Jules scheduled tasks — what fits, and how Muse manages the schedule #2020.
   • Task: Investigation for investigate: Jules scheduled tasks — what fits, and how Muse manages the schedule #2020 — Jules scheduled tasks: fit matrix (which task shapes fit Jules' scheduled mode), limits on the one collected Jules account (~100 actions/day per the issue), and how Muse manages the schedule alongside the OpenCode and Muse schedules. Deliverable: fit matrix + proposed first Jules schedule.
   • Expectation: effort class m — done = investigation recorded on this issue with fit matrix + proposed first schedule, follow-on routed.
   • Links: queue task 3339
9. dezren39 commented on Oct 29, 2026

   

   dezren39

   on Oct 29, 2026

   MemberAuthor

   More actions

   Investigation result — Jules scheduled tasks (#2020, queue task 3339)

   Process note: this task's first claim (10:20Z, openchamber scheduled lane) expired without an outcome; this lane re-claimed it atomically at 11:11Z (attempt 2) and produced the result below. Sources for Jules product facts: Google announcement coverage and current Jules documentation summaries gathered 2026-10-29 — Jules is a fast-moving Google Labs product and its API is explicitly v1alpha, so product specifics below should be re-verified at implementation time; the fit judgements do not depend on exact numbers.

   What Jules scheduled tasks are (verified shape)

   • Scheduled Tasks are recurring Jules runs (daily / weekly / monthly cadences) defined once and executed unattended in Jules' cloud: each run clones the repo into a fresh cloud VM, plans, edits, tests with the VM's standard toolchains, and opens a PR. Schedules can be edited, paused, and resumed (a January 2026 update replaced delete-and-recreate). Creation/management is a web-UI feature; the REST API (v1alpha) and Jules Tools CLI create and monitor sessions (ad-hoc runs) and can pull diffs/activities — schedule CRUD via API is not something the sources establish, so the management design below assumes UI for schedule CRUD and API/CLI for monitoring.
   • The account math: plan tiers are Free = 15 tasks per rolling 24h / 3 concurrent; Pro (Google AI Pro) = 100 tasks/day / 15 concurrent; Ultra = 300/day / 60 concurrent. The fleet's ONE collected account at "~100 actions/day" (per this issue) is consistent with the Pro tier — and that budget is shared across everything the account does: scheduled runs, ad-hoc sessions, Suggested Tasks, and CI-Fixer retries on Jules' own PRs. Paid tiers currently require an individual @gmail.com account (no Workspace), which is presumably why the fleet has exactly one.
   • Adjacent features that interact with any schedule: CI Fixer (Jules automatically attempts fixes when checks fail on its own PRs — helpful, but each attempt spends the same daily budget), and Suggested Tasks (Pro/Ultra, up to 5 repos, scans for TODOs and proposes work for approval — a suggestion inbox, not a schedule).

   Fit matrix — what belongs on Jules schedules, and what never does

   Task shape	Fit	Why
   GitHub Actions version bumps; dependency updates in mainstream stacks (npm/pip/go modules with public registries)	✅ Best fit	Self-contained in one repo, mechanically verifiable, PR-shaped, exactly the vendor's headline use case
   Lint/format/dead-code sweeps, TODO-comment cleanups (bounded: "at most N, smallest first")	✅ Fit	Low judgement, diff-reviewable, failure is cheap
   Docs-drift fixes (README vs actual scripts/commands)	✅ Fit	Read-heavy, small diffs, no secrets
   Test-writing for existing, well-specified behaviour; small bugfixes from a fully-specified issue	✅ Fit (ad-hoc more than scheduled)	Jules' core loop; keep prompts/issues precise — it cannot ask the fleet questions mid-run and get fleet answers
   CI failure first response on Jules' own PRs	✅ Built-in (CI Fixer)	Budget the retries; cap attempts so a flaky check can't eat the day
   Anything needing fleet secrets, Bitwarden, Supabase service keys, the laptop, the sandbox, Tailscale, or local services	❌ Never	Jules runs in Google's cloud VM with only its GitHub App access. There is no path to fleet credentials, and there must never be one
   Work whose verification needs the fleet's Nix builds / full flake evaluation	❌ Poor fit	The VM offers standard toolchains; the fleet's heavyweight Nix verification would be slow-to-impossible there, so Jules would be opening PRs it cannot actually verify — the fleet's CI still gates, but unverified-volume is how review queues drown
   Cross-repo propagation sets (the fleet's one-change-many-repos rule)	❌ Poor fit	Jules tasks are single-repo; the set discipline lives in fleet process Jules cannot see
   Triage, design, investigations, placement judgement, anything labelled held / user-owned / escalated	❌ Never	Judgement work belongs to the Claude/OpenCode routes (#2019's subject); Jules is an execution surface for already-specified work
   Monitoring, babysitting, anything persistent or interactive	❌ Never	A scheduled Jules run is a fire-and-forget batch that ends in a PR; it holds no state and watches nothing

   The one-line rule: Jules schedules take work that is recurring, single-repo, fully self-contained, mechanically verifiable, and cheap to reject. If a human would need to answer a question mid-task, it is not a Jules task.

   How Muse manages the schedule (alongside the other two)

   The fleet would then have three schedule surfaces, with distinct jobs:

   • Muse cron — judgement-bearing fleet work (this queue's workers, monitors, creators): unchanged.
   • OpenCode schedules (investigate: OpenCode native scheduled tasks — creation, route choice, independence from Muse tokens #2019's finding: no native scheduler; OS timer + opencode run on chosen quota routes) — session work needing fleet tools/context on fleet machines.
   • Jules schedules — the commodity-maintenance slice above, running on Google's quota, touching zero fleet tokens. That is the entire strategic point (LIST 4): every recurring chore that fits Jules is Muse+OpenCode capacity handed back.

   Management mechanics:

   1. Registry: a single fleet-side record (in the placement-framework docs, next to the cron inventory) listing every Jules schedule: repo, cadence, prompt verbatim, budget expectation, date created, kill criteria. Jules' UI is the execution truth; the registry is the management truth — without it, schedules are invisible to fleet reviews (the exact failure mode investigate: Jules scheduled tasks — what fits, and how Muse manages the schedule #2020 exists to prevent).
   2. Create / adjust / retire: via the Jules web UI under Drew's collected account (browser session; any Google sign-in challenge is Drew's to clear, surfaced immediately per standing rules). Prompts for scheduled runs must be self-limiting (max PRs per run, smallest-first, explicit exclusions: never touch held/user-labelled issues, never edit workflow permissions, never force-push) because scheduled runs are unattended.
   3. Double-work control: Jules starts work from its own triggers (including the jules GitHub label — applying that label is an assignment and must be treated as one in fleet bookkeeping). Scheduled Jules prompts operate on maintenance surfaces (workflows, deps, docs) that the queue does not claim; if a Jules schedule is ever pointed at issues, the issues get fleet assignment labels + an agent note from the babysitting Muse pass before Jules can start, and queue workers treat Jules PRs like any other agent's (first holder wins).
   4. Output handling: Jules PRs enter the normal fleet PR flow — reviewed like anyone's, never auto-merged until a schedule has a multi-week clean record, and that promotion is a recorded decision, not a default. The daily fleet monitor (or a small addition to it) lists open Jules PRs + yesterday's Jules session count from the API, so budget burn and PR backlog are visible in one place.
   5. Budget governance: scheduled runs are capped at a small fixed slice (proposal: ≤ 5 runs/day across all schedules) of the ~100/day; Suggested Tasks stays off until the pilot proves out (it spends the same budget proposing work nobody triaged); CI-Fixer attempts capped per PR. The rest of the budget stays reserved for ad-hoc Jules use, which is where its marginal value is highest.

   Proposed first Jules schedule (the pilot)

   Exactly one schedule, two-week trial, chosen to be useful, verifiable, and boring:

   • What: "Weekly GitHub Actions version-bump sweep — developing-today/code." Prompt (to be finalized at creation): check .github/workflows/ for actions pinned to superseded major versions; open one PR bumping them, with per-action changelog links and a note of any breaking-change flags; do not change workflow permissions, triggers, or secrets references; if nothing is outdated, open nothing.
   • Cadence: weekly (Monday, early UTC — lands before the fleet's week starts).
   • Budget: 1 scheduled run/week + CI-Fixer retries — noise against 100/day.
   • Success criteria (review at 2 weeks): PRs are correct and mergeable with at most trivial edits; zero workflow breakage attributable to a bump; reviewer time per PR < 10 minutes. Pass → add a second schedule (docs-drift on one repo, weekly) and consider dependency bumps for a mainstream-stack repo. Fail → pause the schedule (the UI supports it), record why in the registry, and the placement conclusion is "Jules = ad-hoc only for this fleet" — a perfectly good outcome for one investigation + one pilot to reach.
   • Explicitly not in the pilot: Suggested Tasks, issue-driven work, any second repo, any auto-merge.

   Open items / risks

   • API v1alpha churn: schedule behaviour and limits can shift; the registry review should re-verify Jules facts quarterly (or when a schedule misbehaves).
   • Jules PR volume vs reviewer attention is the real scarce resource — the pilot's reviewer-time criterion matters more than its correctness criterion.
   • One account = one point of failure and one identity on every Jules PR; if the fleet later wants Jules on more repos concurrently, additional accounts are Drew's decision (and a Google-ToS-shaped question), not something to engineer around.
   • This investigation and investigate: OpenCode native scheduled tasks — creation, route choice, independence from Muse tokens #2019 (OpenCode scheduled tasks, completed earlier today by lane D: no native scheduler; OS timer + opencode run pattern, worked example verified) are the two route inputs to the placement synthesis design: task-placement framework v1 — decision rules and a shared-pool efficiency model #2024 named by the program; both are now complete.

   Follow-on routing (same pass)

   • Filed pilot follow-on fleet: pilot: first Jules schedule — weekly GitHub Actions version-bump sweep on developing-today/code (from #2020) #2265 — create the one proposed schedule (weekly Actions version-bump sweep on developing-today/code), register it in the fleet schedule registry, and report the first run — enqueued as triage task 3419 in the same pass. Creating the schedule itself needs Drew's Jules account session in the browser; the follow-on says so plainly rather than pretending a worker can click it into existence alone.

   🤖 Agent note · done — queue worker (repo-worker-code), lane C, task 3339 (attempt 2; first claim expired without an outcome). Investigation recorded here; pilot follow-on filed + enqueued.
10. dezren39

    removed

    status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

    queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

    on Oct 29, 2026
11. 4 remaining items

    Load more
12. dezren39

    added

    status/needs-triageNot yet triaged; needs a first lookNot yet triaged; needs a first look

    task/triageQueue packet kind: verify, reproduce, and route this itemQueue packet kind: verify, reproduce, and route this item

    on Nov 3, 2026
13. developing-today commented on Nov 3, 2026

    

    developing-todayBot

    on Nov 3, 2026 – with developing.today

    Contributor

    More actions

    agent-note:v1
    state: reviewed (coverage loop-back)
    Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 7265 (triage, queued, priority 50) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
    Found via: coverage loop-back 2026-11-03
14. dezren39

    added

    queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

    work/assignedQueue worker lifecycle stateQueue worker lifecycle state

    status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

    and removed

    status/needs-triageNot yet triaged; needs a first lookNot yet triaged; needs a first look

    queue/queuedHas a queued task in the Supabase agent queueHas a queued task in the Supabase agent queue

    on Nov 4, 2026
15. dezren39 commented on Nov 4, 2026

    

    dezren39

    on Nov 4, 2026

    MemberAuthor

    More actions

    agent-note:v1
    event: picked_up
    task: 7265 (repo-health-code-pilot; worker repo-worker-code; OpenChamber scheduled lane 335a5d1f-bfc1-4831-99ea-850c8939a727)
    state: claimed; resumed from the prior handed_off checkpoint.
    verified: #2020 is OPEN, with the earlier detailed investigation result already recorded; that result names follow-on #2265 and synthesis #2024. Fresh PR search found no open PR for this investigation (the placement-framework PR #4994 is merged); no hard-stop labels are present.
    next: revalidate #2265 and the newer Jules retirement decision, then close or route #2020 with current evidence.
16. dezren39 commented on Nov 4, 2026

    

    dezren39

    on Nov 4, 2026

    MemberAuthor

    More actions

    Triage verdict — completed investigation; proposed pilot is moot

    Fresh triage for queue task 7265 (2026-11-04): #2020 is OPEN and has no hard-stop labels or open implementing PR.

    • The requested fit matrix and Muse-management investigation are already delivered in the detailed result at investigate: Jules scheduled tasks — what fits, and how Muse manages the schedule #2020 (comment).
    • The only buildable follow-on from that result, Jules pilot fleet: pilot: first Jules schedule — weekly GitHub Actions version-bump sweep on developing-today/code (from #2020) #2265, is CLOSED as moot after the 2026-10-30 decision to retire Jules rather than create the proposed schedule. The later retirement record Jules retirement (ruled 2026-10-30) was never executed — dispatch crons, Jules-side schedules, secrets, and mcpx wiring all still live #5098 confirms the full-retirement direction; its 2026-11-03 schedule close-out reports the Jules-side schedules deleted. Jules retirement (ruled 2026-10-30) was never executed — dispatch crons, Jules-side schedules, secrets, and mcpx wiring all still live #5098 remains open for separate decommission close-out items, which do not block this investigation.
    • The placement synthesis that consumed this investigation is already merged as PR docs: task-placement framework v1 — decision table + shared-pool model + exceptions (#2024) #4994 (443e1d91bfda1e8b2822eb78595c02faffcb2789). design: task-placement framework v1 — decision rules and a shared-pool efficiency model #2024 remains open for the orchestrator review round; that review stays on the synthesis issue, not as untriaged work here.

    No new follow-up is warranted: the investigation is complete, and its proposed Jules pilot was deliberately retired. Closing #2020 as completed; no technical blocker.
17. dezren39

    closed this as completedon Nov 4, 2026
18. dezren39

    added

    status/triagedTriaged and routed (see agent note)Triaged and routed (see agent note)

    and removed

    queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

    status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

    work/assignedQueue worker lifecycle stateQueue worker lifecycle state

    on Nov 4, 2026