Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions notes/pr10_update_summary.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# PR #10 Update Summary

## Provider-facing request form final shape

The branch now defines one copy-paste-ready request form for the provider side
to fill and return.

## Intake check final shape

The branch now defines a yes/no intake gate that rejects partial route data,
generic provider advice, and missing landing confirmation.

## Ready condition after acceptance

A packet is ready only when the form is fully filled, intake is `yes`, the
landing target is `/workspace/parameter-golf`, and the route is immediately
executable.

## Current label

`continue_sharpening`
20 changes: 20 additions & 0 deletions notes/tpi_011_decision.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
# TPI-011 Decision

## Current bottleneck

The only blocker is the absence of one filled provider-facing handoff packet.

## Decision label

`continue_sharpening`

## Exact next action

Send the fixed request form, receive one filled packet, and judge it with the
yes/no intake check.

## Branch rule

- no filled packet: `continue_sharpening`
- filled packet accepted and landing verified: `promote_to_execution_resume`
- filled packet accepted but attach or landing fails: `move_to_failure_ledger`
35 changes: 35 additions & 0 deletions notes/tpi_011_intake_check.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
# TPI-011 Intake Check

## Yes / No gate

Answer `yes` only if all of the following are true:

- pod identity is present
- landing target is confirmed as `/workspace/parameter-golf`
- workspace confirmation is present
- one concrete route is present

## Route-specific checks

### `provider_attach_command`

Answer `yes` only if:

- `exact_attach_command` is filled

### `ssh_tuple`

Answer `yes` only if all are filled:

- `host`
- `username`
- `port`

## Reject as `no`

- generic provider advice only
- local SSH key existence only
- route type is named but route value is missing
- landing target is not confirmed

Any missing field means reject and keep the label at `continue_sharpening`.
24 changes: 24 additions & 0 deletions notes/tpi_011_ready_condition.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
# TPI-011 Ready Condition

Ready means the workflow may begin the fixed verification sequence immediately.

## Ready only when all of the following are true

- the request form is fully filled
- the intake check result is `yes`
- the landing target is `/workspace/parameter-golf`
- the concrete route is immediately executable

## Verification sequence

```bash
pwd
ls /workspace
cd /workspace/parameter-golf
git rev-parse --abbrev-ref HEAD
python3 -c "import torch, datasets, sentencepiece; print('deps-ok')"
nvidia-smi
```

Resume unchanged baseline and candidate execution only after landing
verification succeeds.
22 changes: 22 additions & 0 deletions notes/tpi_011_request_form.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
# TPI-011 Provider-Facing Request Form

Send this exact block to the provider side and request one fully filled reply.

```md
Please return one filled handoff packet in this exact shape.

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>
```

Control note: partial metadata or generic instructions are not sufficient.