Build your first report

Build a report you can explain

Turn six synthetic activity entries into a formatted report, while keeping the input and checks protected.

Open the formatted report. It accounts for 6 entries and 270 minutes. Orion has 180 minutes and Lumen has 90.

This lesson practices the current Harness 1.7.0 workflow with fixed local command participants. The worker supplies known reference code; the protocol reviewer does not judge its quality. The protected tests check the actual program. No model or provider is called.

For real implementation, your assistant needs participants suited to the task and the execution authority you choose. Start with the offline practice to understand the decisions.

Choose your starting path: this bounded reporting exercise starts from a clear goal. If your real project has several workflows or unresolved requirements, use the goal-driven and spec-driven reference to choose the preparation it needs before accepting a plan.

Start in an isolated practice folder

Use the Python 3.12 environment from the course setup.

Complete the course setup first. Keep the same terminal, with COURSE_WORK set and the course folder open. These commands use a POSIX shell on macOS or Linux.

The helper creates an unfinished report.py, two test files, the CSV, expected output, a local participant registry and a work request. It initializes a disposable Git checkout. It accepts nothing and starts no build.

practice setup

PRACTICE="$COURSE_WORK/practice"
python practice.py "$PRACTICE"

Ask what may change and how it will be checked

Prepare the draft, then inspect its complete scope before deciding.

Keep the same terminal and PRACTICE value. The task and request live beside the project, outside the checkout whose inputs Harness freezes.

Expect draft, no missing questions and a checkpoint_digest. Read the goal and both test criteria. Only report.py may change. The tests, input, expected outputs, registry and pytest configuration are protected.

If anything is wrong, stop and revise through the supported workflow. Editing the original request after preview does not update the saved task.

plan preview

python -m attune_harness plan --request "$PRACTICE/task.work.json" \
  --project "$PRACTICE/project" --config "$PRACTICE/project/participants.json" \
  --task-dir "$PRACTICE/task"

Agree to the exact request

Acceptance records the scope you reviewed; execution is another decision.

Copy the full checkpoint_digest from your own preview into PREVIEW_CHECKPOINT. If the displayed request is correct, accept that checkpoint. Expect accepted and a new current checkpoint.

You have not completed the implementation by accepting its scope. In a browser intake, Approve this work request and Keep as draft record the corresponding intent decision; this command practice uses the CLI.

scope acceptance

PREVIEW_CHECKPOINT="replace-with-your-full-preview-digest"
python -m attune_harness plan --task-dir "$PRACTICE/task" \
  --accept --checkpoint "$PREVIEW_CHECKPOINT"

Give the local commands a bounded go

Inspect the registry before authorizing the prepared offline build.

The practice registry uses two fixed local commands. They make no API or native-model request. Read their configuration and the permitted effects before running the build command.

--allow-external permits these local subprocess participants. It is not a funding grant or a security sandbox. For real model work, review the current participant setup and funding guide; do not infer your route from this fixture.

Expect completed only after the configured checks actually pass. If the command fails, inspect its saved error and journal before choosing a next action.

offline build

python -m attune_harness build "$PRACTICE/task" --allow-external

Separate a completed task from a trustworthy claim

Read the saved outcome and the tests that support it.

Inspect the saved task. Find the permitted file change, task probe and final probe. The November 5 course check recorded 77 cases in the two reporting test files. The fixed reviewer exercises the review protocol. For a real implementation, assess the result against your own criteria.

Compare the hashes of the input and protected files before and after the build. A passing result supports the cases that ran.

saved task inspection

python -m attune_harness status "$PRACTICE/task" --format markdown

Take the checked result into your browser

Run the completed program against the unchanged six-row CSV.

Move into the practice project. Save the report beside the project so the saved work’s input snapshot stays unchanged.

Expect Saved report to …. Open that file and check 6 entries, 270 minutes, the project totals and the date range against the CSV. If you run this command again, choose a new filename.

report command

cd "$PRACTICE/project"
python report.py data/activity.csv --format html --output "$PRACTICE/activity-report.html"

Leave the work ready to inspect tomorrow

Explain one result, one boundary and the next decision.

Your result and next decision

Write your answer in your own notes, or use the interactive lesson.

In the interactive lesson, these notes stay in your browser. They do not change or approve the Harness task.

Continue with Come back tomorrow to inspect saved work before continuing. Use Decide whether to trust the report to connect a claim to independent evidence.