Long-running checks: ten-minute timeout or background

operating-model/decision-log.md

@@ -42,3 +42,4 @@ Status is intentionally explicit:
 | 2026-09-29 | Confirmed | Projects keep their launch prompts as named, versioned files in the repo, with an index; a launch is one line naming the prompt and its path, plus parameters; the run report names the prompt version it ran. | The owner approved the lead's design ("go") for replacing pasted launch text with checked-in prompts, so a launch is repeatable and a report says which prompt version produced it. Adds to the 2026-09-29 dispatcher row. See `agent-work-loop.md` section 7. |
 | 2026-10-08 | Confirmed | The owner's cross-project rules live here in vendor-neutral words so any agent works the way the owner wants in every repository: model tiers (deep, standard, light, premium) with a vendor mapping, premium launches only on the owner's per-launch yes, ask before any new service, monitor, workflow or scheduled wakeup, never set a spend cap ($0 by default), they/them for the owner, a fresh brief for a scope change, files only under `~/work`, scratch in the harness's scratchpad or `~/work/code/mastrix/worktrees/<repo>-<task>-notes/`, never `/tmp`, and a vendor-neutral checkpoint procedure. | Owner, R1008-27: "n1-n8 is good", accepting decisions D1-D8 of the agent-neutrality plan as recommended, and: "any agent can work exactly like the way I want it to on the repo". Sources: the owner's rulings of 2026-09-27, 2026-10-05 and 2026-10-06 as kept in the Claude memory files. Supersedes the vendor-named tier wording of the 2026-09-21, 2026-09-23 and 2026-09-27 rows (they stay as history) and the 2026-09-27 scratch-path example. See `working-style.md` → Model tiers, `execution-and-handoffs.md` → Scratch files and agent worktrees, and `procedures/checkpoint.md`. |
 | 2026-10-12 | Confirmed | Inquiry sessions are question-only sessions to understand a project; artifacts stay local and agents proactively propose consolidating answers into FAQs, documents, diagrams or tables. | Owner: "This is only a session for asking questions. We'll name it 'inquiry'... remember to propose it either as an FAQ, a section, a document, a README, a diagram, or a table." See `working-style.md` → Confirmed preferences (Inquiry sessions). |
+| 2026-10-12 | Confirmed | Checks that can outlast the shell tool's default timeout run with the maximum timeout or in the background, and every brief that runs checks says so. | Owner asked for the rule to leave one project's memory and live in the shared rulebook. Evidence: two agents' `make check` runs were killed on 2026-10-11 by the two-minute default, not by another process. See `execution-and-handoffs.md` → Long-running checks. |

operating-model/execution-and-handoffs.md

@@ -194,6 +194,17 @@ true, dispatch that action in the first writable turn and record the dispatch. I
 interval cannot mutate a worktree, it must carry the queued action forward rather than letting the
 next ordinary turn rediscover it.
 
+## Long-running checks
+
+A full project check (a complete `make check`, the whole test suite) can outlast the shell tool's
+default timeout, which is about two minutes. The run is then killed with a SIGTERM that looks like an
+outside process stopping it. Run any check expected to take longer than that either with the tool's
+maximum timeout (ten minutes) or in the background, and state which one the hand-back used.
+
+Put this line in every brief that runs checks. Report a possible broad process kill only if a run
+dies under the ten-minute timeout. Two DIS agents lost `make check` runs this way on 2026-10-11 and
+nearly set off a hunt for a rogue `pkill`.
+
 ## Documentation currency gate
 
 Updating the README that covers the changed code is mandatory before checking anything in — a