Artifact handling rules:
- `ART:` is the mandatory artifact identity line.
- `ART:` always uses this canonical form:
  ART: T#M# filename
- The `T#M#` value identifies the canonical message-local artifact directory.
- The filename must be a bare filename, not a path.
- The canonical artifact path is:
  D:\kbos\threads\t#\m#\filename

ART modes:
- `ART:` alone references an existing canonical artifact.
- `ART:` immediately followed by `ATTACHED:` materializes a source file now into the canonical artifact path, then references it.
- `ART:` immediately followed by `PENDING:` declares a delayed-materialization artifact slot, then references it.

ART-only reference:
- Use `ART:` alone when the artifact already exists at the canonical artifact path.
- Do not add `ATTACHED:` when only referencing an already materialized artifact.
- Do not add `PENDING:` when only referencing an already materialized artifact.

ART+ATTACHED publication:
- Use `ART:` followed immediately by `ATTACHED:` when publishing a source file now.
- Use this exact shape:
  ART: T#M# abc.txt
  ATTACHED: <source path or URL>
- If `T#M#` is the outgoing message ID, this is normal same-message artifact publication.
- For normal same-message artifact publication, do not use the assigned message ID.
- The assigned message ID is the message being processed. The outgoing message ID is the message being published. Same-message `ART:` plus `ATTACHED:` lines must use the outgoing message ID.
- If `T#M#` is not the outgoing message ID, this is cross-thread artifact fulfillment.
- Cross-thread artifact fulfillment is allowed only when the target `T#M# filename` was previously declared with `ART:` plus `PENDING:`.
- For cross-thread artifact fulfillment, the target `T#M#` must be an ancestor blocked-on-children message, or another explicitly allowed target.
- For cross-thread artifact fulfillment, the canonical destination must not already exist.
- Do not use cross-thread `ART:` plus `ATTACHED:` unless the assigned work explicitly requires fulfilling a pending artifact slot.

ART+PENDING declaration:
- Use `ART:` followed immediately by `PENDING:` when declaring an artifact slot that will be materialized later.
- Use this exact shape:
  ART: T#M# abc.txt
  PENDING: D:\kbos\threads\t#\m#\abc.txt
- The `PENDING:` path must be the canonical destination encoded by the `ART:` line.
- `PENDING:` declares delayed materialization. It does not publish a source file now.
- A pending artifact slot may be fulfilled only once.
- After fulfillment, the materialized artifact is immutable.

`ATTACHED:` line format:
- Each `ATTACHED:` line must contain exactly one local file path or exactly one http/https URL.
- The path or URL must end at the end of the line.
- Do not append narration, explanation, punctuation, status text, or any other content after the path or URL.
- Any trailing non-whitespace text after the path or URL invalidates the line.
- Before finalizing any `ART:` plus `ATTACHED:` pair, verify the `ATTACHED:` line meets the format above.

`PENDING:` line format:
- Each `PENDING:` line must contain exactly one canonical KBOS destination path.
- The path must end at the end of the line.
- Do not append narration, explanation, punctuation, status text, or any other content after the path.
- Any trailing non-whitespace text after the path invalidates the line.

Content and naming rules:
- If the latest assigned message requests analysis, recommendations, wording changes, templates, or sectioned prose, return them in the message body by default.
- Do not create a new artifact unless the latest assigned message explicitly requests artifact publication or a file deliverable.
- Prefer stable, descriptive artifact filenames. Do not encode the assigned message ID into a new artifact filename unless disambiguation is needed.
- Artifact filenames published or referenced by one outgoing message must be unique within that message.
- If multiple needed artifacts share the same base name, disambiguate the `ART:` filenames, preferably with the outgoing message ID prefix, for example `t136m3_`.
- Every file attached to the thread message must have a standard filename extension, for example `.txt`, `.pdf`, `.jpg`, `.png`, `.md`, `.html`, `.csv`, `.json`, `.py`, or `.diff`.
- For log output, smoke output, console output, or command transcripts, use `.txt`, not `.log`.
- Do not attach extensionless files.
- Do not attach empty files. A 0-byte file must not be published as an artifact.
- For exact-content artifact tasks, treat “content must be exactly X” as byte-exact content with no trailing newline unless the assigned message explicitly requests one.
- When creating an exact-content artifact, use a no-newline or byte-exact write method and verify the byte count or raw bytes before attaching.
- When copying or aggregating text into an artifact, preserve the source text encoding exactly. If non-ASCII punctuation appears, verify the artifact bytes are encoding-clean before attaching.

Artifact reuse rule:
- If an artifact was already published earlier and you are only referencing it for the next actor, use `ART:` only.
- Do not add `ATTACHED:` unless the file is being newly materialized in this outgoing message.
- If the file was not produced this turn and does not need pending-slot fulfillment, it must not carry an `ATTACHED:` line.
- Before writing any `ATTACHED:` line, ask: "Is this file already materialized as a canonical artifact?" If yes, use `ART:` only and do not add `ATTACHED:`.
- Before adding `ATTACHED:`, check whether the same artifact is already present in the thread from an earlier message.
- When a later message publishes an artifact with the same filename as an earlier artifact, treat the later artifact as superseding the earlier artifact for normal handoff purposes.
- In an outgoing message, reference only the latest relevant artifact for that filename unless the assigned task explicitly requires version comparison or historical review.
- Do not include multiple ART lines with the same filename in one message.

Iteration attachment rule:
- On follow-up iterations, attach only artifacts that are new, changed, or required to fulfill a declared pending artifact slot in the current outgoing message.
- If an unchanged artifact from an earlier message is still needed by the next actor, reference it with `ART:` only.
- Do not reattach unchanged prior artifacts merely to provide a complete review set.

Scope and permissions:
- The authoritative published artifact is the copy materialized into the canonical message-local artifact directory identified by the `ART:` line.
- Use only surface-supported `ATTACHED:` source forms.
- {actor_name} may use `ATTACHED:` in the outgoing message only with a file path {actor_name} has read permission for this turn, or an http/https URL. Permission to read means permission to attach.
- If a local `ATTACHED:` path is outside {actor_name}'s allowed read roots for this turn, fail closed.
- Include only the `ART:` lines the next actor still needs for reliable completion of the governing task.
- Prefer referencing existing artifacts with `ART:` over reattaching unchanged files.
- Omit unneeded incoming `ART:` lines by default.
- When deciding whether the next actor still needs an artifact, use the governing task and the current handoff, not bookkeeping habit or thread pattern alone.

Artifact publication check:
- Before publishing any `ART:` line with `ATTACHED:`, confirm whether it is normal same-message publication or cross-thread pending artifact fulfillment.
- The assigned message ID is the read anchor. It identifies the message currently being processed.
- The outgoing message ID is the publish anchor. It identifies the message currently being written.
- For normal same-message publication, the `ART:` line must use the outgoing message ID, never the assigned message ID.
- Before finalizing any normal same-message `ART:` plus `ATTACHED:` pair, verify that the `T#M#` value exactly matches the outgoing message ID shown in the assigned-message instructions.
- If the `T#M#` value does not match the outgoing message ID, the publisher will treat the pair as cross-thread or prior-message artifact publication.
- Do not use cross-thread `ART:` plus `ATTACHED:` merely to attach a file to the current response.
- For cross-thread pending artifact fulfillment, the `ART:` line must use the pending slot's target message ID.
- Cross-thread pending artifact fulfillment is valid only when the target `T#M# filename` was previously declared with `ART:` plus `PENDING:` and the assigned work explicitly requires fulfilling that pending slot.
