Files

T

retoor af080fe68e Strict goal verification, approval hardening, retrieval eval, work limits, sandbox caps (1.38.0)

- Approval: re-prompt unknown answers (max 3), shell-only affirmative
  guidance recovery; destructive actions stay strict
- GoalVerifier subagent with strict JSON verdicts, bounded follow-up
  rounds, nonzero exit plus open turn on unverified one-shots
- Retrieval eval (Hit@K/MRR/nDCG/Context Precision), FTS cascade with
  title weighting, query/read event logging, --eval-retrieval CLI
- Supervisor caps (8 parallel, 64 records) and scheduler hardening
  (4 fires/tick, per-schedule lease, stated misfire policy)
- Sandbox box resource trio: 2g/2.0/256 at create, best-effort
  update for existing boxes, rm -f recovery pointer
- Research archive: 12 subjects, 667 sources, 27 conclusions;
  suites 979 + 16 green

2026-10-18 12:13:24 +02:00

2.7 KiB

Raw Blame History

APScheduler User Guide

Metadata

Field	Value
Institute	Molodetz Institute — Research & Retrieval Division
Subject	background-work-limits
Document type	Source Dossier
Tier	1
Source title	APScheduler User Guide
Source URL	https://apscheduler.readthedocs.io/en/3.x/userguide.html
Source publisher / author	APScheduler
Source type	vendor docs
Source date (published)	Unknown — not stated (living documentation page)
Date researched	2026-10-18
Researched by	tai (agent), model: Muse Spark, on behalf of retoor
Research method	both
Confidence	High
Status	Active

Summary

The APScheduler guide supplies tai's scheduler policy vocabulary: max_instances defaults to 1 (a new fire while the previous run lives counts as a misfire), coalescing rolls queued missed executions into one trigger, and misfire_grace_time decides whether a late execution still runs (which can fire several runs in succession).

Key findings

"By default, only one instance of each job is allowed to be run at the same time. This means that if the job is about to be run but the previous run hasn't finished yet, then the latest run is considered a misfire."
"It is possible to set the maximum number of instances for a particular job that the scheduler will let run concurrently, by using the max_instances keyword argument when adding the job."
"If coalescing is enabled for the job and the scheduler sees one or more queued executions for the job, it will only trigger it once. No misfire events will be sent for the 'bypassed' runs."
Late execution against misfire_grace_time "can lead into the job being executed several times in succession."

Pros / strengths

Three orthogonal knobs (overlap, coalescing, grace) that decompose tai's scheduler decisions cleanly: tai takes max_instances 1 plus always-coalesce and skips grace windows as unneeded complexity.
Documents the failure mode each knob prevents, so tai's simpler choices stay explicit rather than accidental.

Cons / limitations / caveats

Single-process scheduler semantics; tai's compare-and-swap claim across processes goes beyond what this page covers.
No per-tick firing cap concept; tai's burst bound comes from the supervisor side (global parallel cap), not from here.

Relevance to tai

Direct template for the scheduler half: one live run per repeating schedule (lease-checked, Temporal-Skip style), missed intervals coalesced into one fire (already tai's behavior, now specified), and no auto-retry of failed runs (loud last_status instead).

Changelog

Date	Change
2026-10-18	Initial dossier created.

2.7 KiB Raw Blame History