Exceptions and log lines on the step that produced them

Node anatomy

Nothing moves on a node that has no log lines. A node with lines gains a count badge in the footer, highest severity first; a failed node swaps its subtitle for the exception's type and message.

What the script author writes

One new global, Log, on every script surface (site scripts, shared scripts, inbound API methods, the Test Run editor). Always forwards to the node's logger; becomes a trace row only when the run is traced, so untraced production runs add no audit volume.

// ProcessRecipeDownload — site Call script (excerpt)
var recipeId = Parameters.Get<int>("RecipeId");
Log.Info($"Recipe {recipeId} requested for line {Parameters.Get<string>("Line")} by {Parameters.Get<string>("Requester")}");
Log.Debug("Writing header attributes then DownloadRequest");

await Children["DelmiaReceiver"].SetAsync("RecipeId", recipeId);
// … writes, wait …

var code = await Children["DelmiaReceiver"].GetAsync<int>("ResultCode");
Log.Info($"Galaxy answered: RecipeProcessedFlag = true, ResultCode = {code}");
if (code is not (0 or 1))
{
    Log.Warn($"ResultCode {code} is outside the accepted set {{0, 1}}");
    Log.Error($"Rejecting recipe {recipeId} (code {code})");
    throw new InvalidOperationException($"Recipe {recipeId} rejected by Galaxy (code {code})");
}
Log.Warn("Recoverable problem", caughtException);   // an exception on a line renders as an expandable chip

Where a line lands

Decision notes

1. Lines are audit rows, not a side channel. A new ScriptLog kind in the existing ScriptTrace channel rides the collector for Live and the audit store for Replay, with redaction, retention and the site 7-day purge applying unchanged. The graph builder folds them into their owning step; they are never drawn as nodes.
2. Untraced runs pay nothing. Log.* always writes to the node's ILogger at the given level (so it shows in Serilog and the site log as usual) and emits a row only when the run is traced. TraceAllCalls methods therefore gain lines in Replay at ~1 row per line.
3. Bounded by design. A per-run cap (200 lines, configurable) and a 2 000-character message cap sit at the API; past the cap lines are dropped and one closing runtime warning names the count. Inline, log rows are low-priority in the collector: they stop 50 events short of the 500 cap so the step rows emitted at run end are never crowded out, and the page shows log lines truncated inline — Replay is complete when that happens.
4. Attribution is explicit, never inferred from time. A row carries stepEventId or it belongs to the execution's anchor step. Steps whose row is written later by another actor (cached calls, notifications) keep the fallback.
5. Exceptions stay where they are already recorded. The failure row exists on every path today; it only lacked the detail. Adding errorDetail costs one argument on the site and one internal field centrally; the HTTP caller still receives the safe SCRIPT_ERROR body.
6. Selecting a failed node opens the Log tab. Every other node keeps Input as its first tab; the Output tab's red alert stays and links across.
7. Not in this slice: live streaming of lines during a long run (Live rows still arrive with the reply), a run-wide chronological log view (the register's Direction B list would host it), and node-logger enrichment by execution id.