Summary
cli-entry.ts already decides whether stdout is a TTY (options.isTty ?? (() => process.stdout.isTTY === true)) to pick color for rendered documents, but nothing of that reaches route code: CliRouteProps / ScriptRouteProps are { input | argv, signal } and the agent context has no IO/terminal capability. A plugin that emits anything itself (progress on stderr, a streamed child process's output, ANSI-bearing text) has to re-implement TTY and NO_COLOR/FORCE_COLOR/CLICOLOR/TERM detection per fd. cargo-hauler does this in src/client/exec.ts (colorEnabled(env, process.stderr.isTTY)), and every other plugin with a hot path outside the rendered document will too.
Request
Add a read-only capability on the agent context (and to ScriptRouteProps for plain/rendered scripts), e.g.
context.io: {
stdout: { isTTY: boolean; color: boolean; columns: number | null };
stderr: { isTTY: boolean; color: boolean; columns: number | null };
sharesTarget: boolean; // fd 1 and fd 2 are the same open file (2>&1 shape)
}
computed once by the framework with the same rules cli-entry.ts uses (so plugin output and framework output agree), and overridable in the in-process test harness (test/cli.ts, test/script.ts already have an isTty knob — this is the same knob, surfaced). Where Effect's Terminal service (effect/Terminal, provided by @effect/platform-node NodeTerminal) applies — columns/rows, line input for interactive scripts — back it with that rather than a parallel implementation; note Terminal.display is string-only and stdout-only, so it does not replace raw two-channel byte forwarding, which is why the capability should be information, not a writer.
Non-goals
Not asking the framework to take over stdout for plain scripts; docs/entry-conventions.md's "ordinary Node stdout/stderr semantics" for src/scripts/** is right. Just the detection.
Version
agent-bundle preview 42539ff5f (main).
Summary
cli-entry.tsalready decides whether stdout is a TTY (options.isTty ?? (() => process.stdout.isTTY === true)) to pick color for rendered documents, but nothing of that reaches route code:CliRouteProps/ScriptRoutePropsare{ input | argv, signal }and the agent context has no IO/terminal capability. A plugin that emits anything itself (progress on stderr, a streamed child process's output, ANSI-bearing text) has to re-implement TTY andNO_COLOR/FORCE_COLOR/CLICOLOR/TERMdetection per fd. cargo-hauler does this insrc/client/exec.ts(colorEnabled(env, process.stderr.isTTY)), and every other plugin with a hot path outside the rendered document will too.Request
Add a read-only capability on the agent context (and to
ScriptRoutePropsfor plain/rendered scripts), e.g.computed once by the framework with the same rules
cli-entry.tsuses (so plugin output and framework output agree), and overridable in the in-process test harness (test/cli.ts,test/script.tsalready have anisTtyknob — this is the same knob, surfaced). Where Effect'sTerminalservice (effect/Terminal, provided by@effect/platform-nodeNodeTerminal) applies —columns/rows, line input for interactive scripts — back it with that rather than a parallel implementation; noteTerminal.displayis string-only and stdout-only, so it does not replace raw two-channel byte forwarding, which is why the capability should be information, not a writer.Non-goals
Not asking the framework to take over stdout for plain scripts;
docs/entry-conventions.md's "ordinary Node stdout/stderr semantics" forsrc/scripts/**is right. Just the detection.Version
agent-bundle preview
42539ff5f(main).