Work decomposition guidance:
- Choose the simplest execution shape that can complete the assigned work correctly.
- Decompose work only when the decomposition improves ownership, isolation, parallelism, reviewability, context cost, or result handoff enough to justify the orchestration overhead.
- Do not create a new thread merely to avoid a normal same-thread handoff.

Execution-shape decision table:
- Use same-thread handoff when:
  - the next actor can complete the work in one normal turn
  - the result can be reviewed or acted on directly in the parent
  - no parallelism or separate lifecycle is needed
  - role separation is still preserved when needed, for example COD coordinates, DEX implements, CCE smoke-tests, LAU final-reviews, and COD synthesizes, all in the same parent thread
- Use a single child thread when:
  - the subtask is expected to require a substantial multi-message lifecycle, roughly 10 or more messages as a rule of thumb
  - the work may need iteration, debugging, review, or rework
  - the parent should pause on a meaningful separately-owned unit
  - the child needs a clear lifecycle, owner verification, and termination boundary
- Use `CMD: create_thread_batch` when:
  - multiple independent child tasks can run in parallel or any order
  - all children share the same parent-resume aggregation step
  - the fan-out benefit outweighs child-thread overhead
- Avoiding child threads does not mean one actor should perform all roles. For narrow implementation, smoke, or review work, prefer same-thread handoff while preserving role separation inside the parent thread.

Continue in the same thread when:
- The work is linear and directly continues the current message.
- The current actor or the next actor can complete the work in one normal turn without a separate ownership or closure boundary.
- The result can be reviewed or acted on directly in the parent thread.
- No parallelism or separate lifecycle is needed, even if different actors still perform implementation, smoke, review, and synthesis in sequence inside the parent thread.
- The work is a clarification, correction, review response, implementation adjustment, final verification, or termination step.
- The work is tightly coupled to the current thread state and would be awkward or lossy to summarize in a child M0.
- A child thread would immediately need to ask the parent for missing context.
- The coordination cost of creating, closing, and resuming a child thread is likely higher than the benefit.

Map-Reduce-Continue framework:
- Map-Reduce-Continue (MRC) is a KBOS branching workflow framework.
- Map: A parent thread creates child work threads using `CMD: create_thread` or `CMD: create_thread_batch`.
- Reduce: Child threads produce results and close. If parent pending-art slots were declared, child threads fulfill them using `ART:` plus `ATTACHED:` against the previously declared `ART:` plus `PENDING:` slots.
- Continue: After all direct children are Closed, the parent thread resumes. The resumed parent actor reviews the materialized pending-art files or child thread files and moves the parent thread state forward.
- Pending artifact readiness is validated when the parent is invoked. If required pending artifacts are still unmaterialized after the parent thaws, the runner must fail closed with a clear operator-visible validation error.

Use `CMD: create_thread` to create a new root thread when:
- Root thread creation should be rare from normal work threads, and should be used when the work is independent and should not block the current thread.
- The new work is not a subtask of the current thread contract.
- The new work should not block the current thread.
- The new work needs its own independent lifecycle, priority, owner, topic, or scheduling path.
- The root thread owner should be the actor most logically accountable for the independent root-thread contract.
- The current thread is only being used as a launch or control surface.
- The new work is a separate investigation, follow-up, maintenance task, or future work item rather than required continuation of the current deliverable.

Use `CMD: create_thread` to create a child thread when:
- The work is a self-contained subtask of the current thread contract.
- The child can have a clear goal, task, deliverable, constraints, owner, and completion check.
- The actor requesting the child thread becomes the child thread owner and is accountable for the child contract.
- The parent should pause until the child work is complete.
- The subtask is expected to require a substantial multi-message lifecycle, roughly 10 or more messages as a rule of thumb.
- The work may need iteration, debugging, review, or rework.
- The child result has a clear return path to the parent through pending artifacts or child-thread inspection after parent resume.
- The parent thread is expected to be long enough that isolating the subtask would reduce context cost or improve clarity.

Use `CMD: create_thread_batch` to create multiple child threads when:
- The work naturally decomposes into multiple independent subtasks.
- The child tasks can proceed in parallel or in any order.
- All children share the same parent-resume aggregation step.
- The fan-out benefit outweighs child-thread overhead.
- The parent should pause until all direct children are Closed, then resume to aggregate results (map, reduce, continue).
- Batch creation should be atomic: either all requested child threads should be created or none should be created.
- Child threads may fan out further when their own work is substantial, separable, and independently verifiable.

Do not create a new thread when:
- The assigned task can be completed in one normal message or one normal handoff.
- The only benefit is cosmetic organization.
- The child would duplicate the same context and immediately return.
- The child would make the result harder for the parent to consume.
- The parent does not need to block on the work.
- The thread tree would become deeper without a meaningful ownership, isolation, or context-cost benefit.

Cost and context guidance:
- New threads can reduce average thread transcript length and repeated context cost for substantial, separable, or parallel work.
- New threads also add orchestration cost: creation, child discovery, child closure, parent resume, and result aggregation.
- Prefer same-thread continuation for small linear work.
- Prefer child threads for substantial self-contained subtasks.
- Prefer batch fan-out for independent subtasks that can proceed separately.

Result return guidance:
- Before creating child threads, decide how child results should return to the parent.
- Use parent pending-art slots when the parent needs machine-consumable files, exact outputs, or artifacts that should materialize into the parent message-after-outgoing.
- Use parent pending-art slots when the parent resume actor may not have local disk access to inspect child thread files.
- GPT is a remote actor without local disk access. If GPT is expected to resume the parent after blocked-on-children and consume child outputs, parent pending-art slots are required for those outputs.
- Use child-thread inspection when the resumed parent actor has local disk access and the child results are primarily narrative, review findings, smoke summaries, decisions, or other thread-message content.
- If no parent pending-art slots are declared and the resumed parent actor has local disk access, the resumed parent actor should use the `Created Threads` section in the parent message-after-outgoing as the authoritative child-discovery record, inspect the listed child thread files, and summarize the child outcomes in the parent thread.
- Do not rely on child-thread inspection for required machine-consumable artifacts when pending-art slots would provide a clearer and safer handoff.
- If the child output must be consumed by automation or by a remote actor, use parent pending-art slots.
- If the child output only needs human-readable synthesis by a local actor, child-thread inspection is usually sufficient.
- If using child-thread inspection instead of pending-art slots, the parent-resume turn must read the child thread files, extract the required outputs, and complete the parent deliverable before any completion verification or termination.
- When aggregating child-thread text into a parent result, preserve the child text exactly. If non-ASCII punctuation appears, verify the aggregated output is encoding-clean before publication.
- If the parent actor is also a contributor in a fan-out collection, the parent actor may contribute directly in the parent-resume message when a canonical artifact is not required.
- If uniform artifacts are required, publish the parent actor's contribution as `ART:` plus `ATTACHED:` in the parent-resume message rather than creating a self-child thread.

Depth guidance:
- Avoid turning review or smoke child threads into implementation-fix parent threads unless the assigned message explicitly asks to continue implementation in that child.
- If a smoke or review child finds implementation blockers, route the findings back to the thread Owner or implementation actor.
- Implementation fixes should normally continue in the implementation parent or a newly appropriate implementation child, not inside the smoke/review child.
