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.5 KiB

Raw Blame History

Supervisor Behaviour

Metadata

Field	Value
Institute	Molodetz Institute — Research & Retrieval Division
Subject	background-work-limits
Document type	Source Dossier
Tier	1
Source title	Supervisor Behaviour
Source URL	https://www.erlang.org/doc/design_principles/sup_princ.html
Source publisher / author	Erlang/OTP System Documentation v29.1.2
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 OTP supervisor reference: children restart by strategy, but restarts are bounded by a maximum intensity (MaxR restarts in MaxT seconds, default 1 in 5), past which the supervisor terminates everything and escalates. Bounding must be structural (a counter with a tripwire), not advisory.

Key findings

"The supervisors have a built-in mechanism to limit the number of restarts which can occur in a given time interval", specified by intensity (MaxR) and period (MaxT).
"If more than MaxR number of restarts occur in the last MaxT seconds, the supervisor terminates all the child processes and then itself."
"The intention of the restart mechanism is to prevent a situation where a process repeatedly dies for the same reason, only to be restarted again."
Defaults are 1 and 5 when not given; escalation goes to the next higher-level supervisor.

Pros / strengths

Four decades of production supervision distilled into one mechanism; the intensity-plus-period shape is directly portable to any retry or respawn loop.
The escalation rule (trip, terminate, let the parent decide) matches tai's loud-failure style better than silent infinite retry.

Cons / limitations / caveats

Erlang process semantics (cheap processes, real kills) do not transfer to Python threads, which cannot be killed; tai can refuse and abandon but never terminate a stuck worker.
No notion of a parallel-worker cap; OTP bounds restarts, not breadth, so the fan-out half comes from the semaphore source instead.

Relevance to tai

Justifies the two bounds tai adopts: a parallel-live cap (breadth) plus no-blind-retry (tai workers and schedules never auto-restart; failures surface as loud results). If tai ever adds worker retry, this source prescribes intensity-plus-period as its shape.

Changelog

Date	Change
2026-10-18	Initial dossier created.

2.5 KiB Raw Blame History