taskguard v0.11.0-rc.1

Added

• taskguard dump PATTERN | --cmd "COMMAND" | --run ID prints everything
  taskguard knows about a job as one JSON document: how the command matches,
  the rules in force and which file set them, what the next run reserves and
  why, step by step (history, boost, first guess, caps, minimums), each recent
  run with what it waited for, what it changed, and its role in the need
  (outlier, failed and ignored, boost), pruned runs, and the live queue entry.
  Use it to find out why a job reserved what it did.
• Each run now stores how its need was made (runs.need_why), so dump
  can explain an old run too, not only the next one.
• A long-lived job can declare the work that will run on it:
  --expect WORK (repeatable) or TASKGUARD_EXPECT=WORK,WORK, where WORK is
  a pool name, a job key or a command pattern. The stack books room for that
  work (learned as the work learns its own need; for a pool, the need its
  jobs typically started with) and starts only with room for both. A job in the same checkout that matches is its work: it goes one
  priority above the stack, takes over the booked room when it starts, and
  waits while its stack still waits. taskguard status shows (for stack KEY) on the work and (expects WORK, books SIZE) on the stack. Without a
  declaration, only what the history infers applies (infer_work, below).
• A long-lived job with no declared work books the work its history says
  follows it: work of one kind (a pool, or a key outside any pool) that
  queued in its checkout within infer_work_within (900) seconds of its
  start on at least infer_work_min (3) of its last infer_work_of (5)
  runs there. It books that work's usual need, shown as (expects WORK from history, ...) until work queues for it, for twice its usual delay and ten
  minutes at most, and drops it once work for the stack starts. While the
  guess is open the stack waits expect_wait for the work, and matching work
  links to it and goes first; an expired or started guess links nothing, and
  work linked to it drops back to its own priority. A guess whose work has queued and
  linked to it came true: it is declared work from then on, also for the
  rule for nothing running, and does not expire while that work waits. The
  guess never stops the rule for nothing running. Another stack respects it
  while it is open, also one started with no declared work, so such a stack
  waits at most until the guess expires or its work starts; a stack that
  still fits next to it starts at once. A declaration wins; --expect none
  expects nothing; infer_work = false turns it off.
• expect_wait (5 seconds by default, 0 turns it off): a long-lived job that
  expects work, declared or from its history, waits that long before it
  starts for the work to queue, so a stack and a run started together start
  with room for both. A stack that expects nothing starts at once.

Changed

• With nothing running, or nothing but long-lived jobs past their start-up,
  the first job in line that fits starts, up to all of RAM, rather than the
  first in line whatever the memory reading says. Next to long-lived jobs, a
  long-lived job, such as a second dev stack, starts that way only under
  mem_max, or, when only programs outside taskguard keep it out, up to the
  ceiling outside_admit allows. With nothing of taskguard's running, it
  starts up to all of RAM, as before. A job that does not fit holds nobody
  back, so the jobs behind it that fit start. At macOS warning this rule
  still decides when only long-lived jobs run.
• A waiting job that would not fit even once every job that ends by itself
  has ended holds nobody back, whatever its priority or reservation: it can
  only start once a long-lived job is stopped or other programs free memory,
  and the small jobs behind it start meanwhile.
• A stack with work queued for it, and work whose stack runs, hold their turn
  as a strict reservation, also while they do not fit yet, rather than letting
  jobs that fit start meanwhile (backfill).

Fixed

• A second dev stack is no longer started over memory while the first one's
  run waits: the rule for "nothing runs but long-lived jobs" started the head
  of the line whatever the readings said, and skipped itself at macOS
  warning, so the run waited until its caller gave up.
• The NEXT line names a long-lived job that holds the room as one that must
  be stopped, not as one that will finish.
• outside_admit works again when mem_max is at or above pause_at
  (92% by default), as with mem_max = 95. It capped memory at pause_at,
  under the limit, so it could never let a job start; the cap is now
  halfway from mem_max to all of RAM in that case.

Prebuilt binaries for macOS (Apple silicon, Intel) and Linux (x86_64, ARM, static musl). Each archive holds the taskguard binary; a .sha256 file sits next to it.