memory(feedback): kernel-pipe vs JS-space stream ordering — TS+Bun port pattern

[AceHack]

Summary

• Captures the substrate finding from PR ts(B-0086): port 1 budget script (.sh→.ts) — slice 18 of TS/Bun migration #901 (slice 18) Copilot P1 round 2 as durable memory per Otto-363 substrate-or-it-didn't-happen
• Pattern: shell-side bash -c \"<cmd> 2>&1\" (preserves chronological ordering) vs JS-space result.stdout + result.stderr concat (loses ordering)
• New memory file + 1-line MEMORY.md index entry

Test plan

• memory file follows the auto-memory frontmatter format (name/description/type)
• MEMORY.md entry under 200 chars per CLAUDE.md guidance
• CI: lint (markdownlint) passes
• CI: lint (no conflict markers) passes

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds a durable memory entry documenting a TS+Bun porting pitfall: preserving mixed stdout/stderr chronological ordering when translating bash $(... 2>&1) to spawnSync.

Changes:

• Added a new memory/feedback_*.md write-up explaining kernel-pipe (2>&1) vs JS-space stdout+stderr concatenation ordering differences.
• Added a new top-level index entry in memory/MEMORY.md pointing to the new memory file.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
memory/feedback_kernel_pipe_vs_js_space_stream_ordering_ts_bun_port_pattern_2026_04_30.md	New memory capturing the porting pattern + rationale and examples.
memory/MEMORY.md	Adds an index bullet linking to the new memory file.

[Copilot]

P1: This new MEMORY.md index entry is far longer than the repo’s documented “keep entries terse / ~200 chars” guidance, which makes the index harder to scan and increases the risk of truncation issues. Consider shortening this bullet to a title + very short hook and move the detailed rationale into the linked memory file body (which already contains it).

Suggested change

- [**Kernel-pipe vs JS-space stream ordering — TS+Bun port pattern (Otto, 2026-04-30)**](feedback_kernel_pipe_vs_js_space_stream_ordering_ts_bun_port_pattern_2026_04_30.md) — TS+Bun port discipline: when porting bash `$(... 2>&1)` to `spawnSync`, merge stdout+stderr via shell-side `bash -c "<cmd> 2>&1"` (preserves chronological ordering at the kernel pipe boundary), NOT `result.stdout + result.stderr` concat in JS-space (loses ordering when child interleaves writes). Origin: PR #901 slice-18 Copilot P1 round 2. Composes with `classifySpawnFailure` 4-case helper + Otto-363 substrate-or-it-didn't-happen.

- [**Kernel-pipe vs JS-space stream ordering — TS+Bun port pattern (Otto, 2026-04-30)**](feedback_kernel_pipe_vs_js_space_stream_ordering_ts_bun_port_pattern_2026_04_30.md) — Port bash `2>&1` to shell-side stderr/stdout merge in `spawnSync`; never concat `stdout` + `stderr` in JS.

[Copilot]

P1: The frontmatter description reads like an absolute “never concat stdout+stderr in JS-space”, but the body later calls out cases where appending result.stderr is necessary to surface shell-side parse errors. Consider tightening the wording here to clarify the rule is about preserving child stdout/stderr interleaving (kernel-pipe 2>&1) while optionally appending result.stderr for shell diagnostics when relevant.

Suggested change

	description: When porting bash command-substitution with `2>&1` to TypeScript via `spawnSync`, must merge stdout+stderr at the kernel pipe boundary (shell-side `2>&1`), NOT in JS-space by concatenating `result.stdout + result.stderr` — JS-space concat loses chronological ordering when child interleaves stdout/stderr writes.
	description: When porting bash command-substitution with `2>&1` to TypeScript via `spawnSync`, preserve child stdout/stderr interleaving by merging at the kernel pipe boundary (shell-side `2>&1`), not by reconstructing child output as `result.stdout + result.stderr` in JS-space; append `result.stderr` separately only when shell-side diagnostics such as parse errors must also be surfaced.

[Copilot]

P1: The example interpolates path directly into the bash -c command string. Even if callers usually pass trusted paths, this pattern is easy to cargo-cult into contexts where the value is user-influenced, creating quoting/injection risk. Consider documenting the safer pattern of passing the path as a positional parameter to bash -c (so quoting is handled without string interpolation) and note that interpolation is only acceptable when the value is fully trusted/constructed.