diff --git a/docs/design/system-prompts.ja.md b/docs/design/system-prompts.ja.md index bede4af..33c1b0f 100644 --- a/docs/design/system-prompts.ja.md +++ b/docs/design/system-prompts.ja.md @@ -4,6 +4,24 @@ オーケストレーターは、「ワークフローで定義した課題の変更はコーディングエージェントが行う」という Symphony の境界を保ちながら、エージェントが Issue Tracker を同期できるようにこれらのプロンプトを注入します。 +## Tasq コマンドの解決 + +オーケストレーターは、課題を割り当てる前にビルドプロファイルから Tasq CLI コマンドを決定します。 + +| ビルドプロファイル | コマンド | +|---|---| +| 空（本番） | `tq` | +| `dev` | `tqdev` | + +その他のプロファイルはエラーになります。`service start` サブコマンドとオーケストレーターの単体起動は、選択したコマンドを `PATH` から解決できることを要求します。 + +初回ターンでは、既定のタスク作業プロンプト注入が有効な場合に、開発ビルド用の次の文言をターン固有の指示より前へ追加します。開発ビルドの継続ターンでは常に追加します。 + +```text +Use the `tqdev` command instead of `tq`. +When using the `tasq-cli` skill, interpret every `tq` command as `tqdev`. +``` + ## タスク開始時のプロンプト 初回実行で `Task.ResumeThreadID` が空の場合、runner は有効なワークフロープロンプトを展開します。`tasq.task_work_prompt` が `false` に設定されていない限り、Tasq はテンプレート変数を展開する前に、既定の task-work プロンプトを先頭へ追加します。 @@ -47,20 +65,9 @@ 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 の承認拒否方針は変更しません。 +Tasq は、開発ビルド用のコマンド解決ガイダンス、タスク作業プロンプトの順に追加し、最後に `{{ issue.id }}` や `{{ tq.command }}` などの変数を展開します。`tasq.task_work_prompt: false` を設定すると、初回ターンでは両方の注入を無効にしますが、継続時の動作は変わりません。 -Pull Request Artifact は、現在レビューを依頼している主要 PR を表します。同じ Artifact を再設定すると以前の URL が置き換わり、補助 PR はハンドオフコメントの補足情報として残します。PR を作成または更新した場合にだけ Artifact 登録が必要です。登録に失敗した場合は合理的な回数だけ再試行し、解決できなければブロッカーコメントを残して `review` へ移動してはいけません。 +承認理由に関する文言はエージェントの振る舞いを案内するものであり、実行時検証や Tasq の承認拒否方針は変更しません。Pull Request Artifact の指示は、エージェントが PR を作成または更新した場合にだけ適用します。 ## タスク再開時のプロンプト @@ -72,6 +79,6 @@ Pull Request Artifact は、現在レビューを依頼している主要 PR を First run ` issue update --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 ` artifact set --type pull_request `. 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. ``` -`` は本番ビルドでは `tq`、開発ビルドでは `tqdev` になります。開発ビルドの継続プロンプトには、上記と同じ 2 行のコマンドおよび `tasq-cli` の読み替えガイダンスも先頭へ追加します。`` はターン開始前に現在の課題 ID で埋め込まれます。同じ継続プロンプトは、有効な複数ターン実行の後続ターンでも使われます。既存の再開条件または後続ターン条件によって継続ターンが選ばれた場合だけ送信され、継続が無効な場合に余分なターンを追加することはありません。担当する変更要求の指示がある場合は、従来どおりこの注意事項の後ろに追加されます。 +`` には [Tasq コマンドの解決](#tasq-コマンドの解決)で決定したコマンドを使い、`` には現在の課題 ID を設定します。開発ビルドでは、上記と同じ 2 行の読み替えガイダンスを先頭へ追加します。 -再開した thread と後続 turn には完全な開始プロンプトが再送されないため、承認理由に関する同じ契約を継続用プロンプトにも記載します。 +有効な複数ターン実行の後続ターンでも、同じ継続プロンプトを使います。既存の再開条件または継続条件が次のターンを選んだ場合だけ送信し、継続が無効な場合に余分なターンを追加することはありません。担当する変更要求の指示がある場合は、この注意事項の後ろに追加します。 diff --git a/docs/design/system-prompts.md b/docs/design/system-prompts.md index 3479706..30e1f97 100644 --- a/docs/design/system-prompts.md +++ b/docs/design/system-prompts.md @@ -4,6 +4,25 @@ This document records the Tasq-owned prompt text that the orchestrator injects i The orchestrator injects these prompts so agents can keep the issue tracker synchronized while preserving the Symphony boundary where workflow-defined ticket mutations are performed by the coding agent. +## Tasq Command Resolution + +The orchestrator resolves the Tasq CLI command from its build profile before dispatch: + +| Build profile | Command | +|---|---| +| empty (production) | `tq` | +| `dev` | `tqdev` | + +Any other profile is rejected. Both the `service start` subcommand and standalone orchestrator startup require the selected command to resolve on `PATH`. + +On initial turns with default task-work injection enabled, development prompts add this guidance +before the turn-specific text. Development continuation turns always add it. + +```text +Use the `tqdev` command instead of `tq`. +When using the `tasq-cli` skill, interpret every `tq` command as `tqdev`. +``` + ## Task Start Prompt On a first run, when `Task.ResumeThreadID` is empty, the runner renders the effective workflow prompt. Unless `tasq.task_work_prompt` is set to `false`, Tasq prepends the default task-work prompt before template expansion. @@ -47,20 +66,9 @@ 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. +Tasq prepends the command-resolution guidance for development builds, then prepends the task-work prompt, and finally expands variables such as `{{ issue.id }}` and `{{ tq.command }}`. Setting `tasq.task_work_prompt: false` disables both injected sections on the first turn; it does not change continuation behavior. -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`. +The approval-reason wording guides agent behavior but does not add runtime validation or change Tasq's approval-denial policy. The pull-request artifact instructions apply only when the agent creates or updates a PR. ## Task Resume Prompt @@ -72,6 +80,6 @@ The injected resume prompt is: First run ` issue update --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 ` artifact set --type pull_request `. 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. ``` -`` 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. `` 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. +`` uses the command from [Tasq Command Resolution](#tasq-command-resolution), and `` is filled from the current task. Development runs prepend the same two-line reinterpretation guidance shown above. -The same approval-reason contract is repeated here because resumed threads and later turns do not receive the full task-start prompt again. +The same continuation prompt is used for later turns in an enabled multi-turn run. The runner sends it only when existing resume or continuation conditions select another turn; it does not add a turn when continuation is disabled. Assigned change-request guidance, when present, is appended after this reminder. diff --git a/docs/references/makefile.ja.md b/docs/references/makefile.ja.md index bd44713..c2c11df 100644 --- a/docs/references/makefile.ja.md +++ b/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` プロファイルを埋め込んだ `tqdev` とサービスバイナリをビルドします。サービス起動前に `tqdev` を `PATH` へ配置する必要があります。 | +| `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` の代わりに指定したディレクトリへ配置します。 | diff --git a/docs/references/makefile.md b/docs/references/makefile.md index 7320eee..5b5ecc8 100644 --- a/docs/references/makefile.md +++ b/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 `tqdev` and service binaries with the `dev` profile. `tqdev` must be on `PATH` before starting services. | +| `make build-tq-dev` | Build `tqdev` and the managed 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`. | diff --git a/docs/symphony/WORKFLOW_CONTRACT.ja.md b/docs/symphony/WORKFLOW_CONTRACT.ja.md index 5a1e8ad..b2771c1 100644 --- a/docs/symphony/WORKFLOW_CONTRACT.ja.md +++ b/docs/symphony/WORKFLOW_CONTRACT.ja.md @@ -1,10 +1,10 @@ # Tasq Symphony Workflow Contract -Tasq は run の割り当て時に、プロジェクトごとの有効なワークフローを解決します。既に割り当て済みの -run に対する実行時の再読み込みは意図的に無効化されています。ワークフローの実行時設定を変更した場合は、 -run を再起動または再割り当てしてください。 +Tasq は実行の割り当て時に、プロジェクトごとの有効なワークフローを解決します。既に割り当て済みの +実行に対する実行時の再読み込みは意図的に無効化されています。ワークフローの実行時設定を変更した場合は、 +実行を再起動または再割り当てしてください。 -front matter パーサーは YAML を使用し、以下の Tasq 固有フィールドをサポートします。未知のフィールドは +フロントマターのパーサーは YAML を使用し、以下の Tasq 固有フィールドをサポートします。未知のフィールドは 前方互換性のために無視されます。 ## サポートされるフィールド @@ -41,88 +41,79 @@ hooks: timeout_ms: 60000 ``` -`tasq.task_work_prompt` は、orchestrator がレンダリング済みのエージェントプロンプトの先頭に追加する +`tasq.task_work_prompt` は、オーケストレーターが展開済みのエージェントプロンプトの先頭に追加する Tasq の既定の作業指示を制御します。省略時の既定値は `true` です。ワークフローテンプレートが -独自の issue-tracker 同期指示を提供する場合にのみ `false` に設定してください。 +独自の Issue Tracker 同期指示を提供する場合にのみ `false` に設定してください。注入する正確な文言と +継続時の動作は、[システムプロンプト](../design/system-prompts.ja.md)を参照してください。 `workspace.root` の相対パスは、選択されたワークフローファイルからの相対パスとして解決されます。 -path フィールドでは環境変数の間接参照と `~` 展開がサポートされています。 +パスのフィールドでは環境変数の間接参照と `~` 展開がサポートされています。 `agent.max_turns` が 1 より大きい場合でも、継続ターンはデフォルトで無効です。同じ Codex -thread 上で複数ターンを実行する準備ができている場合に `agent.continuation_turns_enabled` を有効化 +スレッド上で複数ターンを実行する準備ができている場合に `agent.continuation_turns_enabled` を有効化 してください。 -runner の進捗、ワークスペースメタデータ、ワークスペース準備の失敗、クリーンアップ状態は orchestrator の +runner の進捗、ワークスペースメタデータ、ワークスペース準備の失敗、クリーンアップ状態は、オーケストレーターの SQLite データベースに保存されます。大きなトランスクリプトは現在の実装ではファイルシステムには書き出されません。 -workspace hook は `bash -lc` で実行され、課題の workspace directory が `cwd` になります。 -`hooks.timeout_ms` はすべての hook に適用され、デフォルトは `60000` ミリ秒です。非正の timeout 値は +ワークスペースフックは `bash -lc` で実行され、課題のワークスペースディレクトリが `cwd` になります。 +`hooks.timeout_ms` はすべてのフックに適用され、デフォルトは `60000` ミリ秒です。0 以下のタイムアウト値は ワークフロー設定の検証で失敗します。 -hook 失敗時の挙動: +フック失敗時の挙動: - `after_create` は新規作成されたワークスペースでのみ実行されます。失敗するとワークスペース作成が中断され、 - 部分的な workspace directory が削除されます。 + 部分的なワークスペースディレクトリが削除されます。 - `before_run` は各エージェント試行の前に実行されます。失敗すると現在の試行が中断されます。 - `after_run` は各エージェント試行の後に実行されます。失敗はログに記録されますが無視されます。 -- `before_remove` は directory が存在する場合にワークスペース削除の前に実行されます。失敗はログに記録され、 +- `before_remove` はディレクトリが存在する場合にワークスペース削除の前に実行されます。失敗はログに記録され、 クリーンアップは続行されます。 -front matter は YAML なので、複数行の hook script には literal block scalar（`|`）が使えます。 +フロントマターは YAML なので、複数行のフックスクリプトにはリテラルブロックスカラー（`|`）が使えます。 ## Prompt Template -front matter の閉じ `---` 以降がすべてプロンプトテンプレートです。orchestrator はエージェント試行ごとに +フロントマターの閉じ `---` 以降がすべてプロンプトテンプレートです。オーケストレーターはエージェントの試行ごとに 1 回レンダリングし、結果をコーディングエージェントへの最初のメッセージとして送信します。 -`tasq.task_work_prompt` が省略されているか `true` の場合、orchestrator は template variable expansion -の前に既定の `tq` issue-tracker 同期指示を先頭へ追加します。そのため +`tasq.task_work_prompt` が省略されているか `true` の場合、オーケストレーターはテンプレート変数を展開する +前に、既定の Tasq タスク作業指示を先頭へ追加します。そのため `{{ issue.id }}` などの変数は既定の指示とワークフローテンプレートの両方で展開されます。 ### 利用可能な変数 | 変数 | 型 | 説明 | |--------------------------|--------|------------------------------------------------| -| `{{ issue.id }}` | int | issue-tracker の数値課題 ID | +| `{{ issue.id }}` | int | Issue Tracker の数値課題 ID | | `{{ issue.title }}` | string | 課題タイトル | | `{{ issue.description }}`| string | 課題説明本文 | -| `{{ attempt }}` | int | attempt 番号（初回は 0、リトライは 1 以上） | -| `{{ tq.command }}` | string | service 起動元から継承した CLI command | +| `{{ attempt }}` | int | 試行番号（初回は 0、再試行は 1 以上） | +| `{{ tq.command }}` | string | 本番ビルドでは `tq`、開発ビルドでは `tqdev` | 変数は単純な文字列置換で展開されます。認識されない `{{ ... }}` トークンはそのまま残ります。 ### 作成ガイドライン -プロンプトテンプレートには、エージェントに **何をすべきか** と、issue-tracker とやり取りするための +プロンプトテンプレートには、エージェントに **何をすべきか** と、Issue Tracker とやり取りするための **利用可能なツール** を記述します。 -#### Issue ステータス更新 +#### Issue Tracker の同期 -デフォルトでは、Tasq はエージェントに `{{ tq.command }}` が表す CLI command で progress comment と -課題の状態を更新するよう指示を注入します。本番の Orchestrator ビルドではこのコマンドを `tq`、開発ビルドでは -`tqdev` として展開し、`tasq-cli` スキル内の `tq` の例を `tqdev` へ読み替えるようエージェントへ指示します。 -選択されたコマンドは `PATH` から解決できる必要があります。見つからない場合、`tq service start` と Orchestrator の -起動はどちらも課題を割り当てる前に失敗します。未対応のビルドプロファイルも、実行ファイル名を推測せずエラーになります。 +既定のタスク作業プロンプトには、進捗コメント、課題の状態更新、PR Artifact の登録、ハンドオフに関する指示が含まれます。ワークフロー作成者は、これらの指示をプロジェクトのテンプレートで繰り返さないでください。 -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 -同期ガイダンスを提供する責任があります。 +管理下のエージェント実行は `TQ_MANAGED_RUN=1` も継承します。この実行中に `update` または `service stop` サブコマンドを呼ぶと、実行を所有するオーケストレーターを終了させる可能性があるため、サービス状態を変更する前に失敗します。サービスのライフサイクル操作と更新は、ユーザーのシェルから実行してください。 #### 成果物 エージェントがタスク完了を判断できるように、期待する成果物を定義します。一般的なパターン: -- 変更をコミットし、pull request を作成する。 +- 変更をコミットし、Pull Request を作成する。 - 課題ステータスをハンドオフ状態（例: `review`）に更新する。 -- 実装メモを課題の description やコメントに残す。 +- 実装メモを課題の説明やコメントに残す。 成功時と失敗時にエージェントが課題をどのステータスに遷移させるべきか、明示的に記述してください。 #### 含めるべきでないもの -- 実行時設定（poll interval、concurrency、timeout）は front matter に属します。プロンプトには +- 実行時設定（ポーリング間隔、並行数、タイムアウト）はフロントマターに属します。プロンプトには 含めないでください。 -- secret や credential は環境変数から取得すべきです。テンプレートテキストには含めないでください。 +- シークレットや認証情報は環境変数から取得すべきです。テンプレートテキストには含めないでください。 diff --git a/docs/symphony/WORKFLOW_CONTRACT.md b/docs/symphony/WORKFLOW_CONTRACT.md index 480451c..1901e69 100644 --- a/docs/symphony/WORKFLOW_CONTRACT.md +++ b/docs/symphony/WORKFLOW_CONTRACT.md @@ -43,7 +43,8 @@ hooks: `tasq.task_work_prompt` controls the default Tasq task-work instructions that the orchestrator prepends to the rendered agent prompt. It defaults to `true` when omitted. Set it to `false` only -when the workflow template provides its own issue-tracker synchronization instructions. +when the workflow template provides its own issue-tracker synchronization instructions. See +[System Prompts](../design/system-prompts.md) for the exact injected text and continuation behavior. Relative `workspace.root` values resolve relative to the selected workflow file. Environment variable indirection and `~` expansion are supported for path fields. @@ -75,8 +76,8 @@ Because front matter is YAML, multiline hook scripts can use literal block scala Everything after the closing `---` of the front matter is the prompt template. The orchestrator renders it once per agent attempt and sends the result as the initial message to the coding agent. -When `tasq.task_work_prompt` is omitted or `true`, the orchestrator prepends the default `tq` -issue-tracker synchronization instructions before template variable expansion, so variables such as +When `tasq.task_work_prompt` is omitted or `true`, the orchestrator prepends the default Tasq +task-work instructions before template variable expansion, so variables such as `{{ issue.id }}` are rendered inside both the default instructions and the workflow template. ### Available Variables @@ -87,7 +88,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 | +| `{{ tq.command }}` | string | `tq` for production builds or `tqdev` for development builds | Variables are replaced by simple string substitution. Unrecognized `{{ ... }}` tokens are left as-is. @@ -97,22 +98,16 @@ as-is. A prompt template should tell the agent **what to do** and **what tools are available** for interacting with the issue-tracker. -#### Issue Status Updates +#### Tracker Synchronization -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. 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. +The default task-work prompt covers progress comments, issue status updates, PR artifact +registration, and handoff. Workflow authors should not repeat those instructions in the project +template. -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 -equivalent issue-tracker synchronization guidance. +Managed agent runs also inherit `TQ_MANAGED_RUN=1`. In that context, the `update` and +`service stop` subcommands fail before changing service state because either operation could +terminate the orchestrator that owns the run. Run lifecycle and update commands from a user shell +instead. #### Deliverables