Command purpose:
- Use `CMD: create_thread` when the assigned work requires SYS to create exactly one new thread.
- `create_thread` may create either a root thread or a child thread.
- Create a root thread when the new work is independent and should not block the current thread.
- Prefer same-thread handoff for narrow tasks.
- Same-thread handoff can still preserve role separation; for example, implementation, smoke, review, and synthesis may be routed across different actors inside the parent thread when no separate child lifecycle is needed.
- Create a child thread when the new work is a subtask of the current thread contract, the parent should pause until the child is Closed, and the orchestration overhead is justified.
- A single child thread is usually justified only when the child task is substantial, long-running, independently reviewable, likely to need multiple iterations, or expected to require a substantial multi-message lifecycle, roughly 10 or more messages as a rule of thumb.
- Do not create a child thread for a narrow one-step implementation, smoke, or review action unless parallelism, artifact isolation, authority boundaries, remote-actor artifact access, or parent/child lifecycle separation clearly require it.
- Creating a root thread does not create a blocked-on-children dependency.
- Creating a child thread creates a direct child relationship and blocks the assigned parent thread while the child remains Open.
- Open means Bucket `H`, `A`, or `P`.
- Closed means Bucket `C`.
- Parked means Bucket `P`. Parked threads are Open but non-runnable.
- A parked child still blocks its parent, but will not run until moved to `H` or `A`.

Required parameter order:

CMD: create_thread
thread_bucket: <H | A | P>
parent_thread_id: <parent thread ID or ->
thread_topic: <thread topic, at most 32 characters>
thread_priority: <P0 | P1 | P2 | P3>
thread_owner: <valid KBOS actor code>
thread_next_actor: <valid KBOS actor code>
thread_m0_body:
BEGIN
**Goal**
<goal for the new thread>

**Task**
<task for the assigned actor = thread_next_actor>

**Deliverable**
<deliverable for the new thread>
<if applicable, identify target artifact slots by message ID and filename, and instruct fulfillment using ART plus ATTACHED without raw standalone protocol example lines>

**Constraints**
<constraints for the new thread>
END
parent_thread_pending_art:
BEGIN
(none)
or
ART: <expected message-after-outgoing ID> <filename>
PENDING: {kbos_path}\threads\t#\m#\<filename>
END

Parameter selection:

thread_bucket:
- Use `A` for ordinary child work that should run as soon as scheduling allows.
- Use `H` only when the new thread is urgent and should be preferred over normal Active work.
- Use `P` only when deliberately creating a non-runnable parked thread.
- Do not use `P` for MRC child threads that are expected to run immediately.
- Do not use `P` merely to stage child work in a fan-out batch.
- If a parent must wait for child results, and the child results should be produced now, use `A` or `H`, not `P`.
- A child in `P` is still Open and still blocks the parent, but it will not be selected for normal actor progress.
- Creating a parked child intentionally creates a blocked-on-parked-bucket condition for the parent until the child is moved to `H` or `A`, or otherwise closed.

parent_thread_id:
- Use `-` for root-thread creation.
- Use the assigned thread ID for child-thread creation.
- When asked to create a child thread, do not copy or infer a parent thread ID from prior examples, earlier thread history, or task wording.
- Use the assigned thread ID shown in the assigned-message context.
- A root thread is independent and does not block the current thread.
- A child thread is part of the current thread contract and blocks the parent while the child remains Open.

thread_topic:
- Use a concise topic that describes the new thread contract.
- The topic must be at most 32 characters.
- Prefer a specific topic over a vague one.
- For child threads, the topic should identify the subtask or contributor, such as `GPT haiku`, `DEX smoke`, or `LAU review`.
- Do not include routing, bucket, priority, or message-ID metadata in the topic.

thread_priority:
- Use the priority that matches the urgency and importance of the new thread.
- For child threads, normally inherit the parent priority unless there is a clear reason to adjust it.
- Use `P0` only for urgent, blocking, or correctness-critical work.
- Use `P1` for normal important work.
- Use `P2` or `P3` for lower-priority smoke, exploratory, or optional work.
- Do not change priority merely because the thread is a child.

thread_owner selection:
- The actor that requests thread creation is the thread owner.
- The owner is accountable for the new thread contract.
- The owner may assign the first turn to another actor using `thread_next_actor`.
- The owner verifies completion and terminates the thread when the contract is done.
- Do not infer owner from the first execution actor.
- For root threads, the owner should be the actor most logically accountable for the independent root-thread contract.
- For child threads, the requesting actor becomes the child thread owner and remains accountable for child completion and result return.

thread_next_actor:
- Choose the actor that should perform the first turn in the new thread.
- `thread_next_actor` may be different from `thread_owner`.
- Use the actor with the right capability for the child task.
- Do not route to SYS unless the new thread's first task is actually a supported SYS procedural command.
- Do not route to VLD unless the first task requires human decision authority.

thread_m0_body:
- `thread_m0_body` is the kickoff body for the new thread.
- It must be body-only and must not include runner-owned metadata such as ID, DATE, KBCP, FROM, TO, or anchor tags.
- It must include exactly these required sections:
  - `**Goal**`
  - `**Task**`
  - `**Deliverable**`
  - `**Constraints**`
- The `**Task**` section should be written for the actor named by `thread_next_actor`.
- The `**Deliverable**` section should make the expected output explicit.
- The `**Constraints**` section should include exactness, artifact, no-newline, routing, or scope constraints when they matter.
- If the child thread is expected to fulfill pending artifacts, identify each target artifact by message ID and filename.
- If the child thread is expected to fulfill pending artifacts, instruct the child to fulfill the slot using `ART:` plus `ATTACHED:`.
- Do not include raw standalone `ART:`, `ATTACHED:`, or `PENDING:` example lines inside `thread_m0_body` unless they are intended to be parsed as actual artifact protocol lines in the child message.
- When explaining the target slot inside `thread_m0_body`, prefer prose or inline-code references such as `T271M7 pending_art_hello.txt`.

parent_thread_pending_art:
- `parent_thread_pending_art` declares delayed-materialization artifact slots on the expected message-after-outgoing.
- The message-after-outgoing is the immediate next message in the same parent thread after your outgoing `CMD: create_thread` message.
- If your assigned message is `T#MN` and your outgoing message is `T#M(N+1)`, then the expected message-after-outgoing is `T#M(N+2)`.
- `parent_thread_pending_art` must contain either `(none)` or one `ART:` plus `PENDING:` pair per pending artifact slot.
- Use `(none)` for root-thread creation.
- Use `(none)` for child-thread creation when the parent will consume child results through child-thread inspection.
- Use pending-art slots when the parent needs machine-consumable files, exact outputs, or artifacts that should materialize into the parent message-after-outgoing.
- Use 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.
- For child-thread creation with pending parent artifacts, each `ART:` line must reference the expected message-after-outgoing ID.
- For child-thread creation with pending parent artifacts, each `PENDING:` line must use the canonical destination path for the preceding `ART:` line.
- `PENDING:` lines must use the canonical destination path encoded by the preceding `ART:` line, relative to `{kbos_path}`.
- `ART:` alone means already materialized.
- `ART:` plus `PENDING:` means declared now and materialized later by descendant work before the parent consumes the message-after-outgoing after thaw.
- If no parent pending-art slots were declared and the resumed parent actor has local disk access, the resumed parent actor may inspect child thread files to reconstruct child results and summarize them in the parent thread.

Create-thread message semantics:
- When SYS materializes `CMD: create_thread`, the parent message-after-outgoing must include a `Created Threads` section listing the created direct child thread ID and topic.
- When the parent thread later resumes after blocked-on-children, the assigned actor may use that `Created Threads` section as the authoritative child-discovery record.
- A discovered child thread ID `T###` resolves to the canonical child thread file path `{kbos_path}\threads\t###\t###.md`, where `{kbos_path}` is the configured KBOS system-of-record root.
- If no parent pending-art slots were declared, the assigned actor may inspect the listed child thread file to reconstruct child results and summarize them in the parent thread.
- If parent pending-art slots were declared, the resumed parent actor should consume the materialized pending-art files from the parent message-after-outgoing.
- A child-thread completion or termination instruction applies only to that child thread.
- The parent thread must still complete its own contract after all direct children are Closed.
- Do not infer that the parent thread should terminate merely because its child threads are Closed.
- If the parent deliverable requires synthesis, aggregation, inspection, or presentation to a recipient, the parent-resume actor must complete that deliverable before any completion verification or termination.
- If creating an MRC child that should run immediately, choose `thread_bucket: A` or `thread_bucket: H`.
- Prefer same-thread handoff instead of child creation when the work can be completed as a narrow linear step without meaningful lifecycle separation.
- Child creation is usually not justified for a one-step implementation, smoke, or review action that is likely to complete in one assignee turn plus one owner verification turn.
- Use child creation for narrow work only when parallelism, artifact isolation, authority boundaries, remote-actor artifact access, or parent/child lifecycle separation clearly outweigh the overhead of creating, closing, and resuming a child thread.
- If creating a child in `P`, state in the assigned task why the child is deliberately parked and who or what is expected to move it out of `P`.

Required output rules:
- Route the outgoing message to SYS only.
- After the `TO: SYS` routing line and blank line, start the message body with `CMD: create_thread`.
- Do not include extra prose, notes, headings, or sections beyond the required parameters.
- Use the exact CMD and parameter names.
- Use the exact parameter order shown above.
- Every parameter is required.
- Use scalar parameter syntax for scalar fields.
- Use `BEGIN` and `END` blocks for multiline fields.
- `BEGIN` and `END` must appear alone on their own lines.
- `thread_m0_body` must include the required kickoff sections: `**Goal**`, `**Task**`, `**Deliverable**`, and `**Constraints**`.
- `parent_thread_pending_art` must contain either `(none)` or valid `ART:` plus `PENDING:` pairs.
- For root-thread creation, `parent_thread_pending_art` must be `(none)`.
- For child-thread creation with no pending parent artifacts, `parent_thread_pending_art` must be `(none)`.
- For child-thread creation with pending parent artifacts, each `ART:` line must reference the expected message-after-outgoing ID.
- For child-thread creation with pending parent artifacts, each `PENDING:` line must use the canonical destination path for the preceding `ART:` line.
