refactor(orchestrator): resolve tq command from build profile

Makefile

@@ -71,7 +71,7 @@ build-tq-dev: ## Build tq and service binaries with the dev profile.
 	mkdir -p "$(HOME)/.tasq-dev/system/bin"
 	go build -ldflags "-X github.com/version-1/tasq/internal/buildinfo.commit=$(TQ_BUILD_COMMIT) -X github.com/version-1/tasq/internal/config.defaultHomeProfile=dev" -o ./tqdev ./cmd/tq
 	go build -o "$(HOME)/.tasq-dev/system/bin/issue-tracker" ./cmd/issue-tracker
-	go build -o "$(HOME)/.tasq-dev/system/bin/orchestrator" ./cmd/orchestrator
+	go build -ldflags "-X github.com/version-1/tasq/internal/config.defaultHomeProfile=dev" -o "$(HOME)/.tasq-dev/system/bin/orchestrator" ./cmd/orchestrator
 	go build -ldflags "-X github.com/version-1/tasq/internal/buildinfo.commit=$(TQ_BUILD_COMMIT)" -o "$(HOME)/.tasq-dev/system/bin/web" ./cmd/web
 
 .PHONY: deploy-tq-dev

cmd/orchestrator/main.go

@@ -38,6 +38,10 @@ func main() {
 	if err != nil {
 		log.Fatalf("load TQ_HOME config: %v", err)
 	}
+	tasqCommand, err := tqconfig.ValidateTasqCommand()
+	if err != nil {
+		log.Fatalf("validate Tasq CLI command: %v", err)
+	}
 	resolvedDBPath := *dbPath
 	if resolvedDBPath == "" {
 		resolvedDBPath = tqconfig.OrchestratorDBPath(home)
@@ -80,6 +84,7 @@ func main() {
 			Store:             store,
 			Runner:            runner.CodexRunner{},
 			WorkflowResolver:  workflowResolver,
+			TasqCommand:       tasqCommand,
 			MaxConcurrentRuns: effectiveMaxConcurrentRuns,
 		})
 		if err != nil {

docs/design/system-prompts.ja.md

@@ -49,6 +49,15 @@ Lifecycle:
 
 `{{ issue.id }}` などのテンプレート変数は、このプロンプトを先頭へ追加した後に展開されます。`tasq.task_work_prompt: false` を設定すると、Issue Tracker と Artifact に関する指示を含む開始プロンプト全体が無効になりますが、継続時の動作は変わりません。
 
+本番ビルドでは `{{ tq.command }}` を `tq` として展開します。開発ビルドでは `tqdev` として展開し、既定のタスク作業プロンプトより前に次の 2 行を追加します。
+
+```text
+Use the `tqdev` command instead of `tq`.
+When using the `tasq-cli` skill, interpret every `tq` command as `tqdev`.
+```
+
+この開発用ガイダンスも既定のタスク作業プロンプト注入の一部であるため、初回ターンで `tasq.task_work_prompt: false` を設定すると無効になります。
+
 承認理由に関する契約を追加することで、承認待ちでブロックされたときのコメントから、運用者が必要な対応を判断できるようにします。runner は Codex app-server から受け取った request payload をすでに保持しているため、エージェントに対して、操作内容、対象範囲、必要性、想定される影響を `reason` に含めるよう指示します。この変更では、実行時の検証や Tasq の承認拒否方針は変更しません。
 
 Pull Request Artifact は、現在レビューを依頼している主要 PR を表します。同じ Artifact を再設定すると以前の URL が置き換わり、補助 PR はハンドオフコメントの補足情報として残します。PR を作成または更新した場合にだけ Artifact 登録が必要です。登録に失敗した場合は合理的な回数だけ再試行し、解決できなければブロッカーコメントを残して `review` へ移動してはいけません。
@@ -63,6 +72,6 @@ Pull Request Artifact は、現在レビューを依頼している主要 PR を
 First run `<tasq-command> issue update <issue-id> --status in_progress` to keep the issue tracker synchronized. Then continue the same task in this live thread without repeating completed work, and stop when it is ready for handoff. Before requesting approval for a command execution or file change, provide a non-empty, specific reason. The reason must identify what needs approval, the target scope (the command and working directory or the file paths), why approval is required, and the expected effect. Do not send a null, empty, or vague reason such as only saying that approval is required. If this continuation creates or updates a pull request, register the primary PR before handoff with `<tasq-command> artifact set <issue-id> --type pull_request <pr-url>`. On success, add the handoff comment, then move the issue to `review`; on failure, retry reasonably, then leave a blocker comment and do not move to `review` if it remains unresolved. Otherwise, artifact registration is not required.
 ```
 
-`<tasq-command>` は managed run では `"$TQ_EXECUTABLE"`、それ以外では `tq` になります。`<issue-id>` はターン開始前に現在の課題 ID で埋め込まれます。同じ継続プロンプトは、有効な複数ターン実行の後続ターンでも使われます。既存の再開条件または後続ターン条件によって継続ターンが選ばれた場合だけ送信され、継続が無効な場合に余分なターンを追加することはありません。担当する変更要求の指示がある場合は、従来どおりこの注意事項の後ろに追加されます。
+`<tasq-command>` は本番ビルドでは `tq`、開発ビルドでは `tqdev` になります。開発ビルドの継続プロンプトには、上記と同じ 2 行のコマンドおよび `tasq-cli` の読み替えガイダンスも先頭へ追加します。`<issue-id>` はターン開始前に現在の課題 ID で埋め込まれます。同じ継続プロンプトは、有効な複数ターン実行の後続ターンでも使われます。既存の再開条件または後続ターン条件によって継続ターンが選ばれた場合だけ送信され、継続が無効な場合に余分なターンを追加することはありません。担当する変更要求の指示がある場合は、従来どおりこの注意事項の後ろに追加されます。
 
 再開した thread と後続 turn には完全な開始プロンプトが再送されないため、承認理由に関する同じ契約を継続用プロンプトにも記載します。

docs/design/system-prompts.md

@@ -49,6 +49,15 @@ Lifecycle:
 
 Template variables such as `{{ issue.id }}` are rendered after this prompt is prepended. Setting `tasq.task_work_prompt: false` disables this entire start prompt, including its tracker and artifact instructions; it does not change continuation behavior.
 
+Production builds render `{{ tq.command }}` as `tq`. Development builds render it as `tqdev` and prepend these two lines before the default task-work prompt:
+
+```text
+Use the `tqdev` command instead of `tq`.
+When using the `tasq-cli` skill, interpret every `tq` command as `tqdev`.
+```
+
+The development guidance is part of the default task-work prompt injection, so `tasq.task_work_prompt: false` disables it on the first turn as well.
+
 The approval-reason contract makes blocked approval comments actionable because the runner already preserves the app-server request payload. It instructs the agent to populate the request reason with the operation, target scope, necessity, and expected effect; it does not add runtime validation or change Tasq's approval-denial policy.
 
 The pull-request artifact represents the primary PR currently submitted for review. Setting it again replaces the prior URL, while supporting PRs remain handoff-comment context. Artifact registration is conditional on creating or updating a PR. A registration failure must be retried reasonably and, if unresolved, reported as a blocker without a transition to `review`.
@@ -63,6 +72,6 @@ The injected resume prompt is:
 First run `<tasq-command> issue update <issue-id> --status in_progress` to keep the issue tracker synchronized. Then continue the same task in this live thread without repeating completed work, and stop when it is ready for handoff. Before requesting approval for a command execution or file change, provide a non-empty, specific reason. The reason must identify what needs approval, the target scope (the command and working directory or the file paths), why approval is required, and the expected effect. Do not send a null, empty, or vague reason such as only saying that approval is required. If this continuation creates or updates a pull request, register the primary PR before handoff with `<tasq-command> artifact set <issue-id> --type pull_request <pr-url>`. On success, add the handoff comment, then move the issue to `review`; on failure, retry reasonably, then leave a blocker comment and do not move to `review` if it remains unresolved. Otherwise, artifact registration is not required.
 ```
 
-`<tasq-command>` uses `"$TQ_EXECUTABLE"` in managed runs and `tq` otherwise. `<issue-id>` is filled from the current task issue ID before the turn starts. The same continuation prompt is also used for later turns in an enabled multi-turn run. It is sent only when the runner's existing resume or later-turn conditions select a continuation turn; the runner does not add an extra turn when continuation is disabled. Assigned change-request guidance, when present, remains appended after this reminder.
+`<tasq-command>` uses `tq` in production builds and `tqdev` in development builds. Development continuations prepend the same two-line command and `tasq-cli` reinterpretation guidance shown above. `<issue-id>` is filled from the current task issue ID before the turn starts. The same continuation prompt is also used for later turns in an enabled multi-turn run. It is sent only when the runner's existing resume or later-turn conditions select a continuation turn; the runner does not add an extra turn when continuation is disabled. Assigned change-request guidance, when present, remains appended after this reminder.
 
 The same approval-reason contract is repeated here because resumed threads and later turns do not receive the full task-start prompt again.

docs/references/makefile.ja.md

@@ -115,7 +115,7 @@ make run-logs
 | `make install-tq version=v0.1.0` | 特定のリリースタグから `tq` と管理対象サービスの実行ファイルをインストールします。 |
 | `make install-tq-prerelease` | 最新の prerelease から `tq` と管理対象サービスの実行ファイルをインストールします。`gh` が必要です。 |
 | `make install-tq-prerelease version=v0.1.0-pre.1` | 特定の prerelease タグから `tq` と管理対象サービスの実行ファイルをインストールします。 |
-| `make build-tq-dev` | `dev` profile を埋め込んだ `tqdev` バイナリをカレントディレクトリに build します。 |
+| `make build-tq-dev` | `dev` プロファイルを埋め込んだ `tqdev` とサービスバイナリをビルドします。サービス起動前に `tqdev` を `PATH` へ配置する必要があります。 |
 | `make deploy-tq-dev` | `tqdev` のサービスを停止し、`build-tq-dev` を実行して、生成された `tqdev` バイナリを `$HOME/.local/bin` に移動した後、サービスを再起動します。 |
 | `make deploy-tq-dev ARGS=/path/to/bin` | 生成された `tqdev` バイナリを `$HOME/.local/bin` の代わりに指定したディレクトリへ配置します。 |
 

docs/references/makefile.md

@@ -115,7 +115,7 @@ make run-logs
 | `make install-tq version=v0.1.0` | Install `tq` and its managed service executables from a specific release tag. |
 | `make install-tq-prerelease` | Install `tq` and its managed service executables from the latest prerelease. Requires `gh`. |
 | `make install-tq-prerelease version=v0.1.0-pre.1` | Install `tq` and its managed service executables from a specific prerelease tag. |
-| `make build-tq-dev` | Build a `tqdev` binary with the `dev` profile in the current directory. |
+| `make build-tq-dev` | Build `tqdev` and service binaries with the `dev` profile. `tqdev` must be on `PATH` before starting services. |
 | `make deploy-tq-dev` | Stop the `tqdev` services, run `build-tq-dev`, move the resulting `tqdev` binary to `$HOME/.local/bin`, and restart the services. |
 | `make deploy-tq-dev ARGS=/path/to/bin` | Deploy the resulting `tqdev` binary to the specified directory instead of `$HOME/.local/bin`. |
 

docs/symphony/WORKFLOW_CONTRACT.ja.md

@@ -98,10 +98,10 @@ front matter の閉じ `---` 以降がすべてプロンプトテンプレート
 #### Issue ステータス更新
 
 デフォルトでは、Tasq はエージェントに `{{ tq.command }}` が表す CLI command で progress comment と
-issue status update を行うよう指示を注入します。`tq service start` で起動した service は、起動元の
-CLI を `TQ_HOME` 配下の永続 managed executable へコピーし、その path を `TQ_EXECUTABLE` で継承します。そのため `tqdev` から起動した場合は、
-`PATH` 上で別の `tq` が先に見つかっても同じ `tqdev` executable を使い続けます。この環境契約を持たずに
-orchestrator を直接起動した場合は、後方互換性のため `tq` に fallback します。
+課題の状態を更新するよう指示を注入します。本番の Orchestrator ビルドではこのコマンドを `tq`、開発ビルドでは
+`tqdev` として展開し、`tasq-cli` スキル内の `tq` の例を `tqdev` へ読み替えるようエージェントへ指示します。
+選択されたコマンドは `PATH` から解決できる必要があります。見つからない場合、`tq service start` と Orchestrator の
+起動はどちらも課題を割り当てる前に失敗します。未対応のビルドプロファイルも、実行ファイル名を推測せずエラーになります。
 
 managed agent run は `TQ_MANAGED_RUN=1` も継承します。この文脈では、run を所有する orchestrator を
 終了させる可能性があるため、`tq update` と `tq service stop` は service state を変更する前に失敗します。

docs/symphony/WORKFLOW_CONTRACT.md

@@ -100,12 +100,11 @@ interacting with the issue-tracker.
 #### Issue Status Updates
 
 By default, Tasq injects instructions that tell the agent to use the CLI command represented by
-`{{ tq.command }}` for progress comments and issue status updates. Services started by
-`tq service start` copy the starter into a persistent managed executable under `TQ_HOME` and
-inherit that path through `TQ_EXECUTABLE`; a
-`tqdev` starter therefore keeps using that same `tqdev` executable even if another `tq` appears
-earlier on `PATH`. Direct orchestrator launches without this environment contract fall back to
-`tq` for backward compatibility.
+`{{ tq.command }}` for progress comments and issue status updates. Production orchestrator builds
+render this command as `tq`, while development builds render it as `tqdev` and tell the agent to
+reinterpret `tq` examples in the `tasq-cli` skill as `tqdev`. The selected command must resolve on
+`PATH`; both `tq service start` and orchestrator startup fail before dispatch when it does not.
+Unsupported build profiles also fail instead of deriving an executable name.
 
 Managed agent runs also inherit `TQ_MANAGED_RUN=1`. In that context, `tq update` and
 `tq service stop` fail before changing service state because either command could terminate the

internal/cli/tq/command_test.go

@@ -819,6 +819,11 @@ func TestServiceStatusStopped(t *testing.T) {
 func TestServiceStartFailsBeforeStartingServicesWhenMigrationsPending(t *testing.T) {
 	home := t.TempDir()
 	t.Setenv(tqconfig.EnvHome, home)
+	commandDir := t.TempDir()
+	if err := os.WriteFile(filepath.Join(commandDir, "tq"), []byte("#!/bin/sh\n"), 0o755); err != nil {
+		t.Fatalf("write tq executable: %v", err)
+	}
+	t.Setenv("PATH", commandDir)
 	for _, name := range []serviceName{serviceIssueTracker, serviceOrchestrator, serviceWeb} {
 		path := serviceExecutablePath(home, name)
 		if err := os.MkdirAll(filepath.Dir(path), 0o755); err != nil {