Problem
MinimalDapClient.enrichChildConfig (src/proxy/minimal-dap.ts) writes our own launch/attach intent — request, stopOnEntry, and the attach extras (localRoot and friends) — into parentConfig, the same bag js-debug's raw reverse-request configuration arrives in. ChildSessionManager.createChildSession (src/proxy/child-session-manager.ts) then reads parentConfig?.stopOnEntry / parentConfig?.request back out, and buildChildStartArgs in packages/shared/src/adapter-policy-js.ts keeps a hand-maintained deny-list (request, stopOnEntry, the orchestration keys) so those keys do not ride into the child's DAP attach request.
Two owners share one object, and nothing ties the two lists together. Add one more intent key to enrichChildConfig (say justMyCode or breakOnExceptions, the natural follow-on to #704) and it leaks straight into the child's attach request unless the deny-list in a different package is updated in the same change. The tests pin which keys leak (localRoot yes, request/stopOnEntry no) only because one object serves two purposes.
After #712 the enricher is a ChildSessionManager option applied at the top of createChildSession, which preserves the dual use rather than removing it.
Proposed direction
Give ChildSessionManager the parent's start intent explicitly — e.g. a parentStart option/getter recorded where lastStartRequestArgs is set (minimal-dap.ts ~572) — and pass attach extras to buildChildStartArgs as their own argument. parentConfig then stays what js-debug sent, the deny-list becomes unnecessary (nothing of ours is in that object to strip), and adding an intent key is a one-package change with the type system pointing at every consumer.
Follow-up to #712 / #721 (raised in that PR's review). Not a bug today; a maintenance trap.
Problem
MinimalDapClient.enrichChildConfig(src/proxy/minimal-dap.ts) writes our own launch/attach intent —request,stopOnEntry, and the attach extras (localRootand friends) — intoparentConfig, the same bag js-debug's raw reverse-request configuration arrives in.ChildSessionManager.createChildSession(src/proxy/child-session-manager.ts) then readsparentConfig?.stopOnEntry/parentConfig?.requestback out, andbuildChildStartArgsinpackages/shared/src/adapter-policy-js.tskeeps a hand-maintained deny-list (request,stopOnEntry, the orchestration keys) so those keys do not ride into the child's DAP attach request.Two owners share one object, and nothing ties the two lists together. Add one more intent key to
enrichChildConfig(sayjustMyCodeorbreakOnExceptions, the natural follow-on to #704) and it leaks straight into the child's attach request unless the deny-list in a different package is updated in the same change. The tests pin which keys leak (localRootyes,request/stopOnEntryno) only because one object serves two purposes.After #712 the enricher is a
ChildSessionManageroption applied at the top ofcreateChildSession, which preserves the dual use rather than removing it.Proposed direction
Give
ChildSessionManagerthe parent's start intent explicitly — e.g. aparentStartoption/getter recorded wherelastStartRequestArgsis set (minimal-dap.ts~572) — and pass attach extras tobuildChildStartArgsas their own argument.parentConfigthen stays what js-debug sent, the deny-list becomes unnecessary (nothing of ours is in that object to strip), and adding an intent key is a one-package change with the type system pointing at every consumer.Follow-up to #712 / #721 (raised in that PR's review). Not a bug today; a maintenance trap.