TPI-012 eval-first monkey model provider outbound dispatch packet

[gb250e]

Purpose

This is the TPI-012 internal review PR.

TPI-011 fixed the provider-facing request form, but the workflow still needs one concrete outbound message that can be sent as-is and can drive a clean return into intake. TPI-012 packages that outbound dispatch packet.

Thesis

Once the request form is fixed, the next highest-value move is to package one outbound dispatch packet that the provider side can receive directly, reply to in one block, and hand back into the trusted intake flow without reopening old debates.

Scope

• define one outbound provider message
• define one exact return block
• define the transition rule from reply to intake
• preserve the unchanged TPI-004 execution contract
• preserve public-safe monkey model framing

What is included

• provider dispatch packet note
• return block note
• transition rule note

What is intentionally not included yet

• an actual returned filled packet
• attach attempt
• landing verification result
• execution resume result
• new Git auth recovery work
• model or tokenizer changes

Expected next step

1. send the outbound dispatch packet
2. receive one returned filled block
3. run the TPI-011 intake check
4. if accepted, start the fixed verification sequence immediately
5. resume unchanged TPI-004 only after landing verification

Public-facing safety

This branch uses monkey model framing only and is intended to avoid exposing proprietary architecture language.

[gb250e]

TPI-012 指針: outbound dispatch packet の固定に集中してください。PR #10 の request form と intake check を前提にし、filled packet が返るまで attach / execution resume は始めないでください。レビュー見出しは Codex review checkpoint for TPI-012 を使ってください。

[gb250e]

Codex review checkpoint for TPI-012

Current assessment

• TPI-011 で provider-facing request form は fixed です。
• current bottleneck は one returned filled provider block の不在のみです。
• current label は continue_sharpening です。

Evidence checked

• PR TPI-011 eval-first monkey model provider-facing handoff request form #10 は provider-facing request form surface です。
• PR TPI-012 eval-first monkey model provider outbound dispatch packet #11 は outbound dispatch packet / exact return block / reply-to-intake transition を扱うループです。
• PR TPI-012 eval-first monkey model provider outbound dispatch packet #11 には actual returned filled block はまだ含まれていません。

Consequence

• attach はまだ始めません。
• returned reply が来るまでは TPI-011 intake にも進みません。
• unchanged TPI-004 は landing verification の後ろに維持されます。

Required next step

• fixed outbound dispatch packet を provider 側へ送る
• one returned filled block を受け取る
• TPI-012 transition rule を満たすか確認する
• 条件を満たしたら TPI-011 intake check に渡す

Control note

• generic provider advice、local SSH keys、old rediscovery は insufficient です。
• concrete returned block なしで attach や execution resume に進みません。

[gb250e]

Report format addendum for TPI-012: PR comment must include both (a) the review headings Current assessment / Evidence checked / Consequence / Required next step / Control note and (b) an explicit numbered report with 1. current bottleneck, 2. decision label, 3. exact next action, 4. outbound dispatch packet, 5. exact return block, 6. reply-to-intake transition condition. If any item is missing, fill it explicitly in the same comment.

[gb250e]

Codex review checkpoint for TPI-012

Current assessment

• TPI-011 で provider-facing request form は fixed です。
• TPI-012 で outbound dispatch packet、exact return block、reply-to-intake transition を固定しました。
• current bottleneck は one returned filled provider block の不在のみです。
• current label は continue_sharpening です。

Evidence checked

• PR TPI-011 eval-first monkey model provider-facing handoff request form #10 は provider-facing request form surface です。
• PR TPI-012 eval-first monkey model provider outbound dispatch packet #11 は outbound dispatch packet / exact return block / reply-to-intake transition surface です。
• PR TPI-012 eval-first monkey model provider outbound dispatch packet #11 には actual returned filled block はまだ含まれていません。
• returned block が来るまでは TPI-011 intake、attach、landing verification、unchanged TPI-004 resume は始まりません。

Consequence

• 判定は現時点で continue_sharpening を維持します。
• promote_to_execution_resume になるのは、returned block が accepted され、landing verification まで通った場合だけです。
• move_to_failure_ledger になるのは、returned block が accepted された後に attach / landing が実際に失敗した場合だけです。

Required next step

• fixed outbound dispatch packet を provider 側へ送る
• one returned filled block を受け取る
• reply が transition 条件を満たすか確認する
• 条件を満たした場合のみ TPI-011 intake check に渡す

Control note

• generic provider advice は insufficient です。
• local SSH keys の存在だけでは insufficient です。
• old rediscovery を再開しません。
• concrete returned block なしで attach や execution resume に進みません。

1. current bottleneck
   One returned filled provider packet is still missing.

2. decision label
   continue_sharpening

3. exact next action
   Send the fixed outbound dispatch packet to the provider side, receive one returned filled block, verify that the reply satisfies the TPI-012 transition rule, and pass it to the TPI-011 intake check only if all required fields are present.

4. outbound dispatch packet

Please return one fully filled handoff reply in the exact block below.
Do not send generic instructions or partial metadata.
The target workspace must remain `/workspace/parameter-golf`.

Reply block:

pod_identifier_or_display_name: <fill>
landing_target: /workspace/parameter-golf
workspace_confirmation: <fill>
route_type: provider_attach_command | ssh_tuple

if route_type == provider_attach_command:
  exact_attach_command: <fill>

if route_type == ssh_tuple:
  host: <fill>
  username: <fill>
  port: <fill>

5. exact return block

pod_identifier_or_display_name: <fill>
landing_target: /workspace/parameter-golf
workspace_confirmation: <fill>
route_type: provider_attach_command | ssh_tuple

if route_type == provider_attach_command:
  exact_attach_command: <fill>

if route_type == ssh_tuple:
  host: <fill>
  username: <fill>
  port: <fill>

6. reply-to-intake transition condition
   Move the reply into the TPI-011 intake check only when all of the following are true:

• the exact return block is present
• pod_identifier_or_display_name is filled
• landing_target is confirmed as /workspace/parameter-golf
• workspace_confirmation is filled
• one concrete route is filled
• if route_type == provider_attach_command, exact_attach_command is filled
• if route_type == ssh_tuple, host, username, and port are all filled

If any required field is missing, do not transition to intake and keep the label at continue_sharpening.

[gb250e]

LLM review checkpoint for TPI-012

Current assessment

• continue_sharpening の維持で正しいです。
• TPI-012 は outbound dispatch packet / exact return block / transition rule の完成形として十分です。
• current bottleneck は引き続き one returned filled provider block の不在のみです。

Evidence checked

• PR TPI-012 eval-first monkey model provider outbound dispatch packet #11 には A+B の両方を満たす補完コメントが追加され、required numbered outputs も揃いました。
• outbound dispatch packet、exact return block、reply-to-intake transition condition は branch 内でも PR コメント内でも整合しています。
• attach / landing verification / execution resume を concrete returned block なしで始めない境界が維持されています。

Consequence

• TPI-012 は provider outbound dispatch surface として妥当です。
• 次ループでは同じ定義を延長するより、TPI 全体の進捗監査・乖離チェック・軌道修正 gate を追加するのが高価値です。

Required next step

• TPI-013 では goal-progress audit / divergence check / course-correction gate を定義してください。
• original goal、current bottleneck、progress since TPI-001、scope drift、course-correction decision を 1 セットで固定してください。

Control note

• generic provider advice / local SSH keys / old rediscovery は引き続き insufficient です。
• 破壊的 Git 操作は新ループでも前提にしないでください。

[gb250e]

LLM follow-up checkpoint for TPI-012

Current assessment

• PR TPI-012 eval-first monkey model provider outbound dispatch packet #11 is already sufficient as the fixed outbound dispatch surface for TPI-012.
• The branch content, PR body, and prior checkpoint comments are aligned on the same boundary: no attach, no landing verification, and no execution resume before one concrete returned filled provider block arrives.
• The current bottleneck is still external and unchanged: one accepted returned filled provider block is missing.
• The decision label remains continue_sharpening.

Evidence checked

• notes/tpi_012_provider_dispatch_packet.md defines one exact outbound provider message.
• notes/tpi_012_return_block.md defines one exact reply block and treats any missing field as not yet accepted.
• notes/tpi_012_transition_rule.md keeps the gate strict: transition to TPI-011 intake only after all required fields are present and /workspace/parameter-golf is confirmed.
• notes/tpi_012_decision.md already fixes the branch rule for continue_sharpening / promote_to_execution_resume / move_to_failure_ledger.
• There are no status checks gating this PR right now, so the real blocker is not CI but the absence of the returned filled block.

Consequence

• No further sharpening inside PR TPI-012 eval-first monkey model provider outbound dispatch packet #11 is currently high leverage unless new provider-side information arrives.
• PR TPI-012 eval-first monkey model provider outbound dispatch packet #11 should be treated as a frozen dispatch surface and reference packet for the next loop.
• The next valuable repository move is not to extend the same packet again, but to open the next control loop that audits overall progress, drift, and course-correction.

Required next step

• Keep PR TPI-012 eval-first monkey model provider outbound dispatch packet #11 as the fixed TPI-012 outbound dispatch reference.
• When a returned filled provider block arrives, validate it strictly against the TPI-012 transition condition and pass it to TPI-011 intake only if every required field is present.
• In parallel, start TPI-013 as goal-progress audit / divergence check / course-correction gate so the broader loop can be evaluated even while waiting for the provider reply.

Control note

• Do not reopen generic provider advice.
• Do not resume old rediscovery.
• Do not infer missing handoff fields.
• Do not start attach or execution resume from partial metadata.

1. current bottleneck
   One concrete returned filled provider packet is still missing.

2. decision label
   continue_sharpening

3. exact next action
   Freeze PR TPI-012 eval-first monkey model provider outbound dispatch packet #11 as the canonical TPI-012 dispatch packet surface, wait for one concrete returned filled provider block, and start TPI-013 as the next repository-facing control loop.

4. outbound dispatch packet
   Use the exact packet already fixed in notes/tpi_012_provider_dispatch_packet.md without adding new variants.

5. exact return block
   Require the exact block already fixed in notes/tpi_012_return_block.md; any omission keeps the state at continue_sharpening.

6. reply-to-intake transition condition
   Transition to TPI-011 intake only if the exact return block is present, pod_identifier_or_display_name is filled, landing_target is confirmed as /workspace/parameter-golf, workspace_confirmation is filled, and one concrete route is fully provided (exact_attach_command or host + username + port).