tractor/ai/prompt-io/claude/20260417T034918Z_9703210_prompt_io.raw.md

No code was produced in this turn — this is a design/planning exchange for subint spawner support per issue #379. Captured verbatim below are the two substantive AI responses, which together fix the phased plan (A: modularize, B: subint, C: harness) and the concrete Phase A file split before any implementation begins.

Turn 1 — initial triage + gating questions

Read: issue #379, current spawn/_spawn.py (847 lines), and pyproject pins.

Task summary

Design/plan/implement subint backend per #379, plus modularize spawn/_spawn.py into per-backend submods, plus harness flag for test parametrization.

Key finding

pyproject.toml:12 pins requires-python = ">=3.12, <3.14" — but concurrent.interpreters / PEP 734 only lands in 3.14. This is the load-bearing design question before coding.

Proposed phasing (incremental commits)

• Phase A — modularize _spawn.py: extract trio_proc → spawn/_trio.py, mp_proc → spawn/_mp.py, keep generic helpers (hard_kill/soft_kill/new_proc dispatcher/SpawnMethodKey) in a slim core. Tests green at each step.
• Phase B — _subint backend: extend SpawnMethodKey with 'subint'; reuse UDS transport by default; shm is escape-hatch follow-up.
• Phase C — harness: add backend-parametrize flag, skip subint when Python < 3.14.

Gating questions before I start

1. Python pin: bump <3.15 and feature-gate subint tests (a), require 3.14 outright (b), or backport shim (c)? I’d recommend (a).
2. PR strategy: one branch, commits per phase (current claude_bun_opus4.7_subint_spawner_backend)? Or split Phase A as its own PR first?
3. fork()-via-subint hack from the issue’s “Our own thoughts” section — v1 or follow-up? I’d defer to follow-up.
4. Prompt file line 32 is truncated — what’s the existing harness flag name you had in mind ("using the existing ___")?

Which of these are already decided vs. open?

User answers (for the raw record)

1. bump <3.15, feature-gate — option (a).
2. split Phase A as its own PR first.
3. defer fork()-via-subint hack.
4. harness flag is --spawn-backend CLI → start_method fixture, per tractor._testing._pytest. Prompt file updated accordingly.

Turn 2 — concrete Phase A plan

Good — prompt file now ends cleanly; harness flag confirmed as --spawn-backend CLI → start_method fixture (via _testing/pytest.py:193,355). Also noted pytest.py:345-349 hardcodes valid backends as a string tuple — typing.get_args(SpawnMethodKey) should drive that list.

Phase A — concrete plan (separate PR)

File split in tractor/spawn/: - _spawn.py stays as “core”: keeps SpawnMethodKey, _spawn_method, proc_waiter, try_set_start_method, exhaust_portal, cancel_on_completion, hard_kill, soft_kill, new_proc dispatcher, _methods registry. Kept at this path so _testing/pytest.py:228 and other external imports don’t break. - _trio.py ← trio_proc() (lines 448–671, ~224 lines) - _mp.py ← mp_proc() (lines 672–842, ~171 lines) - _methods dict imports the two backend fns from the new modules.

Commits (each green via /run-tests): 1. Drive _testing/pytest.py backend-tuple from get_args(SpawnMethodKey) — tiny prep. 2. Extract trio_proc → spawn/_trio.py; _methods imports it. 3. Extract mp_proc → spawn/_mp.py; _methods imports it. 4. Tidy spawn/__init__.py docstring to describe new layout.

No pyproject pin bump in Phase A (that’s Phase B).

Workflow: I’d run this in a new worktree via /open-wkt spawn_modularize (branch wkt/spawn_modularize), then open a PR before returning to the current claude_bun_opus4.7_subint_spawner_backend branch for Phase B/C.

Green-light to /open-wkt and start Phase A?

User final response

all this first then yes, green light.

— log this /prompt-io entry first, then proceed with Phase A in a worktree.