Make it work for your needs

Ask the next question the report does not answer

The report summarizes both projects. A person responsible for Orion may want to see only Orion without manually editing the input.

That is a useful next request: select one project while keeping the original data and unfiltered reporting behavior intact.

The supplied program currently accepts a CSV file, a text or HTML format and a new output path. It has no project-filter option. This lesson prepares and reviews the change; it does not claim that filtering has been implemented.

You will define the behavior, calculate independent acceptance examples and leave a clear stopping note. Use fewer hints where you can, and reopen earlier lessons when useful.

Read the course setup instructions for the published Harness 1.7.0 runtime. Use the accompanying current software-check record for the supplied baseline.

Know what must stay unchanged

Inspect the existing result before proposing a new option.

From the extracted example folder, inspect the actual usage guide, the input and expected report. Read this baseline command before running it; it prints a report locally without a model call.

Expected baseline: 6 entries and 270 minutes; Orion 180, Lumen 90; Development 150, Documentation 75 and Testing 45.

Keep data/activity.csv and the existing expected outputs intact. Preserve the current source revision and test evidence before creating a separately scoped working copy.

Ask your assistant to identify the parser, aggregation and formatting paths in the actual source. An improvement brief should name real affected files after inspection rather than treating a desired option as an existing capability.

baseline command

python3.12 report.py data/activity.csv

Make the scope small enough to review

A bounded change states what should differ and which existing promises must survive.

This is a proposed project change, not a saved accepted Harness plan. Ask for the supported plan and current checkpoint before execution.

Choose answers the implementation cannot invent

Calculate expected project results directly from the original six rows.

Orion is 90 + 30 + 45 + 15 = 180. Lumen is 60 + 30 = 90. These are independently derived expectations for a proposed change, not results from an implemented filter.

1. Require the same selected rows and totals in text and HTML.
2. Retain the no-selection baseline and existing validation and file-output cases.
3. Settle unknown-project and name-matching behavior before freezing expected outcomes.
4. Keep any additional tests separate from a claim that the baseline checks already cover the new feature.

An HTML bar should be interpreted within the filtered result. Decide how an absent category is presented rather than silently turning a missing row into zero in the product contract.

Carry the brief into the supported workflow

Use Harness to retain reviewed scope and checks after the product decisions are clear.

Read this prompt before sending it. It requests preparation and inspection, not implementation or a provider call.

1. Inspect the actual project, existing changes and current evidence.
2. Settle open selection decisions and prepare independent checks from the acceptance examples.
3. Prepare the supported request with exact file effects, protected checks, configured participants and budgets. Inspect its checkpoint before accepting scope.
4. Authorize execution separately only when the current request and its execution route are understood.

Use the current 1.7.0 course setup and practice guidance for the selected runtime and supported preparation route. A prose change brief is not an accepted executable task.

Preserve the six-row fixture and baseline outputs. Current software checks use deterministic local work; a future model-assisted implementation needs its own reviewed participant configuration and applicable authority.

change planning prompt

Help me prepare a bounded project-selection improvement to the supplied reporting program. Inspect the actual source and existing changes first. Preserve the six-row fixture, unfiltered expected reports, baseline tests and current evidence. Use the filled change brief and independently derived Orion/Lumen totals. Ask me to settle the option name, matching and unknown-project behavior before freezing checks. Prepare a supported Harness request with exact file effects, protected checks, participants, budgets and its current checkpoint. Keep preparation read-only; stop before acceptance, implementation or provider work. Do not assume that the program already has a project-filter flag.

Explain your own next decision

Suppose the intended reader manages Lumen, not Orion. Prepare the smallest revision to the request before asking for implementation.

In your own words, state the useful result, one independent expected answer, what stays protected and the next decision. You can use the Lumen totals from the original rows to check your answer.

Your Lumen variation

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

This optional note stays in local browser storage when available. It accepts your wording and does not save or approve a Harness task.

Explain why changing the original CSV to remove Orion would be a weaker test of a reusable filter: it loses the full-data input that the new behavior is supposed to select from.

Make the next session easy to start

Finish with a clear account of what is proposed, what is established and what needs a decision.

Keep this note with the project guide when you choose to continue. Preserve the baseline and correct an inaccurate claim rather than changing an expected answer to match the new implementation.

Next: Open Tutorial 1: Turn an idea into a useful result when you want to frame a different outcome, or return to the lesson matching your current decision.