Skip to content

MASTERY.md

Latest commit

 

History

History
85 lines (61 loc) · 3.35 KB

MASTERY.md

File metadata and controls

85 lines (61 loc) · 3.35 KB
Raw

Automated project grade — Fare & Budget Check

GitHub grades this project without waiting for a KODE Ń VIBE reviewer.

The pass rule

  • PASS — Nailed it: every required check passes in one run.
  • REVISE — Keep building: one or more required checks fail.

There is no averaging and no partial-pass score. Do not delete, skip, rename, or weaken a check. Fix the project, push again, and GitHub creates a new grade for that commit.

Automatic learner flow

  1. On the KODE Ń VIBE starter, choose Use this template to create your own repository.
  2. Create an attempt branch, for example git switch -c attempt/fare-budget. Keep the untouched starter on main.
  3. Build the acceptance checks, commit, and push the attempt branch. GitHub Actions starts the grade automatically; opening or updating a pull request to main is graded too.
  4. Open Actions → Automated project grade. Read the failed test names and logs if the result says REVISE.
  5. When the job summary says PASS — NAILED IT, save that run link as evidence.

Every repository's main branch is intentionally quiet, so unfinished starter code does not send false failure alerts. Grading starts automatically when you push an attempt branch or open a pull request to main.

Run the same grade locally

From the repository root, run:

python3 -B -I tests/run_tests.py

Every check must pass without skipping, deleting, or weakening a check.

  • Fare sharing rounds a positive share upward, preserves zero, and rejects an invalid fare or rider count.
  • Remaining money accepts an over-budget result while rejecting invalid inputs.
  • Budget labels are correct at the negative, zero, and positive boundaries.

The test names are the grading rubric; a failed name identifies what to revise.

Optional confidence check — not graded

No reviewer is required for the automated pass. These checks are still useful because automated tests cannot see every real-use or readability problem:

  • Run python3 fare_budget.py; the three labelled example lines are correct and readable.
  • Change the demo to use a zero fare, then an over-budget case; neither crashes.
  • Call fare_share(100, 0) in the Python prompt; the message names riders.
  • Confirm none of the three calculation functions contains input() or print().

Optional explain-back — not graded

Use these prompts to check your own understanding. They do not need a reviewer and they do not change the GitHub grade.

  1. Why does (fare_cents + riders - 1) // riders round a positive share upward?
  2. Why can money_left validly return a negative number while its inputs cannot be negative?
  3. What makes these functions pure, and how does that help the tests?

Evidence to keep

GitHub keeps the commit, logs, and grade automatically. Save only:

  • the commit SHA;
  • the successful Actions run URL; and
  • one sentence about what you would improve next.

Honest boundary

PASS means every published requirement checked by this project passed on one revision. It is formative evidence, not a certificate or proof of independent authorship. A learner controls their copy and can edit visible tests or workflows, and automation cannot prove complete usability, durable understanding, or professional readiness. Keep the supplied checks unchanged if you want the result to remain meaningful.