debugger: the program's standard input #40
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
Through
runInTerminaland a loopback channel (section 3).Source
Acceptance criteria
tests/debug/Dependencies
None known.
Moved from the planning lists of the docs; the design record stays the specification.
[loop:torbscript] intake: in scope (author orion, label loop). Implements DEBUGGER.md section 20 / section 3 (the debugged program reads standard input through
runInTerminaland a loopback channel); the design record is the specification, no collision with CONCEPT "Open Questions". Touches the debugger andtests/debug/; needs an editor-side check in VS Code, so the acceptance criterion may need a testable stand-in, settled in refine. next: refine (queued)[loop:torbscript] refine: still queued behind the intake order. next: waiting (ready buffer full: #4, #163, #164, #223 are ready) until 2026-10-10T04:00:00Z
[loop:torbscript] claim refine by session:loop-torbscript-20261022 until 2026-10-23T01:30:00Z
[loop:torbscript] decided by the loop: (1) Opt-in, default unchanged. The adapter uses
runInTerminalonly when the client sentsupportsRunInTerminalRequest: trueininitializeand thelaunchasks for it withconsole: "integratedTerminal"or"externalTerminal"(the DAP attribute VS Code sends). Without it the stdio channel of DEBUGGER.md section 3 stays exactly as it is, so every existingtests/debug/session andbenchmarks/debugkeeps its output. Why: a user without a terminal-capable client loses nothing, and no existing contract changes. (2) Channel: the adapter listens on a loopback port (127.0.0.1, ephemeral) and sendsrunInTerminalwithtorb debug --debuggee --connect 127.0.0.1:<port>plus a one-time token the debuggee sends first; requests and answers are the same one-line JSON as today, but no U+001E framing is needed because the program output no longer shares the stream. The program then has the terminal for all three streams; the adapter stops producingoutputevents for it and reports exit via the channel. Why: this is what section 3 and 20 already name; the listening side is in the adapter (async,std/network), the connecting side needs blocking read/pending/flush inruntime/debug.c(kernel operations, a C table row each, not natives, per section 3), so no new std surface. (3) Seed: no. No syntax, no native,--connectis atorb debug --debuggeeflag the build does not use, no std name looked up by string. (4) Testable stand-in for VS Code: the editor-side run is not a gate; the gate is a session intests/debug/where the harness plays the editor (answersrunInTerminalby running the given command with its standard input from a<name>.stdinfile and its output captured). The VS Code check is a manual smoke test recorded in the PR description. Why: the existing piped-whole sessions cannot answer a reverse request, sotools/debug.shgets a small scripted-terminal mode; that is part of this item.[loop:torbscript] decided by the loop: Size is one PR as two Conventional Commits: (a)
feat(runtime): loopback connect, read, pending, flush inruntime/debug.candtorb debug --debuggee --connect, covered by a runtime/debugger test; (b)feat(debugger): adapter listener,runInTerminalrequest and its response,consolehandling,tools/debug.shscripted-terminal mode, thetests/debug/session, DEBUGGER.md sections 3 and 20 updated (the item leaves "Open", the "gives up its standard input" paragraph becomes the default-route caveat),skills/regenerated. Not split into issues: no step is separately useful or larger than ~1 PR. If the implementer finds the runtime half bigger than expected, it comments and splits just in time at that commit boundary.[loop:torbscript] refine: refined acceptance criteria (the issue body is unchanged; these supersede its two boxes). Goal: a debugged program reads standard input, through
runInTerminaland a loopback channel (DEBUGGER.md sections 3 and 20).runInTerminalandconsole: "integratedTerminal", the program reads standard input from the editor terminal while breakpoints, stepping andpausestill work over the loopback channel (manual VS Code smoke test noted in the PR; not a gate)runInTerminalsupport orconsole, nothing changes: all existingtests/debug/sessions pass with unchanged.expectedtests/debug/(the harness plays the editor terminal and feeds a<name>.stdinfile) in which the program reads a line and a breakpoint after the read is hitskills/regeneratedDesign record: DEBUGGER.md sections 3 and 20. Seed touch: no. Size: one PR, two Conventional Commits (see decisions above). Gate
gate.onis false, no issues created. Token usage of this worker: roughly 45k.next: implement
[loop:torbscript] claim implement by session:loop-torbscript-20261023 until 2026-10-23T04:29:29Z
[loop:torbscript] implement: PR #398 is open, two Conventional Commits (runtime/debug.c loopback channel, then the adapter's runInTerminal route), forge CI green on
d5bc267c(bootstrap, tier A with gates, tier B, seed pack, archives, playground, same-C check). A first CI round caught two bugs in my hand-written test (a slice off by one, and the exit hook not running on exit code 0 intorb debug --debuggee); both fixed. No seed touch, no refresh needed. Not smoke-tested in a real VS Code. Token usage: not measurable from inside the subagent run, see the session's usage. next: review