You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On m1 (96G root, also the production fleet node) today, multiple agent sessions ran repo checks concurrently and free disk fell from ~48G to ~4G, nearly taking the box down. The owner has suspended greentree use on this box until this is governed.
No way to publish when one required check is knowingly unrunnable on this box. Today an agent that ran every command of full by hand (all green) still cannot gate/publish because verdicts only come from greentree-executed runs. That forces the exact bare git commit fallback the tool exists to prevent. Proposal: either greentree gate --only <checks> with the skipped required checks recorded as skipped(<reason>) in the publish journal (auditable, not silent), or greentree attest-external <check> that records a verdict for the current tree with external: true provenance so the gate can distinguish trusted-machine-verified from operator-claimed.
Context: hit while building the port-share PoC stack on 2026-08-19; the data-path change was committed bare with the full-check commands run by hand, recorded in the working notes.
On m1 (96G root, also the production fleet node) today, multiple agent sessions ran repo checks concurrently and free disk fell from ~48G to ~4G, nearly taking the box down. The owner has suspended greentree use on this box until this is governed.
Two concrete gaps, one proposal each:
Per-box budget, not per-run floors.
min_free_disk(full check needs ~50G of build output and has no disk floor — it filled a production node's root filesystem #6, shipped in Govern disk, gate merges, and find tokens where they live #9) refuses to start under a floor and kills mid-run via statvfs, but each run judges only itself: N concurrent greentree runs (or greentree beside plain cargo builds, Checks that consume build artifacts race concurrent builders in a shared checkout #7) each see enough headroom and collectively fill the disk, because a workspaceclippy --all-targets/test check can growtarget/by tens of GB after the pre-start check passes. Proposal: a machine-wide advisory budget — a lock/lease file under$XDG_RUNTIME_DIR/greentree/recording each live run's declared max footprint (per-checkmax_diskin greentree.yaml); a run refuses to start when the sum of live declarations plus its own exceeds free space. Declared-but-wrong footprints still get caught by the existing statvfs kill.No way to publish when one required check is knowingly unrunnable on this box. Today an agent that ran every command of
fullby hand (all green) still cannotgate/publishbecause verdicts only come from greentree-executed runs. That forces the exact baregit commitfallback the tool exists to prevent. Proposal: eithergreentree gate --only <checks>with the skipped required checks recorded asskipped(<reason>)in the publish journal (auditable, not silent), orgreentree attest-external <check>that records a verdict for the current tree withexternal: trueprovenance so the gate can distinguish trusted-machine-verified from operator-claimed.Context: hit while building the port-share PoC stack on 2026-08-19; the data-path change was committed bare with the full-check commands run by hand, recorded in the working notes.