Prefixed output
A single script and a serial group inherit the terminal, so their output is untouched. A parallel group of two or more members pipes them so each line can say which script wrote it.
The prefix
The prefix is the member's script name in square brackets, followed by one space, in a colour that stays the same for the whole run. Names are not padded to a common width, so a line starts as soon as the bracket closes.
Six colours cycle in the order members are declared: cyan, magenta, green, yellow, blue, bright magenta. Red is left out, because a red prefix on an ordinary line reads as a failure the script never reported.
A group of one is not prefixed
A group with exactly one member runs that member with the terminal inherited, exactly as a single script would. There is nothing to disambiguate, and prefixing it would silently degrade a config that happens to wrap one script in a group.
Partial lines
Bytes are forwarded as they arrive, not held until a newline. A prompt that ends mid-line renders immediately rather than waiting for output that may never come.
When a different script writes while a line is still open, Rune injects a newline first, so two scripts never share a line. A carriage return re-emits the prefix, which keeps progress bars that redraw a single line readable.
Child bytes themselves are never rewritten. Whatever the tool emitted is what reaches the terminal, minus nothing.
Colour through the pipe
A piped process sees a pipe rather than a terminal, and most tools turn colour off when they do.
Rune detects colour support on its own output and forwards FORCE_COLOR to piped members, so tools
that honour it keep their colour.
NO_COLOR set to any value turns off Rune's own colour, including prefixes.
A member with interactive: true is not piped at all. It inherits the terminal, so it is not
prefixed and it detects colour for itself.
Broken pipes
When Rune's own output goes to a pipe that closes, such as rune run dev | head -20, it stops
writing, terminates the members, and exits. It does not keep running invisibly with nowhere to
write.
Encoding
Output is decoded incrementally, so a multi-byte character split across two reads is reassembled rather than corrupted. Bytes that are not valid UTF-8 pass through as they arrived.