Clarify that trigger shape and execution-engine need are orthogonal

Stress-tested the decision rule in docs/loop-engineer-pattern.md against
domains shaped opposite to the two examples (event-driven+needs-engine,
scheduled+no-engine). The rule itself held, but the two existing examples
happened to pair scheduled-with-engine and event-with-no-engine, which could
read as the trigger determining the engine choice. Added two one-line
counter-examples to break that implicit correlation.

Author: Ryan Leckenby

LOG.md

@@ -8,6 +8,7 @@ Format: `YYYY-MM-DD HH:MM | domain | one-line summary | link(s)`
 
 ## Entries
 
+- 2026-06-22 16:00 | scaffold | stress-tested the orchestration/execution decision rule against opposite-shape domains (event+engine, scheduled+no-engine); rule held, fixed an implicit correlation in docs/loop-engineer-pattern.md's examples | [[docs/loop-engineer-pattern.md]]
 - 2026-06-22 15:00 | review-signals | added review-signals skill + skill-writing recipe; dogfooded against a synthetic signal (correctly judged "leave open," then removed) | [[.claude/skills/review-signals/SKILL.md]]
 - 2026-06-22 14:00 | smoke-test | dogfooded new-loop skill (scaffold verified correct, then removed — throwaway test domain) | [[.claude/skills/new-loop/SKILL.md]]
 - 2026-06-22 12:00 | scaffold | initial knowledge base + skills scaffolded from the loop-engineer-template pattern | [[knowledge/README.md]]

docs/loop-engineer-pattern.md

@@ -49,6 +49,23 @@ to call and when, based on results it can't predict in advance?**
 Most domains will be the second kind. Reach for the Python engine when a step's tool-calling
 shape is genuinely open-ended, not by default.
 
+**Trigger shape and execution-engine need are independent axes — don't conflate them.** The two
+example domains happen to pair scheduled-with-engine (`task-refinement`) and
+event-driven-without-engine (`dev-trigger`), which can make it look like the trigger decides the
+engine choice. It doesn't; they're orthogonal:
+
+- **Event-driven *and* needs the engine**: an `incident-response` domain triggered by a paging
+  webhook, whose work is "check recent deploys, query the error tracker, check related logs, form
+  a hypothesis, maybe roll back" — an unpredictable, data-dependent number of tool calls, same as
+  `task-refinement`'s, just woken up by an event instead of a clock.
+- **Scheduled *and* doesn't need the engine**: a `weekly-log-rollup` domain triggered by `/schedule`
+  every Monday, whose work is "read every `LOG.md` line since the last rollup, summarize into one
+  `knowledge/notes/` entry" — a fixed sequence with no open-ended tool-calling, same as
+  `dev-trigger`'s, just woken up by a clock instead of an event.
+
+Always re-ask the question in this section per domain — never infer the engine answer from the
+trigger answer.
+
 ## Putting it together: one full cycle
 
 Using `task-refinement` as the example: