宜博 / lemongraph

Two real findings from today's live self-hosting run, surfaced while diagnosing why
bfd3ee82/71868db6 were blocked:

1. trigger_org_node/trigger_org_node_structured use a fixed wall-clock
   subprocess.run(timeout=...) -- a long-running-but-genuinely-progressing agent call
   gets killed just for taking longer than a guessed constant (300s), which is exactly
   what happened to bfd3ee82's Validator planning call. Per an already-established
   (but never actually implemented) decision: an agent call should never be judged
   "stuck" by total duration alone, only by an extended period with no activity AND no
   error. New requirements doc:
   docs/todo/agent-call-liveness-not-fixed-duration-timeout-requirements.md.

2. task_execution.py::_mark_blocked's catch-all dumps anything outside a small
   exception whitelist into blocked_reason='execution_error' -- including
   ConcurrencyLimitReachedError, which isn't an error at all, just normal backpressure.
   Boss Agent needs the system to emit distinct, meaningful reasons at the point of
   failure, not reverse-engineer root cause from a generic bucket -- added as FR-7 to
   the Boss Agent doc.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Requirements doc (BRD/PRD level) for a new org-level role that monitors
blocked_pending_human tasks, does real diagnosis (not blind retry), and acts
within an explicit authorization boundary instead of always waiting on a
literal human -- generalizing the planner_reviewer precedent (an autonomous
judgment agent already replacing a human review gate) to this surface.

Motivated by today's real incident: 4 tasks blocked with the same generic
execution_error reason but three genuinely different root causes (stale
process, legacy narrative-output format, a real concurrency bug), all
diagnosed by hand. Also documents watch_resume.py's real concurrency-race
flaw as a requirement input (FR-6) so the eventual implementation doesn't
repeat it.

Deliberately does not pick the autonomy boundary per blocked_reason -- left
as an open question for explicit user sign-off, not something Planner should
infer silently.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>