fix: inherit the service starter CLI in managed runs

docs/design/system-prompts.ja.md

@@ -11,12 +11,13 @@
 開始時に注入されるプロンプトは次のとおりです。
 
 ````text
-Use `tq` to keep the issue tracker synchronized:
+Use `{{ tq.command }}` to keep the issue tracker synchronized:
 
 If the `tasq-cli` skill is available, use it as the preferred guidance for tracker operations.
 
-- Prefer typed `tq` commands such as `tq issue`, `tq comment`, and `tq artifact` for issue tracker operations.
-- Use `tq api` only when the issue tracker operation has no typed `tq` command.
+- Use `{{ tq.command }}` for every Tasq CLI operation, including commands shown elsewhere as `tq`; it identifies the CLI that started the managed services.
+- Prefer typed commands such as `{{ tq.command }} issue`, `{{ tq.command }} comment`, and `{{ tq.command }} artifact` for issue tracker operations.
+- Use `{{ tq.command }} api` only when the issue tracker operation has no typed command.
 - Do not call the issue tracker API directly with `curl`, `wget`, or a custom HTTP script. This restriction applies only to the issue tracker API, not to other services or local endpoint verification.
 - When work starts, move the issue to `in_progress` and leave a progress comment.
 - Add progress comments at meaningful milestones during the work.
@@ -28,24 +29,25 @@ If the `tasq-cli` skill is available, use it as the preferred guidance for track
 
 ```sh
 # Start
-tq issue update {{ issue.id }} --status in_progress
-tq comment add {{ issue.id }} --author codex --type progress --body "Started work."
+{{ tq.command }} issue update {{ issue.id }} --status in_progress
+{{ tq.command }} comment add {{ issue.id }} --author codex --type progress --body "Started work."
 
 # Meaningful progress milestone
-tq comment add {{ issue.id }} --author codex --type progress --body "Implemented the change; running verification."
+{{ tq.command }} comment add {{ issue.id }} --author codex --type progress --body "Implemented the change; running verification."
 
 # Blocked (use instead of the review handoff)
-tq comment add {{ issue.id }} --author codex --type blocker --body "Blocked: explain the blocker and what is needed."
-tq issue update {{ issue.id }} --status blocked
+{{ tq.command }} comment add {{ issue.id }} --author codex --type blocker --body "Blocked: explain the blocker and what is needed."
+{{ tq.command }} issue update {{ issue.id }} --status blocked
 
 # Ready for review
-tq artifact set {{ issue.id }} --type pull_request <pr-url>
-tq comment add {{ issue.id }} --author codex --type handoff --body "PR: <url>; verification: <summary>."
-tq issue update {{ issue.id }} --status review
+{{ tq.command }} artifact set {{ issue.id }} --type pull_request <pr-url>
+{{ tq.command }} comment add {{ issue.id }} --author codex --type handoff --body "PR: <url>; verification: <summary>."
+{{ tq.command }} issue update {{ issue.id }} --status review
 ```
 
-Run the installed `tq` binary from `PATH`. Do not use `go run ./cmd/tq` for
-tracker synchronization.
+Tasq CLI のすべての操作には `{{ tq.command }}` を使います。managed service では service を起動した
+CLI の永続 snapshot を `"$TQ_EXECUTABLE"` として展開し、orchestrator の直接起動では `tq` に
+fallback します。`PATH` 上の別 executable に置き換えてはいけません。
 ````
 
 `{{ issue.id }}` などのテンプレート変数は、このプロンプトを先頭へ追加した後に展開されます。`tasq.task_work_prompt: false` を設定すると、Issue Tracker と Artifact に関する指示を含む開始プロンプト全体が無効になりますが、継続時の動作は変わりません。
@@ -59,7 +61,7 @@ Pull Request Artifact は、現在レビューを依頼している主要 PR を
 再開時に注入されるプロンプトは次のとおりです。
 
 ```text
-First run `tq 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. If this continuation creates or updates a pull request, register the primary PR before handoff with `tq artifact set <issue-id> --type pull_request <pr-url>`. On success, add the handoff comment, then move the issue to `review`; on failure, retry a reasonable number of times, then leave a blocker comment and do not move to `review` if it remains unresolved. Otherwise, artifact registration is not required.
+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. 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 a reasonable number of times, then leave a blocker comment and do not move to `review` if it remains unresolved. Otherwise, artifact registration is not required.
 ```
 
-`<issue-id>` はターン開始前に現在の課題 ID で埋め込まれます。同じ継続プロンプトは、有効な複数ターン実行の後続ターンでも使われます。既存の再開条件または後続ターン条件によって継続ターンが選ばれた場合だけ送信され、継続が無効な場合に余分なターンを追加することはありません。担当する変更要求の指示がある場合は、従来どおりこの注意事項の後ろに追加されます。
+`<tasq-command>` は managed run では `"$TQ_EXECUTABLE"`、それ以外では `tq` になります。`<issue-id>` はターン開始前に現在の課題 ID で埋め込まれます。同じ継続プロンプトは、有効な複数ターン実行の後続ターンでも使われます。既存の再開条件または後続ターン条件によって継続ターンが選ばれた場合だけ送信され、継続が無効な場合に余分なターンを追加することはありません。担当する変更要求の指示がある場合は、従来どおりこの注意事項の後ろに追加されます。

docs/design/system-prompts.md

@@ -11,12 +11,13 @@ On a first run, when `Task.ResumeThreadID` is empty, the runner renders the effe
 The injected start prompt is:
 
 ````text
-Use `tq` to keep the issue tracker synchronized:
+Use `{{ tq.command }}` to keep the issue tracker synchronized:
 
 If the `tasq-cli` skill is available, use it as the preferred guidance for tracker operations.
 
-- Prefer typed `tq` commands such as `tq issue`, `tq comment`, and `tq artifact` for issue tracker operations.
-- Use `tq api` only when the issue tracker operation has no typed `tq` command.
+- Use `{{ tq.command }}` for every Tasq CLI operation, including commands shown elsewhere as `tq`; it identifies the CLI that started the managed services.
+- Prefer typed commands such as `{{ tq.command }} issue`, `{{ tq.command }} comment`, and `{{ tq.command }} artifact` for issue tracker operations.
+- Use `{{ tq.command }} api` only when the issue tracker operation has no typed command.
 - Do not call the issue tracker API directly with `curl`, `wget`, or a custom HTTP script. This restriction applies only to the issue tracker API, not to other services or local endpoint verification.
 - When work starts, move the issue to `in_progress` and leave a progress comment.
 - Add progress comments at meaningful milestones during the work.
@@ -28,24 +29,25 @@ If the `tasq-cli` skill is available, use it as the preferred guidance for track
 
 ```sh
 # Start
-tq issue update {{ issue.id }} --status in_progress
-tq comment add {{ issue.id }} --author codex --type progress --body "Started work."
+{{ tq.command }} issue update {{ issue.id }} --status in_progress
+{{ tq.command }} comment add {{ issue.id }} --author codex --type progress --body "Started work."
 
 # Meaningful progress milestone
-tq comment add {{ issue.id }} --author codex --type progress --body "Implemented the change; running verification."
+{{ tq.command }} comment add {{ issue.id }} --author codex --type progress --body "Implemented the change; running verification."
 
 # Blocked (use instead of the review handoff)
-tq comment add {{ issue.id }} --author codex --type blocker --body "Blocked: explain the blocker and what is needed."
-tq issue update {{ issue.id }} --status blocked
+{{ tq.command }} comment add {{ issue.id }} --author codex --type blocker --body "Blocked: explain the blocker and what is needed."
+{{ tq.command }} issue update {{ issue.id }} --status blocked
 
 # Ready for review
-tq artifact set {{ issue.id }} --type pull_request <pr-url>
-tq comment add {{ issue.id }} --author codex --type handoff --body "PR: <url>; verification: <summary>."
-tq issue update {{ issue.id }} --status review
+{{ tq.command }} artifact set {{ issue.id }} --type pull_request <pr-url>
+{{ tq.command }} comment add {{ issue.id }} --author codex --type handoff --body "PR: <url>; verification: <summary>."
+{{ tq.command }} issue update {{ issue.id }} --status review
 ```
 
-Run the installed `tq` binary from `PATH`. Do not use `go run ./cmd/tq` for
-tracker synchronization.
+Use `{{ tq.command }}` for every Tasq CLI operation. Managed services render it as
+`"$TQ_EXECUTABLE"`, a persistent snapshot of the CLI that started the services; direct
+orchestrator launches fall back to `tq`. Do not substitute another executable from `PATH`.
 ````
 
 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.
@@ -59,7 +61,7 @@ On a resumed run, when `Task.ResumeThreadID` is set, the runner resumes the exis
 The injected resume prompt is:
 
 ```text
-First run `tq 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. If this continuation creates or updates a pull request, register the primary PR before handoff with `tq artifact set <issue-id> --type pull_request <pr-url>`. On success, add the handoff comment, then move the issue to `review`; on failure, retry a reasonable number of times, then leave a blocker comment and do not move to `review` if it remains unresolved. Otherwise, artifact registration is not required.
+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. 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 a reasonable number of times, then leave a blocker comment and do not move to `review` if it remains unresolved. Otherwise, artifact registration is not required.
 ```
 
-`<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_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.

docs/symphony/WORKFLOW_CONTRACT.ja.md

@@ -86,6 +86,7 @@ front matter の閉じ `---` 以降がすべてプロンプトテンプレート
 | `{{ issue.title }}`      | string | 課題タイトル                                   |
 | `{{ issue.description }}`| string | 課題説明本文                                   |
 | `{{ attempt }}`          | int    | attempt 番号（初回は 0、リトライは 1 以上）         |
+| `{{ tq.command }}`       | string | service 起動元から継承した CLI command         |
 
 変数は単純な文字列置換で展開されます。認識されない `{{ ... }}` トークンはそのまま残ります。
 
@@ -96,9 +97,15 @@ front matter の閉じ `---` 以降がすべてプロンプトテンプレート
 
 #### Issue ステータス更新
 
-デフォルトでは、Tasq はエージェントに `tq` CLI で progress comment と issue status update を行うように
-指示を注入します。実行時環境に `tq` が `PATH` 上にあり、`TQ_API_URL` が
-issue-tracker のエンドポイントに設定されている必要があります。
+デフォルトでは、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 します。
+
+managed agent run は `TQ_MANAGED_RUN=1` も継承します。この文脈では、run を所有する orchestrator を
+終了させる可能性があるため、`tq update` と `tq service stop` は service state を変更する前に失敗します。
+service lifecycle command と update command は user shell から実行してください。
 
 ワークフロー作成者は通常、これらの `tq` 指示をプロンプトテンプレートで繰り返す必要はありません。
 `tasq.task_work_prompt` を `false` に設定した場合、ワークフローテンプレート側で同等の issue-tracker

docs/symphony/WORKFLOW_CONTRACT.md

@@ -87,6 +87,7 @@ issue-tracker synchronization instructions before template variable expansion, s
 | `{{ issue.title }}`      | string | Issue title                                       |
 | `{{ issue.description }}`| string | Issue description body                            |
 | `{{ attempt }}`          | int    | Attempt number (0 for first run, >=1 for retries) |
+| `{{ tq.command }}`       | string | CLI command inherited from the service starter    |
 
 Variables are replaced by simple string substitution. Unrecognized `{{ ... }}` tokens are left
 as-is.
@@ -98,9 +99,17 @@ interacting with the issue-tracker.
 
 #### Issue Status Updates
 
-By default, Tasq injects instructions that tell the agent to use the `tq` CLI for progress comments
-and issue status updates. The runtime environment must have `tq` on `PATH` and `TQ_API_URL` set to
-the issue-tracker endpoint.
+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.
+
+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
+orchestrator that owns the run. Run lifecycle and update commands from a user shell instead.
 
 Workflow authors normally do not need to repeat these `tq` instructions in the prompt template. If
 `tasq.task_work_prompt` is set to `false`, the workflow template is responsible for providing

internal/cli/tq/command_test.go

@@ -183,6 +183,34 @@ func TestUpdateProfileAllowed(t *testing.T) {
 	}
 }
 
+func TestUpdateRejectsOrchestratorManagedRun(t *testing.T) {
+	t.Setenv(tqconfig.EnvManagedRun, "1")
+	runner := &fakeUpdateRunner{}
+
+	_, stderr, code := runCLIWithUpdateRunner(t, []string{"update", "-y"}, "", runner)
+
+	if code != 1 {
+		t.Fatalf("code=%d stderr=%s", code, stderr)
+	}
+	assertStringSlice(t, runner.calls, nil)
+	if message := decodeCLIError(t, stderr); !strings.Contains(message, "orchestrator-managed run") {
+		t.Fatalf("error = %q", message)
+	}
+}
+
+func TestServiceStopRejectsOrchestratorManagedRun(t *testing.T) {
+	t.Setenv(tqconfig.EnvManagedRun, "1")
+
+	_, stderr, code := runCLI(t, []string{"service", "stop"})
+
+	if code != 1 {
+		t.Fatalf("code=%d stderr=%s", code, stderr)
+	}
+	if message := decodeCLIError(t, stderr); !strings.Contains(message, "orchestrator-managed run") {
+		t.Fatalf("error = %q", message)
+	}
+}
+
 func TestUpdateYesSkipsConfirmation(t *testing.T) {
 	runner := &fakeUpdateRunner{
 		current:   "tq v0.1.0 (commit: old)",