name	deep-system-trace
description	Instrument code with tagged log statements to trace data flow — no behavior changes. Use when investigating issues across layers, caching, or when asked to "trace" or "add debug logging".

Deep System Trace

Investigate a build or runtime issue by instrumenting code with log statements — without changing any semantics or behavior. Your remit is purely to trace data flow and explain what the code is doing AS IS.

Goal

Produce an audit trail: an ordered explanation of how the system arrived at the observed behavior. This might trace a value through transformations, a sequence of decisions that led to a code path, or the ordering of operations across scripts. Every link must be backed by observed log output.

Rules

Do not fix anything. Only add log/print/echo statements and read existing code. Do not change semantics, control flow, or behavior. When the root cause is found, stop and report. Do not apply the fix in the same session.
Tag every log line with a versioned slug. Choose a short, descriptive prefix for the trace (e.g. RNPATH). Every log you add gets this prefix plus a version number: [RNPATH-v1]. Whenever you modify that line or file, bump the version (e.g. [RNPATH-v2]). Without versioning, a stale log line from a cached build is indistinguishable from your new one.
Prove your logs ran. After each run, search output for your slug. A missing slug means caching or a dead code path — investigate which. Never assume changes took effect without evidence.
Bust caches proactively. Before each run, delete known caches for the project's build system that could serve stale artifacts. Document which caches you clear and why.
Log values, not just execution. Print the actual runtime value, the working directory, and how the value was derived — not just "reached line N".
Work incrementally. Start at the failure point, add logs, run, observe, then trace one step upstream. Repeat. Do not try to instrument everything at once.
Beware name reuse across layers. The same identifier may refer to different things in different scripts or languages. Verify each occurrence independently.
Maintain an investigation log using tasks. After each run cycle, record: what you logged, what you observed, what it tells you, and what to investigate next.

Workflow

Read the error. Identify the exact failure message and location.
Instrument the failure site. Log the relevant state at the point of failure, with a version slug.
Clear caches and run.
Check for your slug. If present, note the value. If absent, investigate why.
Trace upstream. Find where the observed state was produced or decided. Add a log there. Repeat from step 3.
Present the audit trail once every link from origin to failure is backed by an observed log line with the current version slug.

Presenting the trail

The audit trail has two kinds of content:

Evidence — raw log output and any captured run artifacts. Keep these as files on disk and reference them by path as needed. Do not reformat or polish.
Explanation — the inline prose that ties the evidence together and walks the reader through the trace. When the explanation points at a specific line of source code, include it with a few lines of surrounding context rather than a bare path:line string.

Deep System Trace

Goal

Rules

Do not fix anything. Only add log/print/echo statements and read existing code. Do not change semantics, control flow, or behavior. When the root cause is found, stop and report. Do not apply the fix in the same session.

Tag every log line with a versioned slug. Choose a short, descriptive prefix for the trace (e.g. RNPATH). Every log you add gets this prefix plus a version number: [RNPATH-v1]. Whenever you modify that line or file, bump the version (e.g. [RNPATH-v2]). Without versioning, a stale log line from a cached build is indistinguishable from your new one.

Prove your logs ran. After each run, search output for your slug. A missing slug means caching or a dead code path — investigate which. Never assume changes took effect without evidence.

Bust caches proactively. Before each run, delete known caches for the project's build system that could serve stale artifacts. Document which caches you clear and why.

Log values, not just execution. Print the actual runtime value, the working directory, and how the value was derived — not just "reached line N".

Work incrementally. Start at the failure point, add logs, run, observe, then trace one step upstream. Repeat. Do not try to instrument everything at once.

Beware name reuse across layers. The same identifier may refer to different things in different scripts or languages. Verify each occurrence independently.

Maintain an investigation log using tasks. After each run cycle, record: what you logged, what you observed, what it tells you, and what to investigate next.

Workflow

Read the error. Identify the exact failure message and location.

Instrument the failure site. Log the relevant state at the point of failure, with a version slug.

Clear caches and run.

Check for your slug. If present, note the value. If absent, investigate why.

Trace upstream. Find where the observed state was produced or decided. Add a log there. Repeat from step 3.

Present the audit trail once every link from origin to failure is backed by an observed log line with the current version slug.

Presenting the trail

The audit trail has two kinds of content:

Evidence — raw log output and any captured run artifacts. Keep these as files on disk and reference them by path as needed. Do not reformat or polish.

Explanation — the inline prose that ties the evidence together and walks the reader through the trace. When the explanation points at a specific line of source code, include it with a few lines of surrounding context rather than a bare path:line string.

deep-system-trace