Project: a tested task report and English demo

What you will build

• A local task-report project with meaningful tests and evidence.
• A clear README and short English explanation.
• A labelled self-assessment using the rubric below.

Project contract

Build in a new personal practice project, using dummy data. Keep company code, customer data and secrets out. Use PHP/Laravel with MySQL and optionally reproduce the counting function in Python. Windows and Ubuntu are supported choices; Laragon/XAMPP are optional local tools. This is a practice product, not a public task service until authentication, authorization, deployment and security have been designed and verified.

The report must show each person's total and done task count, including zero-task people. Define what todo, in_progress, done and unknown mean for imported data. Validate task proposals, select allowed fields, and give useful errors. Separate preview from real storage. Do not label a preview as saved. Decide explicitly whether this first project only reports a fixture or also creates records; document your scope.

Step-by-step build

1. Write a README with your chosen runtime versions, setup commands, data contract, scope and expected counts. Confirm your database is an isolated practice database before creating tables.
2. Reuse the people/tasks schema from the SQL lesson. Keep keys/constraints. Add fixtures for two tasks for one person, a person with one task and a person with none.
3. Write the report query with LEFT JOIN and non-null child counts. Predict the result before running it. Keep person identity in grouping.
4. Extract the PHP in-memory report into a function. Return counts, keep display outside, and handle unknown statuses according to a documented contract.
5. Add a Laravel preview with framework validation and explicit accepted fields. Start with the earlier tested preview. If you add storage, use validated input, real per-user authorization, safe transactions where appropriate, and separate success/failed-write tests. Do not publish it as a multi-user service based only on this brief.
6. Test the cases in the evidence table. Record exact commands/results and what you did not test. Do not fabricate a passing result.
7. Save small Git commits after reviewing the staged diff. Include source and lockfiles, not credentials, vendor directories or local virtual environments.
8. Write one bug/verification report and record a 60–90 second English demo. Explain one choice and one limitation.

Evidence checklist

Keep tests in your own repository. A link, screenshot or note is evidence to inspect, not automatic proof of correctness. Use the private Practice journal to save project evidence, a link and labelled self-assessment. The site stores your report; it does not fetch or execute your repository, verify the evidence, or award a project pass.

Worked planning example

Scope: Local fixture report and validation preview; no task persistence.
Expected: Asha total 2/done 1; Robin total 1/done 0; Maya total 0/done 0.
First check: Run original SQL and the Laravel preview feature tests.
Next change: Add a zero-task person with the same name as another person.
Limit: No production hosting or multi-user task permissions tested.

Replace the plan with your actual completed evidence as you work. Planned checks are not passes.

Guided review

Run the original SQL and framework labs before adapting them. Introduce one defect in a disposable copy, such as COUNT(*) for child counts, observe a failing check, then restore the correction. Explain which assertion catches it. Do not alter the learning website or another person's data for this exercise.

Independent extension

Add a todo count while preserving zero-task people, or implement the same counting contract in Python. Compare expected results using the same dummy fixture. Pick one extension and finish its tests rather than collecting unfinished features. Keep an English explanation of any type/null differences between implementations.

Common mistakes

• Treating a screenshot as sufficient test coverage.
• Claiming persistence after a validation-only preview.
• Ignoring empty/missing/invalid data or duplicate names.
• Publishing practice code without account/ownership controls.
• Giving yourself a pass without recording evidence.

English practice and glossary

Explain: “This project solves __. The input contract is __. I tested __. One limitation is __. My next improvement is __.” Keep technical terms accurate. A rubric is a set of review criteria; evidence is something another person can inspect; a limitation is a boundary of what you built or verified.

Review rubric — self-assessment

Score each area against recorded evidence. Mark it self-assessed; a total does not award a site quiz pass, interview guarantee or professional certification. Ask a reviewer to rerun the project when possible.