resume prompt injection list closed by criterion - Liplus-Project/liplus-language GitHub Wiki

再開プロンプトへ注入する項目は、列挙ではなく基準で閉じる

Question

auto / semi_auto で brake の報告後に親が実装サブエージェント（著者）を再開するとき、再開メッセージへ何を注入するか。項目を足したくなったとき、何が追加を許し、何が拒むか。

Current resolution

注入は 4 項目で、閉じているのは基準である。 項目の本文は skills/task-subagent-prompt/SKILL.md Resume-phase authority boundary が持つ。ここが持つのは、各項目がなぜその形なのかと、リストが閉じている理由である（#1615 の組み直しで本文から移した）。

  • 基準 = 再開点におけるゲート状態の判断。すなわち (1) 再開した著者に何が許されるかという境界、または (2) 著者自身のセッションからは見えない親側の状態。境界の内側で著者が行うことは手順であり、正本の置き場に留まる。
  • (a) 停止条件はポインタで運ぶ。(b) 2 つの否定は逐語。(c) 指摘の所在は PR URL とスレッド。(d) 裁定コメントの解決済み言語は、その run の値として名指す。
  • 格上げ（auto-load が既に覆っている項目をリストへ入れること）は、この地点での逸脱が実測されたときに限る。見込みでは入れない。

各項目の理由（本文から移したもの）

  • auto-load 任せにしない理由。 再開したサブエージェントは、実装を一通り走らせ終え、あと CI green 1 回でマージ可能な PR に届くセッションを持ったまま戻ってくる。「最後まで済ませる」引きはまさにそこで最も強い。#1628 は semi_auto の委譲サブエージェントがこの境界を越え、セルフレビュー投稿とマージまで実行した実測である。
  • (a) がリテラルでなくポインタである理由。 リテラルを注入するには親が先に skills/operations-on-pr-review/SKILL.md を読む必要があり、それは親に禁じられている（rules/operations/main-agent-procedures.md The bar and its pair、#1708）。この項目は bar が「移設」ではなく「ポインタ化」で修復された唯一の箇所で、理由は literal の実行主体がサブエージェント自身であり、main が読める面へ移す対象が無いこと。#1628 が実測したのは auto-load 任せでは境界が持たなかったことであって、指示して読ませても持たないことではない。境界そのものは逐語の (b) が担う。
  • (c) で指摘を貼らない理由。 評価者が PR へ直接投稿する経路（#1864）の下では、親はそもそも貼るために読んでいない。durable な写しはスレッドであり、どこにも残らないメッセージは 2 つ目の写しの置き場として誤りである。経路の推移: #1684（評価者が PR コメントへ投稿）→ #1733（親が統合コメント 1 本に集約）→ #1864（評価者が直接投稿、往復ループ化）。
  • (d) が加わった理由。 #1864 で裁定の置き場が commit body から PR コメントへ移り、言語契約（Workspace_Language_Contract は PR コメントを base language 側＝会話的返信に置く）の及ぶ面になった瞬間に load-bearing になった。session-start hook は契約の値を親の context へだけ出し、サブエージェントへは出さないため、基準の後半（親側にしか無い状態）に当たる。見込みで入れたのではない。phase 1 の委譲プロンプトが運んだ body 言語はこれに答えない。
  • 次ラウンドの再開で親が修正を足さない理由。 #1733 では「親の修正を運ぶ再々開」があったが、#1864 で親は往復の内容を読まなくなった。中継しているものを判断していない主体が修正を付けることはできない。

リストが閉じている理由（#1691 / PR #1694）

  • state ラベル遷移は列挙しない。 まさに再開の瞬間に発火するので隙間に見えるが、サブエージェントが既に持つラベル権限の内側にあり、skills/task-subagent-state-labels/SKILL.md が mandate として保持し、トリガーに再開を名指している。ここへ列挙すれば mandate の 2 つ目の写しになり、ドリフトするのは常に 2 つ目の写しである。
  • 格上げは実測でのみ。 rules/model/subtractive-structural-beauty.md は required か unnecessary の二値しか認めず、見込みが買えるのは safety net である。(b) には #1628 の実測があり、ラベル遷移には相当する観測が無い。構造的根拠（二値）を本体に、先例（#1628）を裏付けに置く形は PR #1694 の brake 1 で 2 体が指摘して揃えた。
  • auto-load 面の発火信頼性を疑うなら、直すのはその面である。 ここへ通せば、この種の疑いがすべてこのリストへ写される場所になり、リストに終わりが無くなる。

再構成フォールバックについて

発火条件と、それが substrate-absence フォールバックと別物である理由は brake-adjudication-by-resumed-author が持つ。本文から移したのは次の 2 点のみ。

  • cold spawn へ足す 1 項目（「この spawn はフェーズ2から入る」）を真の再開が運ばないのは、真の再開では自分のセッションそのものがその陳述だからである。
  • #1864 で (d) が加わった後も、フォールバック段落は「上記 3 項目をそのまま注入する」と書いたまま残り、同じ段落末尾の「停止条件・2 つの否定・指摘の所在・言語の名指しが同じ」（4 点）と食い違っていた。#1615 の組み直しで「4 項目」に揃え、docs/3.-Task.md の日本語ミラー（2 箇所）も同じく直した。

Edges

Related

  • #1628 — semi_auto での停止条件オーバーランの実測（(b) の根拠）
  • #1691 / PR #1694 — リストを基準で閉じ、ラベル遷移を auto-load に残した判断
  • #1708 — operations skill の bar と、停止条件のポインタ化
  • #1684 / #1733 / #1864 — 指摘の経路の推移と (d) の追加
  • #1615 — 本文から理由を本 entry へ移した組み直し