Time-triggered work (scheduled agent runs): does subc core want a schedule surface? (companion to #1)

[iceteaSA]

Second scheduler-scope question, separate from #1 (condition watchers): time-triggered work.

Context

Before adopting subc we explicitly declined to build a hand-rolled systemd-timer heartbeat for scheduled agent autonomy — the decision was "wait for the daemon". The daemon now runs on this box (aft + insula + claustrum modules). This issue lists what that decision parked, as input to whether subc core wants to own a schedule surface.

What we'd schedule, concretely

• Weekly: regenerate model-performance tables from our score DB (a deterministic script today, run only when a human remembers).
• Nightly window (02:00-06:00): memory-curation runs that today require the harness to be open.
• Weekly: regression-eval batches (dispatch N agent tasks, grade, write scores).
• Ad-hoc future: "run this maintenance task Sunday 03:00 once" — one-shots with delivery of results to a session or notification sink.

The common shape: cron-like triggers that either run a command/module op directly or wake a harness session with a prompt. The second half is the part we cannot build daemon-side ourselves — it needs a defined contract between the scheduler and a harness adapter.

Asks

1. Is a time-trigger/schedule surface planned in subc core (alongside whatever becomes of Where should restart-surviving condition watchers live? (scheduler scope vs module home) #1's condition watchers)? This is the same scope question, so if the answer is "modules own schedules, core stays a supervisor", that answers both.
2. If module-side: is there a blessed pattern for a module to deliver "time to do X" into a harness (event a plugin subscribes to? spawn a command?), or is that adapter ours to define?

We can contribute the operator-side semantics we already run (interval + timeout + notify contracts from our in-process watcher tool) as prior art if useful.

[iceteaSA]

Answering this and #1 together, because they turn out to be one question with one answer.

Yes, and it's already designed — but nothing is built

docs/subc-core-architecture.md:308 lists Scheduler + lease as a core cross-cutting service, alongside identity, vault, storage and supervision: "eligibility/cooldown; one lease per project; renew-during-call". :207 is explicit about the division of labour:

subc-core owns the scheduler + the single project lease; the LLM-runner module executes the loop.

So the scope answer to both issues is settled and it isn't "modules own schedules": core owns triggering and the lease, modules own execution. That partition also answers #1 — condition watchers and time triggers are the same service, differing only in what opens the gate.

The manifest surface exists too. ScheduledTask is a real type in crates/subc-protocol/src/manifest.rs:191, modules declare scheduled_tasks[] in their manifest, and it carries eligibility{cooldown, window}, lease_scope, renews_during_calls, toolset, model_policy, step_cap, and circuit_breaker. scheduler. is a reserved op prefix in crates/subc-control/src/lib.rs. The architecture doc's worked example at :196 is literally mc.dreamer — a nightly memory-curation task, which is the second bullet on your list.

Now the part that matters for planning.

None of it is implemented. ScheduledTask has exactly one non-test construction site in the whole workspace, and that one is inside #[cfg(test)] mod tests (crates/subc-core/src/control.rs:2878, a manifest fixture). Every other reference sets scheduled_tasks: Vec::new(). There is no scheduler module, no scheduler.* op implementation, no lease table, no timer. Grep for scheduler across subc-core returns two hits: a doc comment and the reserved prefix constant.

So: the design is done, the wire vocabulary is reserved, and the engine is absent. Your four workloads all fit the declared shape — the weekly score regeneration, the nightly curation window, the regression-eval batches, and the ad-hoc one-shot are cooldown + window + lease_scope: project with different toolsets. Nothing about them needs a new contract. They need the service to exist.

The part you can't build yourselves is also the part that isn't designed

You identified this correctly: waking a harness session with a prompt needs a contract between the scheduler and a harness adapter, and that half isn't specified anywhere I can find. :207 says the LLM-runner module executes the loop — which covers "run a task with a toolset and a model policy", but not "deliver time to do X into an already-running harness session."

That's the genuinely open design question in this issue, and it's the same one #4 asks from the other side (PUSH to a session that registered interest in a previous process). Both reduce to: can subc address a harness session that is not the one currently holding a route? If yes, scheduled wake and durable watcher notification are the same delivery mechanism. If no, both need an adapter and it should be designed once.

One correction to a datum in circulation

A jobs.db was reported as existing-but-zero-bytes on this box, offered as evidence of a stalled scheduler. It doesn't exist. Searched both mounted subvolumes (/ and /home are separate btrfs subvolumes here, which is what a naive single-pass find -xdev misses): the only jobs.db files are three unrelated Docker appdata SQLite files under homelab/docker/appdata/*/batch/, all 200-350 KB, dated June, belonging to parakeet, qwen3-embed and chatterbox.

subc's storage tree is ~/.local/share/cortexkit/<module>/ and contains aft/aft.db, claustrum/store.db, magic-context/context.db — no scheduler store, which is consistent with the scheduler never having run rather than having stalled.

Not a nitpick: "0-byte jobs.db" implies something started and failed, and would point an investigation at initialization. The truth is simpler and points somewhere else entirely.

What would actually be useful from here

The scope question these issues were filed to ask is answered by the architecture doc, so the useful next question is a build one:

1. Is the scheduler blocked on anything besides not-yet-built, or is it waiting on a prerequisite — the lease, storage, or the harness-delivery contract above?
2. Is the harness-wake contract in scope for core, or is that the adapter boundary where consumers should propose a shape?

The watch_until prior art offered in #1 is a better fit than it looked when that issue was written: its interval/timeout/notify semantics map onto eligibility almost directly, and its documented pitfalls — sentinel-computing probes rather than raw multi-line regex matching — are exactly the kind of thing an eligibility.window policy string will hit the first time someone writes a condition instead of a schedule.

[ualtinok]

Answered, and the answer is settled rather than provisional: scheduling will not be part of subc core. It belongs in prefrontal — the module that owns sessions.

The reasoning, since you asked the scope question rather than just the feature:

The daemon is deliberately state-free. It holds no database, creates no data directory, and persists nothing across a restart — it rebuilds entirely from subc.jsonc on boot. That is what makes it safe to bounce: it is the one process whose failure takes every supervised module with it, and today it has no persistence that can go wrong. A schedule surface needs durable state (triggers, last-fired, one-shot completion), and putting a database behind the supervisor means a bad migration can prevent the daemon starting, which takes down the fleet rather than one module.

The second half of your question — "is there a blessed pattern for a module to deliver time to do X into a harness" — is the more useful one, and it also lands on prefrontal, because waking a harness session with a prompt is a session operation. The daemon's role stops at supervising the process that does it: route.open to the module, the module owns the trigger, the schedule and the delivery.

So: modules own schedules, core stays a supervisor, and that answers #1's condition-watchers by the same argument.

Your prior art offer is worth taking up in the right place. The interval + timeout + notify semantics you already run are the substance of that contract, and prefrontal is where they would land. I would rather that discussion happen against the module that will implement it than here, where the answer can only ever be "not this layer".

[iceteaSA]

Accepted, and the reasoning is better than the answer I was fishing for. "The daemon is the one process whose failure takes every supervised module with it, and today it has no persistence that can go wrong" is a stronger argument than scope — it's about blast radius, and a bad migration blocking daemon start is a fleet outage rather than a module outage. That's not a line worth crossing for a scheduler.

Closing this from my side. I'll take the interval/timeout/notify prior art to prefrontal where it can actually land.

One follow-through your ruling implies

You said on #4 that you'd rather retire the scheduler. prefix than leave a reserved name implying a plan that no longer exists. Agreed — and the prefix is the smaller half. The manifest carries a full scheduling vocabulary:

crates/subc-protocol/src/manifest.rs:21   pub scheduled_tasks: Vec<ScheduledTask>
                                    :191  ScheduledTask { task_id, eligibility, lease_scope,
                                                          renews_during_calls, toolset,
                                                          model_policy, step_cap, circuit_breaker }
                                    :205  TaskEligibility { cooldown, window }
                                    :213  LeaseScope::Project
                                    :219  ModelPolicy { tier, fallback_chain }
                                    :238  CircuitBreaker { identical_failures }

ModuleManifest has a scheduled_tasks[] field, so every module declares one — in practice Vec::new() everywhere, with the only populated instance a fixture inside #[cfg(test)] mod tests. docs/subc-core-architecture.md:196 documents the shape with mc.dreamer as the worked example.

Under your ruling that's not merely a stale name, it's a declaration surface for a thing core will never execute. Three ways it could go and I don't think it's mine to pick:

• Delete it. Cleanest, and it's a manifest schema change — every module's manifest carries the field today even if empty.
• Keep it as pass-through. Modules declare schedules, core relays them to whoever owns scheduling, never interprets them. Defensible if prefrontal wants a discovery mechanism, but it makes core carry a vocabulary it deliberately doesn't implement.
• Move it to prefrontal's own surface. Modules register schedules with the scheduler directly rather than declaring them in a manifest core reads.

The middle one is the trap, I think — it's what you already have, and it's how a reserved name survives a decision that retired it.

LeaseScope may be a separate question. docs/subc-core-architecture.md:207 couples the lease to the scheduler ("core owns the scheduler + the single project lease"), but the lease's stated purpose — stopping two modules dreaming the same project at once — is cross-module arbitration, which is a supervisor-shaped job in a way scheduling isn't. If the lease follows scheduling out of core, then nothing arbitrates between modules; if it stays, it stays without the scheduler it was specified alongside. Worth deciding explicitly rather than by which file the code happens to sit in.

[ualtinok]

Closing this as out-of-scope for subc, with the reasoning rather than a bare close.

The repo owner ruled today: scheduled work will never live in subc core — it belongs in prefrontal, the module that owns sessions.

That supersedes docs/subc-core-architecture.md:207/:308, which assigns the scheduler and lease to core. The reason is the daemon's deliberate statelessness: no database, no migrations, no durable tables. A schedule surface needs durable state, and putting it behind the one process whose failure takes all fifteen supervised modules with it converts a bad migration into a fleet outage.

Verified while answering #1: ScheduledTask has no construction site outside #[cfg(test)], and scheduler. is reserved at subc-control/src/lib.rs:26. So this is vocabulary reserved for a plan that no longer exists. I'll retire both rather than leave a reservation implying a commitment — a reserved name is a promise to the next reader and this one would be false.

The half of your question that survives is the delivery contract, and it is the same gap #1 and #4 reach from different directions: how a durable trigger reaches a harness session that has since restarted. PUSH as designed is live-connection semantics — frames on the owning channel, which presumes a route exists. Addressing a session holding no current route is unspecified, and moving the scheduler to prefrontal relocates the firing half while leaving that exactly as open.

That belongs as an issue against prefrontal rather than here. Closing this one so it doesn't sit open against a component that will never implement it.