0 Fork 0

Files

T

Frank 8af40c402b chore(agent): commit the machine tier and the doctrine text the checkout was already running

Landing blocker for #61 and #63: the deployment checkout is 12 commits behind and
`merge --ff-only` refuses while tracked paths are dirty. Discard is not available here
(workspace policy: no `checkout`/`stash` on shared state), so the dirt is committed.

- `agent/APPEND_SYSTEM.md`: the point-of-use / one-work-log / PR-link doctrine, already
  byte-identical to `origin/main` (`cmp` against the trunk blob: no difference). No new
  prose — the commit exists so the trunk merge can proceed.
- `agent/config.yml` and `agent/managed-skills/**`: the machine-live tier the heartbeat
  owns (AGENTS.md § Live-sync tiers).

`ALLOW_SECRETS=1` was used, deliberately and after auditing the staged diff by hand: the
only credential-shaped strings in it are two copies of `AKIA0000000000000EXAMPLE` — the
inert all-zero AWS example id — and they appear inside the two skill pages that teach
that exact placeholder shape. This checkout is still running the pre-#61 hook; the merged
gate (value-scoped placeholder filter, `71601f7`) exempts this value, so the refusal
dies with this landing. No `--no-verify` was used: the gate ran and its verdict is
recorded here.

Refs #61

2026-10-21 01:44:51 -07:00

2.4 KiB

Raw Blame History

name, description

name	description
omp-background-job-deadline-debug	Diagnose a background bash job/service killed mid-run ("Command timed out after Ns") in omp: find which deadline owned it (tools.maxTimeout cap vs async default), prove it from the bundle, and launch long jobs uncapped as ready-log services.

Omp background-job deadline forensics

Symptom: an async bats/build job dies with [Command timed out after 300s|600s] while the same launch once ran 18+ min ("no deadline").

Cause map (proven against the pinned bundle)

Resolver in dist/cli.js: let v=n??300, R=v===0, k=R?void 0:ep("bash",v,x) where qx.bash={default:300,min:1,max:3600} and x = config key tools.maxTimeout ("Maximum timeout in seconds the agent can set for any tool", default 0).

Request absent → qx.bash.default 300 s.
Request > 0 → clamped by tools.maxTimeout when set (e.g. 600 caps a 1800 request).
Request 0 → meant "no deadline", but 0 sometimes arrives as missing (falsy drop upstream of the resolver) → silently 300 s. Filed as tool issue; treat any async job over ~5 min as untrustworthy.

Diagnose in three moves

grep -o 'qx={bash:{[^}]*}' <omp bundle> — policy table (command -v omp → readlink -f → dist/cli.js).
read cfg://tools — live maxTimeout (value ≠ 0 explains any hard cap).
Compare kill notices: the number in "killed once it has run Ns" is the resolved deadline; 300 = default reached (request dropped), other values = your request or the config cap.

Launching jobs longer than the cap

Named services are not deadline-capped: bash(name:"x", pty:false, command:"…; echo DONE >> log", ready:{log:"DONE", timeout:900}). Readiness fires on the log pattern; result does NOT auto-deliver — wait on it or read proc://x after the supervisor notice.
NEVER end the service command with echo "EXIT $?" >> log and trust the supervisor's exit code — the trailing echo masks it (supervisor reports 0 while the log says EXIT 1). The log line is the truth; grep the log for the recorded code and ^not ok before believing any "exit code 0".
Do not raise tools.maxTimeout unasked: session-scoped write cfg://tools/maxTimeout needs user approval and may be declined — respect it, use the service route.

Multi-suite hazard

Suites that rebuild shared artifacts per test (e.g. dankvoice bats rebuilds dist/) must not run concurrently — one suite at a time, or per-worktree copies only.

2.4 KiB Raw Blame History