Write the project contract
The center receives a CSV with an identifier, client, task, and deadline. It shows the orders, highlights missing fields, and allows exporting the result. The first MVP works locally, without sending messages, user accounts, or integration with calendars.
Define the unit: one line corresponds to one order. Repeated identifiers require an explicit decision. If the content is the same, they may represent a new attempt; if it’s different, they must appear as a conflict. This rule needs to exist before drawing the screen.
Why learn
The contract combines the initial learnings and prevents the project from growing before it works. It establishes a delivery that can be demonstrated with a few files.
✓ Do
Separate data rules from the interface.
✗ Avoid
Add login before validating the import.
Key concepts
Prepare the test data
Assemble a file with complete orders, a missing deadline, a long name, and a repeated identifier. These are test cases, not accidents to fix manually. Keep a table with the expected result for each one.
Use only fictitious data in the exercise. The file can be shared with anyone reviewing the project without loading real information. If you use commas inside fields, check the appropriate CSV format and how the chosen tool reads it.
Why learn
A varied set prevents the center from working only with the first row. The expected result is a reference during implementation and review.
A way to apply
- Define contract and fictitious data with expected results.
- Implement import, validation, list, and export.
- Demonstrate the cases and record the review.
Key concepts
Draw a small flow
Represent import, validation, list, and export. An invalid entry needs a message that allows correcting the file. The error must not erase the orders already loaded without explaining it.
Separate file reading from validation rules. This split makes it easier to test behavior without depending on the interface. A function can accept records and return valid records, pending items, and conflicts, which the screen shows afterward.
Why learn
This separation reduces coupling and makes review clearer. You can investigate a data rule without having to redo the whole visual experience.
id,client,task,deadline
P-01,North fictitious workshop,Review catalog,2026-11-02
P-02,Fictitious Lua studio,Organize images,
P-01,North fictitious workshop,Review catalog,2026-11-02
Expected rule: P-01 doesn’t duplicate; P-02 keeps a pending deadline.
Key concepts
Build the first delivery
Ask the assistant to implement only the defined flow. Deliver contract, fictitious data, expected results, and constraints. Request that it explains how to run and verify the solution. Choose a technology you can maintain.
After the first version, manually test the cases. Don’t treat the assistant’s statement as proof. Open the exported file in another tool and confirm columns, accents, number of lines, and preservation of pending items.
Why learn
The implementation gains a clear limit and a definition of done. Opening the output in another tool checks whether the result is usable outside the original screen.
✓ Do
Open the exported CSV in another program.
✗ Avoid
Hide duplicates only in how the table looks.
Key concepts
Review the failure points
Test repeated import, an empty file, and invalid content. A new attempt must not silently duplicate orders or replace data without warning. Also check the behavior when the browser’s storage is unavailable.
Do an independent review of the code and results. Prioritize data loss, duplication, and incorrect export. Visual improvements come later once the main flow is reliable. Record known limitations in the README.
Why learn
The tests bring the tool closer to real usage conditions. The review finds risks that don’t appear in the demonstration of a single successful path.
| Criterion | Expected evidence |
|---|---|
| Flow | Importing and exporting preserves fields and accents. |
| Pending item | Missing deadline is still identified. |
| Repetition | The same input does not produce extra effects. |
Key concepts
Practice: demonstrate the center
The final delivery brings together the tool, the fictitious data, the exported file, and a record of the checks. Do a short demonstration: import, locate the pending item, handle a duplicate, and export.
If any part still fails, describe the case and the smallest correction needed. Don’t mark the whole project as finished because the screen opened. Completion depends on the criteria defined at the start, which must remain visible during the review.
Why learn
The project shows how several Pílulas turn into a small tool. It also teaches how to deliver a result another person can verify and continue with.
Your exercise
Implement or prototype the center using the example data. Add a P-01 with a different task and describe how the conflict appears. Deliver README, input, and output.
Download practice sheetCheck the commented answer
An identical P-01 is treated as a repetition. A diverging P-01 appears as a conflict that needs a decision, without silently replacing the first task. P-02 remains with a pending deadline. The export must allow distinguishing accepted records from pending items or conflicts according to the adopted contract.
Check your understanding
When can the MVP be considered finished?
Key concepts
What stays from this module
A local center that imports orders, preserves pending items, and exports a table.
- ✓ Importing and exporting preserves fields and accents.
- ✓ A missing deadline is still identified.
- ✓ The same input doesn’t create extra effects.
Progress records your reading. The practice is completed when you check the submission.