Test plan quality against a real issue, before stage 5 spends anything on it #10

New Issue

grenade · 2026-08-07T12:40:35Z

grenade commented

2026-08-07 12:40:35 +00:00

Goal

design.md §9 names plan quality as the load-bearing unproven assumption: the
whole economic argument — Opus plans, a 27B model implements — rests on
tireless-authored plans being specific enough to execute alone. The design puts
the test in stage 3, which is three stages away.

It can be tested today, by hand, for the cost of tokens that would be spent
anyway. If prompt/plan.cc.md needs restructuring, that moves ChildSpec,
plan::validate, and all four prompts — and it is far cheaper to learn that
before a database schema and a dashboard are built around the current shape.

Structural validation is already in place and is not the question. What is
unknown is semantic quality: whether a plan that satisfies the schema is also
correct and specific enough in substance. No validator catches a well-formed
plan that is simply wrong about the codebase.

Files

prompt/plan.cc.md — whatever the exercise shows needs changing
crates/tireless-entities/src/plan.rs — only if ChildSpec is missing
something the exercise reveals
doc/plan/design.md §9 — record the finding either way

Steps

Pick a real issue from this repo's backlog that has not been decomposed —
one of the larger stage 2 or stage 4 items is a good subject.
Run Claude Code against this repo with
--append-system-prompt "$(cat prompt/plan.cc.md)" and that issue as the
task.
Read the output as plan::validate would: does every child carry all five
sections, at least one runnable acceptance command, and a non-empty boundary?
Then read each child the way the implementer will — cold, with no memory of
the planning conversation and no view of the other children. Could you start
from it alone? Do you know which files to open, when to stop, what to leave?
Where a child fails that reading, work out whether the fault is the prompt or
the model, and change the prompt only if it is the prompt.
Record the result in design.md §9, including a negative result. "The prompt
is fine and the risk is lower than feared" is a valuable finding.

Acceptance

cargo test --workspace (the prompt tests assert the required sections are
still named; changing the prompt must not break them)
A plan produced by the current plan.cc.md against a real issue is pasted
into this issue, along with the reading from step 4.
design.md §9 is updated with what was learned.

Out of scope

Implementing anything the plan describes. This issue is about the plan.
Building the stage 3 executor, the parser, or any automation. This is
deliberately a manual exercise — its whole value is that it does not wait for
the machinery.
Changing implement.oc.md based on speculation. If the exercise shows the
plan side needs a change, the pair moves together (invariant 8) — but do not
edit the implementation prompt for reasons this exercise did not produce.
Bumping contract-version: unless ChildSpec actually changes shape.

## Goal design.md §9 names plan quality as the load-bearing unproven assumption: the whole economic argument — Opus plans, a 27B model implements — rests on tireless-authored plans being specific enough to execute alone. The design puts the test in stage 3, which is three stages away. It can be tested today, by hand, for the cost of tokens that would be spent anyway. If `prompt/plan.cc.md` needs restructuring, that moves `ChildSpec`, `plan::validate`, and all four prompts — and it is far cheaper to learn that before a database schema and a dashboard are built around the current shape. Structural validation is already in place and is not the question. What is unknown is *semantic* quality: whether a plan that satisfies the schema is also correct and specific enough in substance. No validator catches a well-formed plan that is simply wrong about the codebase. ## Files - `prompt/plan.cc.md` — whatever the exercise shows needs changing - `crates/tireless-entities/src/plan.rs` — only if `ChildSpec` is missing something the exercise reveals - `doc/plan/design.md` §9 — record the finding either way ## Steps 1. Pick a real issue from this repo's backlog that has not been decomposed — one of the larger stage 2 or stage 4 items is a good subject. 2. Run Claude Code against this repo with `--append-system-prompt "$(cat prompt/plan.cc.md)"` and that issue as the task. 3. Read the output as `plan::validate` would: does every child carry all five sections, at least one runnable acceptance command, and a non-empty boundary? 4. Then read each child the way the *implementer* will — cold, with no memory of the planning conversation and no view of the other children. Could you start from it alone? Do you know which files to open, when to stop, what to leave? 5. Where a child fails that reading, work out whether the fault is the prompt or the model, and change the prompt only if it is the prompt. 6. Record the result in design.md §9, including a negative result. "The prompt is fine and the risk is lower than feared" is a valuable finding. ## Acceptance - `cargo test --workspace` (the prompt tests assert the required sections are still named; changing the prompt must not break them) - A plan produced by the current `plan.cc.md` against a real issue is pasted into this issue, along with the reading from step 4. - design.md §9 is updated with what was learned. ## Out of scope - Implementing anything the plan describes. This issue is about the plan. - Building the stage 3 executor, the parser, or any automation. This is deliberately a manual exercise — its whole value is that it does not wait for the machinery. - Changing `implement.oc.md` based on speculation. If the exercise shows the plan side needs a change, the pair moves together (invariant 8) — but do not edit the implementation prompt for reasons this exercise did not produce. - Bumping `contract-version:` unless `ChildSpec` actually changes shape.

grenade added the tireless/implement tireless/agent:cc labels 2026-08-07 12:41:02 +00:00

grenade referenced this issue

2026-08-07 12:41:14 +00:00

Stage 1 — forge ingestion (read-only) #1

grenade referenced this issue from a commit

2026-08-07 17:20:13 +00:00

feat(data): implement JobStore and the Gitea read client

Sign in to join this conversation.