Skip to content

Implement clean orchestrator prompt loading with strict main-session targeting #193

@fujiwaranosai850

Description

@fujiwaranosai850

From research #191

Related existing implementation lane: #190

Overview

Implement the clean orchestrator prompt reimplementation using a winner-takes-all resolver and strict bootstrap targeting. AGENTS.md must remain the baseline bootstrap context. The runtime must resolve exactly one orchestrator prompt source in this order:

  1. devclaw/projects/<project>/prompts/orchestrator.md
  2. devclaw/prompts/orchestrator.md
  3. package default orchestrator prompt, if present

Inject only the resolved source as bootstrap file orchestrator.md. Do not layer or merge prompt sources. Keep acceptance focused on live semantic behavior, not merely the presence of orchestrator.md in startup context.

Implementation Checklist

Phase 1: Reintroduce the clean loader shape (~0.5-1 day)

  • Add package default orchestrator prompt export in lib/setup/templates.ts and restore defaults/devclaw/prompts/orchestrator.md if the clean lane needs a shipped fallback.
  • In lib/dispatch/bootstrap-hook.ts, add a dedicated orchestrator prompt loader that mirrors worker semantics but returns a single winning source plus source metadata.
  • Ensure orchestrator resolution order is exactly: project override, workspace default, package default. Do not concatenate or layer content from multiple files.
  • Keep AGENTS.md as the orchestrator baseline. Inject resolved orchestrator content as a separate bootstrap file named exactly orchestrator.md.

Phase 2: Tighten session targeting and project resolution (~0.5-1 day)

  • In lib/dispatch/bootstrap-hook.ts, target orchestrator prompt injection only for the real main/orchestrator session path. Do not treat every non-worker session as orchestrator.
  • Reuse topic-aware project lookup from lib/projects/io.ts so exact topic bindings win and chat-level fallback applies only when no topic match exists.
  • Make bootstrap insertion replace-or-update an existing orchestrator.md entry instead of duplicating it.
  • Preserve current worker behavior: worker sessions still replace AGENTS.md with role prompts, and must not receive orchestrator prompt injection.

Phase 3: Regression coverage and semantic acceptance (~1-1.5 days)

  • Extend lib/dispatch/bootstrap-hook.test.ts to cover single-winner orchestrator resolution, including project-over-workspace and workspace-over-package cases, and assert the returned source is singular.
  • Extend lib/services/bootstrap.e2e.test.ts so real orchestrator/main sessions receive orchestrator.md, while worker sessions and unrelated session shapes do not.
  • Add topic-bound bootstrap tests in lib/services/bootstrap.e2e.test.ts for exact topic match and chat-level fallback.
  • Add bootstrap shape assertions that AGENTS.md does not contain orchestrator overlay text and that only one orchestrator.md body is present.
  • Add or document a canary-style semantic acceptance check using a distinctive orchestrator prompt policy so success is measured by live behavior, not filename presence.

Phase 4: Workspace/docs consistency (~0.5 day)

  • Update any prompt-scaffolding/reset surfaces that should know about orchestrator.md, likely including lib/setup/workspace.ts, lib/tools/admin/config.ts, lib/tools/admin/config-reset.ts, and lib/tools/admin/project-register.ts.
  • Update docs/comments that currently imply layering or synthetic prompt filenames so they describe the clean winner-takes-all orchestrator.md model.

Dependencies & Blockers

  • Existing clean implementation lane is tracked in Clean reimplementation of orchestrator prompt loading with winner-takes-all fallback #190. Coordinate scope so this task stays aligned with that lane.
  • The most important blocker/risk is incorrect session targeting. If the bootstrap hook cannot positively identify the true orchestrator/main session shape, stop and clarify rather than broadening targeting heuristics.
  • Preserve current worker bootstrap behavior while introducing orchestrator support.

Estimated Total: 2-4 days

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions