Define the command and file contract
See this course’s project requirements
A local command-line converter that validates fictional attendance CSV, writes JSON to a chosen output and reports rejected rows without altering input.
Keep your working files in your own notebook or software. Save a private description, checklist, and work link in My Proof.
What to include
- A converter contract with two accepted and two rejected records.
- A CSV-to-typed-record trace with invalid-value evidence.
- A failure report distinguishing rejected rows from failed runs.
- A checked JSON output with 2 accepted and 2 rejected entries.
- A reusable command contract and a missing-argument test.
- A repeatable local CSV converter with failure and preservation evidence.
Review and revise
Use these criteria to check your work and choose what to improve.
- The implementation or declared simulation follows the supplied contract and retains inspectable original inputs.
- Normal, boundary and rejected cases are recorded with expected versus observed results.
- The changed case has a correct explanation and does not rely on hidden state.
- The project includes source, outputs, instructions and honest tool, privacy and verification limits.
Want more background?
The idea in everyday life
attendance.csv headers are id, minutes; rows A,30; B,45; C,-2; B,10. Valid IDs must be nonempty and unique; minutes are nonnegative integers.
A file-processing tool needs a declared schema, output path and failure policy. The supplied tool never edits its input; it can overwrite the explicitly chosen output, so choose a fresh practice path.
Define the command and file contract — original worked practice
A file-processing tool needs a declared schema, output path and failure policy. The supplied tool never edits its input; it can overwrite the explicitly chosen output, so choose a fresh practice path.
attendance.csv headers are id, minutes; rows A,30; B,45; C,-2; B,10. Valid IDs must be nonempty and unique; minutes are nonnegative integers.
1. Step 1
Write the two field definitions.
You should see: id is a unique nonempty label; minutes is a nonnegative integer.
This keeps the rule and its observable result together.
2. Step 2
Classify the four rows.
You should see: A and B are accepted; C is negative and the second B duplicates an accepted ID.
This keeps the rule and its observable result together.
3. Step 3
SELECT separate input and output paths.
You should see: attendance.csv and results.json differ.
This keeps the rule and its observable result together.
4. Step 4
Write expected accepted and rejected counts.
You should see: A converter contract with two accepted and two rejected records.
This keeps the rule and its observable result together.
What to finish
A converter contract with two accepted and two rejected records.
Watch for this
Overwriting the source file because the output name was not checked against the resolved input path.
How can I tell I understand it?
Explain and demonstrate the required distinction: A file-processing tool needs a declared schema, output path and failure policy. The supplied tool never edits its input; it can overwrite the explicitly chosen output, so choose a fresh practice path. Show a changed input and the expected result without weakening this contract.
Quick knowledge check
Answer all 3 questions. Get at least 2 right and the lesson completes automatically.
You’ll get an explanation for each answer. Signed in? Your results save to your account.
Pass the check. We’ll save the progress.
Answer all 3 questions above and get at least 2 right. You can review the explanations and try again.
Go to the knowledge checkTools, templates, and lesson sources
Tools and templates
Tools open in a new tab so you can keep your place here.
Sources and further reading
Explore the references behind this lesson.
Source & access notes · checked 2026-10-01
Relevant documented module/API behavior inspected during expansion authoring; actual execution evidence is recorded separately. No grant eligibility is established.
Access: Official page retrieved with the web reader on 2026-10-01. Documentation reading does not certify execution in every native tool or browser.
Reuse: Original local practice files, fictional data, worked examples and questions. Concepts paraphrased and linked; source exercises are not copied.
Source & access notes · checked 2026-10-01
Relevant documented module/API behavior inspected during expansion authoring; actual execution evidence is recorded separately. No grant eligibility is established.
Access: Official page retrieved with the web reader on 2026-10-01. Documentation reading does not certify execution in every native tool or browser.
Reuse: Original local practice files, fictional data, worked examples and questions. Concepts paraphrased and linked; source exercises are not copied.
Report a problem with this lesson
Tell us what went wrong. Please leave out personal information and private project contents.