Plan and accept work

Reference note: The release-pinned local workflow guide retains older optional-extra installation instructions and describes forms intake as future work. Those statements conflict with the 1.3.0 package metadata and released GUI. Use Get started and Dependencies and reference for 1.3.0 setup. Treat that older guide as an input-limit/design reference.

Use the isolated environment and release example checkout from Get started. R names that checkout.

How does a sample plan become accepted?

Prerequisite: Harness 1.3.0. P = prepared Git checkout, T = new task outside P, R = release checkout, PY = active Python.

1. Run: attune-harness init --for plan --goal "Repair addition" --project "$P" --scope calc.py --interpreter "$PY" --tests tests/test_calc.py --task-dir "$T"
2. Run: attune-harness plan --request "$T.work.json" --project "$P" --config "$R/examples/starter/participants.json" --task-dir "$T". Copy checkpoint_digest into C.
3. Inspect the preview. If its scope is correct, run: attune-harness plan --task-dir "$T" --accept --checkpoint "$C"

Expected: JSON shows status “accepted”. calc.py still contains a - b.

Limit: Acceptance starts no build. The starter reviewer approves without judging.

This is a released CLI alternative to the proposed specification editor. Use a fresh disposable Git checkout, not a working project. Activate the environment with Harness 1.3.0 first. examples/ comes from a repository checkout, not the installed package. Set R to an absolute checkout path at the pinned release commit. Set P and T to unused absolute paths, with T outside P. For example, after setting R:

P="$PWD/training-plan-project"
T="$PWD/training-plan-task"
PY="$(python -c 'import sys; print(sys.executable)')"
mkdir -p "$P/tests"
printf 'def add(a, b):\n    return a - b\n' > "$P/calc.py"
printf 'from calc import add\n\ndef test_add():\n    assert add(2, 2) == 4\n' > "$P/tests/test_calc.py"
git init "$P"
git -C "$P" add calc.py tests/test_calc.py
git -C "$P" commit -m "Training fixture"

Run the three actions. Set C to the full checkpoint_digest returned by step 2, for example C='the-full-returned-digest'. It changes with your task; do not copy a digest from someone else's report. Step 1 returns created and writes $T.work.json beside the task directory. Step 2 returns draft with no missing questions for this fixture. Step 3 returns accepted. Confirm with:

attune-harness status "$T"

This process stops before build. It exercises request creation and the checkpoint-bound acceptance decision. It does not prove that a plan is good or that an independent reviewer judged it. For real participants and build authority, read Plan and build.

Verification scope

All four processes ran against installed Harness 1.3.0 on macOS in isolated synthetic tasks. The two browser sequences used fresh headless Chromium contexts. Navigation reached accepted; continuity retained its saved goal after a listener restart and remained draft. Planning returned created, draft, then accepted; it changed no sample source and created no build run. Retrieval returned two matching Markdown sources, and verification passed the single supported link claim with semantic checks absent.

These observations establish those local sample outcomes. They do not qualify Windows, real participant quality, paid-provider behavior or all possible projects. No released code changed for this training update. The broader workspace navigation, specification editor and browser execution/resume designs are outside the 1.3.0 forms boundary.

The released CLI guide, local workflow guide and saved memory guide retain the implementation baseline independently of current development docs.