The Push Before Midnight, and What It Could Cost Your Craft XP

A qualifying GitHub push made after a Craft quest is created can earn full XP in LifeQuest. It turns a visible record of work into evidence-weighted progress, while self-report remains available for half XP when that proof does not fit.

A record that has to exist outside the app

In 2005, the Linux kernel community needed a source-control tool after its relationship with BitKeeper broke down. Linus Torvalds began building Git, with a priority on a distributed system that could preserve a project’s history across many contributors. The uncertainty was practical: a huge, fast-moving codebase still needed a trustworthy way to track what changed and when.

The history survived because each contribution left a record that others could inspect. A commit has a place in a project’s timeline. A push makes that work visible in the repository.

Git’s origin story is documented in the Git project’s Pro Git book. Its lesson for a coding habit is straightforward: progress becomes more useful when it leaves a record you can return to.

A coding quest should work the same way. “Finish the failing test,” “ship the portfolio update,” or “refactor the login flow” can be real work, but tapping a generic checkbox does not distinguish a completed task from a good intention.

The last push before midnight

Imagine the final minutes of a student’s day. The quest was created earlier: fix a bug in a class project, make the tests pass, push the change before midnight. The student works through the failing case, changes the code, runs the test again, then sends one qualifying push to GitHub.

That push is the moment LifeQuest can use.

After connecting a GitHub username in Profile, a student with a Craft-domain quest can choose GitHub push verification. LifeQuest checks for a qualifying public push made after the quest was created. When the record matches, the quest earns full Craft XP.

The order matters. A commit from last week may be real work, but it cannot verify a quest created today. The system looks for evidence connected to the work the student chose to do, rather than treating a long-standing commit streak as proof of every new goal.

GitHub verification is also purposefully narrow. It can confirm a qualifying public push, not explain how difficult the code was, how long the student worked, or whether the change deserved praise. Those are different questions. The value is simpler: the student completed a coding task and created a checkable record after committing to it.

GitHub events can take up to five minutes to appear in the verification flow. A push made seconds ago may need a little time before LifeQuest can find it. That delay is less satisfying than an instant green check, but it keeps the claim tied to the record rather than a device-side guess.

Full XP for evidence that fits coding

A push is a strong fit for some Craft quests. It is a poor fit for others.

If the quest is “practice pencil shading for 20 minutes,” GitHub has nothing useful to say. If it is “complete a JavaScript exercise and publish the solution,” a push gives the quest a visible trail. LifeQuest lets the student choose the method that genuinely fits: GitHub verification for qualifying coding work, a server-timed focus session for sustained work, photo proof where a current image can help, or self-report for half XP when objective proof is impractical.

That choice matters because no single checkbox can describe every kind of effort honestly.

For coding, the payoff is more than a brighter completion screen. The student can look back at Craft progress and know that full XP came from a specific kind of evidence. The quest, the push, and the reward point in the same direction.

For a fuller look at what a GitHub streak can and cannot show, read What Did I Actually Get Better at With a GitHub Streak?.

Build the quest before the commit

The useful habit is small: create the coding quest before opening the editor. Give it a concrete finish line, such as “push the completed API exercise” or “commit the accessibility fix.” Then work, push, and verify the record that follows.

That structure creates a clean sequence:

• Make the quest specific enough to recognize when it is done.
• Create it before the qualifying push.
• Connect the public GitHub username before verification.
• Allow a few minutes for GitHub activity to appear.
• Use self-report when a push cannot honestly represent the work.

Torvalds’s 2005 problem was much larger than a student’s late-night coding task, but the mechanism carries: a shared history is valuable because it can be checked. One push before midnight will not measure every part of learning to code. It can make one completed piece of work visible, and LifeQuest can award full Craft XP for that evidence.