Skip to content

Start threads in another project, as a child or top-level #114

Closed
#126
Closed
Start threads in another project, as a child or top-level#114
#126

Description

@lukemaj
lukemaj
opened on Oct 1, 2026

What: An agent can start a thread in another project, either as a child that reports back or as an independent top-level thread.
Why: spawn_thread always creates the child in the parent's project and worktree, so the Promachos cannot send Drafters into a Satrapy repo, and agents cannot start top-level threads at all.
So what: An agent builds it; the Promachos and Wight mode depend on it for cross-Satrapy work.

Parent

#113

Outcome

From any thread, an agent starts a thread in a named project with a task, Color and runtime mode, as a child (hidden, reports back) or as a top-level thread (in that project's sidebar), and the new thread loads that project's own instructions.

Elon record

  • Requirements and who asked: Drafters start in any project, as a child or a top-level thread (user, 2026-10-01); agents start top-level threads in another project (Agents cannot start a top-level thread in another project #47, user, 2026-09-27).
  • Deleted: A target-specific routing policy; the parent's routing applies until a real task needs otherwise.
  • Bottleneck: thread.create in the threads toolkit uses parent.projectId, parent.branch and parent.worktreePath.
  • Checked myself: apps/server/src/mcp/toolkits/threads/handlers.ts:726-738; SpawnThreadInput has no project field.

Acceptance criteria

  • A child spawned into another project runs in that project, under its local-or-worktree setting, reports back to the parent, and stops with interrupt_thread.
  • A top-level thread started in another project appears in that project's sidebar and can be read and messaged afterwards.
  • The new thread's transcript shows it loaded the target project's AGENTS.md, not the parent's.

Non-goals

  • Machine placement across environments.
  • Per-target Prism routing.

Blocked by

None

Required proof

  • Focused server tests for both modes, plus one live run on the desktop build showing a child and a top-level thread in another project.

Supersedes #47.

Activity

  1. lukemaj
    added a parent issue on Oct 1, 2026

  2. lukemaj commented on Oct 1, 2026

    @lukemaj
    lukemaj
    on Oct 1, 2026
    ContributorAuthor

    What: #114 is being implemented on its exclusive branch; no PR has been opened yet.
    Why: spawn_thread currently inherits the caller's project, branch and worktree, preventing Drafters from running in another project's context.
    So what: The assigned writer will implement and prove both modes, then the coordinator will run isolated desktop acceptance and obtain independent review before delivering one PR against main.

    Canonical handoff

    • Authority: implementation, focused proof, one independently reviewed PR against main; no merge, no versioning, no daily-app changes.
    • Branch: feat/114-spawn-into-project.
    • Exclusive workspace: /Users/lukaszmaj/dev/toolboxmd/chromeria-worktrees/114-spawn-into-project.
    • Exact base and starting HEAD: 0db8b3f19549ef369a611883e111ae20760364c8, verified against live origin/main with git ls-remote.
    • Canonical checkout is read-only; sibling branches/resources are untouched.
    • Writer: T3 thread sub.sub.sub.65170a12-0252-434a-b1ad-926c423a623d.dispatcher-6bbc72e88f48.dispatcher-8422e388fab3.retry-225070bbc6ec (Prism retry route). Original worker settled idle before replacement and left no changes.
    • Required proof: focused server tests for child and top-level; isolated desktop run demonstrating target instructions, reportback, interrupt, top-level sidebar/read/message. Proof and exact-head independent review are pending.
    • Contribution to Objective: Drafters start in any project, as children or top-level threads.
    • Version: explicitly omitted by fleet rule; no policy adoption.
    • Delivery: no commits, push or PR yet. No release/installation/merge authority exercised.
    • Cleanup: unrelated worktrees listed read-only and preserved; no fleet resources stopped or deleted.

    Elon record

    Requirements and who asked: User requested cross-project child and top-level spawning, with the Issue's full acceptance and fleet proof.
    Deleted: Per-target routing; the caller's Prism routing remains the initial policy.
    Bottleneck: thread.create in the threads toolkit inherits the parent's project, branch and worktree.
    Checked myself: Coordinator inspected apps/server/src/mcp/toolkits/threads/handlers.ts at base 0db8b3f19549ef369a611883e111ae20760364c8, confirming routing uses parent.projectId and creation copies the parent workspace fields.

  3. lukemaj commented on Oct 1, 2026

    @lukemaj
    lukemaj
    on Oct 1, 2026
    ContributorAuthor

    What: #114 has one active writer implementing cross-project child and top-level spawning.
    Why: Creation currently inherits the caller workspace and project scope refuses cross-project top-level read/message access.
    So what: This coordinator owns acceptance, independent review and exactly one PR against main; installed desktop acceptance stays with the fleet coordinator, and no merge is authorized.

    Canonical handoff

    • Outcome contributes to the Objective: Drafters start in any project, as children or top-level threads.
    • Exclusive writer workspace: /Users/lukaszmaj/dev/toolboxmd/chromeria-worktrees/114-spawn-into-project, branch feat/114-spawn-into-project.
    • Base/starting HEAD: 0db8b3f19549ef369a611883e111ae20760364c8, clean and verified against live origin/main.
    • Writer: sub.sub.sub.46b03420-8643-4703-8756-8602f14b39fb.dispatcher-b307e728dc20.dispatcher-cf11ceba5ed3.worker-e5b9f300c5aa, role worker, hard lane, Prism-selected Codex GPT-6.1-Sol. Retired fleet threads will not be contacted.
    • Required API: simple target-project and child/top-level inputs, caller Prism policy retained, runtime mode supported; narrow access to caller-created top-level threads rather than all cross-project threads.
    • Workspace/instructions: target local/worktree preference and target instructions must hold through actual turn launch, not only thread.create.
    • Proof: focused server tests and permitted isolated backend runtime proof; browser/computer use unauthorized. Installed desktop child/top-level/sidebar/instructions checks remain for fleet coordinator.
    • Authority: implement, focused proof, independent review, commit/push and exactly one PR closing Start threads in another project, as a child or top-level #114 against main. No merge, installation or live-state changes. No versioning by design.
    • Dependencies: Wight mode: keep a thread working on continue #117 and Spectrum: start_spectrum with council and free modes #118 consume spawn_thread; input semantics documented in tool descriptions. No sibling branch writes or contacts.
    • State: no implementation commit, push or PR yet. Reviewer pending; writer owns next implementation action. Unrelated worktrees listed read-only and preserved.

    Elon record

    Requirements and who asked: User and #114 require cross-project child/reportback/interrupt and top-level/sidebar/read/message with target instructions and workspace preference.
    Deleted: Cross-environment placement, per-target Prism policy, broad cross-project access, another dispatcher and unnecessary parallel writers.
    Bottleneck: Spawn inherits caller placement; top-level threads need a narrow durable caller access path, plus target workspace setup through the turn launch.
    Checked myself: Read full #114/#113; inspected toolkit scope checks, create/start-turn path, sidebar subagent filter and existing server workspace bootstrap tests at the exact base; verified live origin/main and clean exclusive branch.

  4. lukemaj commented on Oct 1, 2026

    @lukemaj
    lukemaj
    on Oct 1, 2026
    ContributorAuthor

    What: #114 implementation is stopped because an unknown writer changed apps/server/src/mcp/toolkits/threads/tools.ts in the assigned workspace.
    Why: The workspace was clean at this coordinator's initial check, but the assigned worker found an overlapping diff before editing; it reported no writes and is now confirmed idle.
    So what: The fleet coordinator must identify the diff's owner and establish that writer is settled before this writer resumes; the diff is preserved unstaged.

    • Branch/HEAD remain feat/114-spawn-into-project / 0db8b3f19549ef369a611883e111ae20760364c8.
    • Observed diff adds projectId, child/top-level mode, runtimeMode and project selectors on thread access tools. File mtime: 2026-10-01 21:21:27 Europe/Warsaw.
    • This coordinator and its assigned worker did not edit tracked source. interrupt_thread confirmed no_active_run, statusAfter: idle for sub.sub.sub.46b03420-8643-4703-8756-8602f14b39fb.dispatcher-b307e728dc20.dispatcher-cf11ceba5ed3.worker-e5b9f300c5aa.
    • No retired or sibling threads contacted. No tests, commit, push or PR yet.
    • Pending after ownership: implementation, focused proof, exact-head independent reviewer findings and review/independent status, Agent Observer sync/publish, one PR against main closing Start threads in another project, as a child or top-level #114.

  5. lukemaj commented on Oct 1, 2026

    @lukemaj
    lukemaj
    on Oct 1, 2026
    ContributorAuthor

    What: #114 resumed with exclusive ownership of all inherited task edits and the original assigned worker as the only writer.
    Why: The user confirmed every retired writer is interrupted and idle as of 21:24 local; inherited changes are authorized task work.
    So what: The writer reviews and repairs inherited placement and access behavior, then the coordinator delivers exact-head independent review and one PR without merge.

    The previous unknown-writer blocker is resolved. Authorized inherited files: tools.ts, handlers.ts, spawnWorkspace.ts, handlers.testFixtures.ts under the threads toolkit. Writer identity and base remain as in the canonical handoff. No #122 parent/child stopping expansion is included.

    Latest user clarification supersedes the earlier narrow caller-created access recommendation: explicit projectId with scope: project may be the smallest consistent existing-scope extension. No creator metadata machinery is required; absent selectors retain existing behavior. Workspace fallback for non-repositories and absence of caller branch/worktree in cross-project turn launch are explicit proof targets.

    Requirements and who asked: #114 and user require target placement/instructions, child reportback/interrupt and top-level sidebar/read/message.
    Deleted: Creator-access metadata unless evidence requires it, cross-environment placement, per-target Prism policy and #122 scope.
    Bottleneck: Target workspace preparation and real launch context, including local fallback; existing project selectors are evaluated before adding new access machinery.
    Checked myself: Inspected all inherited tracked diffs and spawnWorkspace.ts; confirmed branch/base and four-file dirty state; resumed the sole writer through native message_thread.

  6. lukemaj commented on Oct 1, 2026

    @lukemaj
    lukemaj
    on Oct 1, 2026
    ContributorAuthor

    What: #114 is implemented and delivered as exactly one independently reviewed PR against main: #126.
    Why: Cross-project spawn now uses the destination's workspace preference and setup scripts, retaining child lifecycle and adding independent top-level threads with explicit project access.
    So what: The fleet coordinator performs installed desktop acceptance and decides merge; this task does not merge, install or release.

    Canonical handoff

    • PR: feat(server): spawn threads into another project #126, closes Start threads in another project, as a child or top-level #114, base main; exact head a16aa9d0099841102d71039e66f919b7bfc7ba02, base 0db8b3f19549ef369a611883e111ae20760364c8.
    • Branch/workspace: feat/114-spawn-into-project, /Users/lukaszmaj/dev/toolboxmd/chromeria-worktrees/114-spawn-into-project. Clean local HEAD and remote task head verified equal; origin/main unchanged. Workspace retained for review fixes. Canonical checkouts untouched.
    • Sole writer: sub.sub.sub.46b03420-8643-4703-8756-8602f14b39fb.dispatcher-b307e728dc20.dispatcher-cf11ceba5ed3.worker-e5b9f300c5aa (GPT-6.1-Sol / Codex); settled after commit. Inherited edits were reviewed under explicit ownership authorization.
    • Independent reviewer: sub.sub.sub.46b03420-8643-4703-8756-8602f14b39fb.dispatcher-b307e728dc20.dispatcher-cf11ceba5ed3.reviewer-e026cb63c976 (GPT-6-Luna / Codex); no blockers on exact head. Reviewer posted findings then review/independent: success; coordinator verified newest status creator lukemaj on the current head.
    • Proof: 15 spawn cases plus cross-project settlement passed (16 total, 59 skipped); 51 unchanged lifecycle/setup tests reused from prior combined run. Final server typecheck, targeted lint, diff check, provenance check passed. Exact commands/results and corrected fixture errors are in the PR.
    • Assumptions: explicit project selector uses target preference; absent selector retains child workspace inheritance; target HEAD is worktree base; setup failures are visible but allow agent launch; explicit project scope extends existing model without creator metadata. Caller Prism policy retained. No cross-environment placement or Stopping a thread does not stop its children; report-backs revive it #122 expansion.
    • Objective contribution: Drafters start in any project, as children or top-level threads.
    • Version: no versioning by design.
    • Delivery: committed/pushed/one PR linked natively; no merge, install or release. No browser/computer use, pairing tokens, port 3773 or live state used. No task server to clean up.
    • Remaining acceptance for fleet coordinator: actual provider transcript loading target AGENTS.md; installed desktop sidebar visibility and child/top-level reportback, interrupt, read and message. Backend tests use real engine/projections/provider reactor with fake provider boundary. CI state remains visible on PR.
    • Agent Observer: cost comment published; attribution gap recorded, zero attributed responses is not a measured $0 task cost. No out-of-scope Observer repair.
    • Wight Wight mode: keep a thread working on continue #117/Spectrum Spectrum: start_spectrum with council and free modes #118 API: optional projectId, mode child/top-level, runtimeMode; follow-up top-level tools use scope project + projectId. Documented in tool descriptions. No sibling or retired threads contacted.

    Elon record

    Requirements and who asked: User/#114 require target placement/instructions, child reportback/interrupt and top-level sidebar/read/message with target workspace preference.
    Deleted: Cross-environment placement, target Prism policy, creator metadata machinery, extra dispatchers/parallel writers and #122 scope.
    Bottleneck: Target workspace and setup before provider launch, plus explicit project selection for follow-up access.
    Checked myself: Complete inherited and final diff, provider cwd and sidebar consumers, clean Git/live remote identity, reviewer findings and exact-head success status, native PR link and published cost limitation.

  7. lukemaj commented on Oct 1, 2026

    @lukemaj
    lukemaj
    on Oct 1, 2026
    ContributorAuthor

    What: #114 is implemented and delivered as exactly one independently reviewed PR against main: #126.
    Why: Cross-project spawn now uses the destination's workspace preference and setup scripts, retaining child lifecycle and adding independent top-level threads with explicit project access.
    So what: The fleet coordinator performs installed desktop acceptance and decides merge; this task does not merge, install or release.

    Canonical handoff

    • PR: feat(server): spawn threads into another project #126, closes Start threads in another project, as a child or top-level #114, base main; exact head e740c6c7cc4357573d5af3bb2f56a4049c22240c, base 0db8b3f19549ef369a611883e111ae20760364c8.
    • Branch/workspace: feat/114-spawn-into-project, /Users/lukaszmaj/dev/toolboxmd/chromeria-worktrees/114-spawn-into-project. Clean local HEAD and remote task head verified equal; Live main advanced to 93bcc9b57fd1520cddc3944952d6a8fea1beaec3 through fix(web): open Issue links beside their thread #124; reviewer confirmed cumulative candidate compatibility, with only disjoint provenance feature entries overlapping. No rebase needed or performed. Workspace retained for review fixes. Canonical checkouts untouched.
    • Sole writer: sub.sub.sub.46b03420-8643-4703-8756-8602f14b39fb.dispatcher-b307e728dc20.dispatcher-cf11ceba5ed3.worker-e5b9f300c5aa (GPT-6.1-Sol / Codex); settled after commit. Inherited edits were reviewed under explicit ownership authorization.
    • Independent reviewer: sub.sub.sub.46b03420-8643-4703-8756-8602f14b39fb.dispatcher-b307e728dc20.dispatcher-cf11ceba5ed3.reviewer-e026cb63c976 (GPT-6-Luna / Codex); no blockers on exact head. Reviewer posted findings then review/independent: success; coordinator verified newest status creator lukemaj on the current head.
    • Proof: 15 spawn cases plus cross-project settlement passed (16 total, 59 skipped); 51 unchanged lifecycle/setup tests reused from prior combined run. Final server typecheck, targeted lint, diff check, provenance check passed. Exact commands/results and corrected fixture errors are in the PR.
    • CI repair: original Server 2 failed src/mcp/alwaysLoad.test.ts:35:32, AssertionError: expected 776 to be less than 600. One-line description-only follow-up commit reduced it to 509 characters, preserving the limit and required wording. pnpm exec vp test run apps/server/src/mcp/alwaysLoad.test.ts: 2 passed; touched lint, final server typecheck and diff check passed. Reviewer examined this delta and cumulative current-head candidate.
    • Assumptions: explicit project selector uses target preference; absent selector retains child workspace inheritance; target HEAD is worktree base; setup failures are visible but allow agent launch; explicit project scope extends existing model without creator metadata. Caller Prism policy retained. No cross-environment placement or Stopping a thread does not stop its children; report-backs revive it #122 expansion.
    • Objective contribution: Drafters start in any project, as children or top-level threads.
    • Version: no versioning by design.
    • Delivery: committed/pushed/one PR linked natively; no merge, install or release. No browser/computer use, pairing tokens, port 3773 or live state used. No task server to clean up.
    • Remaining acceptance for fleet coordinator: actual provider transcript loading target AGENTS.md; installed desktop sidebar visibility and child/top-level reportback, interrupt, read and message. Backend tests use real engine/projections/provider reactor with fake provider boundary. Current-head CI passed all applicable checks including Check, Test and all three server shards; optional jobs skipped.
    • Agent Observer: cost comment published; attribution gap recorded, zero attributed responses is not a measured $0 task cost. No out-of-scope Observer repair.
    • Wight Wight mode: keep a thread working on continue #117/Spectrum Spectrum: start_spectrum with council and free modes #118 API: optional projectId, mode child/top-level, runtimeMode; follow-up top-level tools use scope project + projectId. Documented in tool descriptions. No sibling or retired threads contacted.

    Elon record

    Requirements and who asked: User/#114 require target placement/instructions, child reportback/interrupt and top-level sidebar/read/message with target workspace preference.
    Deleted: Cross-environment placement, target Prism policy, creator metadata machinery, extra dispatchers/parallel writers and #122 scope.
    Bottleneck: Target workspace and setup before provider launch, plus explicit project selection for follow-up access.
    Checked myself: Complete inherited and final diff, provider cwd and sidebar consumers, clean Git/live remote identity, reviewer findings and exact-head success status, native PR link and published cost limitation.

  8. lukemaj
    closed this as completedin #126on Oct 1, 2026

  9. lukemaj commented on Oct 2, 2026

    @lukemaj
    lukemaj
    on Oct 2, 2026
    ContributorAuthor

    Live verification on the installed build 86d3269c6eac (2026-10-02, coordinator): spawn_thread with projectId of the from project and mode: child ran in /Users/lukaszmaj/dev/toolboxmd/from, read that project's AGENTS.md ("# from. agent instructions") and reported back to the calling thread. The same call with mode: top-level created thread-a4f19985d070 in the from project with parentThreadId: null and no report-back; read_thread with scope: project and that projectId read it afterwards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions