The 11:47 p.m. Push That Could Cost You Full XP

A GitHub push earns full XP only when it qualifies for the coding quest and happened after the quest was created. At an 11:47 p.m. personal cutoff, an unfinished function and an unverified push leave the outcome genuinely open.

In 1970, the Apollo 13 crew faced a problem with no obvious fit. Jim Lovell, Jack Swigert, and Fred Haise were in the lunar module while Mission Control in Houston needed to manage rising carbon dioxide. The available command-module filters were square; the lunar module accepted round ones. Engineers had to make the equipment they had work with the connection they needed.

Their solution is documented in Jim Lovell and Jeffrey Kluger’s Lost Moon: an adapter assembled from materials already onboard. It worked, and Apollo 13’s crew returned safely. But before it worked, having a useful filter was not enough. It had to fit the actual system.

The last minutes reveal what the quest requires

A late coding session has its own smaller version of that problem. You have the function half-written. Tests are failing in one branch. Your editor shows a clean-looking diff, but the quest requires a qualifying public GitHub push created after the quest began.

At 11:42 p.m., “I worked on it” and “I can verify it” are different statements.

That distinction can feel fussy when you are tired. It is also the point. LifeQuest lets a coding quest use GitHub verification because a qualifying push can connect work to a timestamped record. It does not make every push automatically eligible, and it cannot confirm work that happened before the quest existed.

A commit from earlier in the afternoon may contain excellent code. It simply cannot prove completion of a quest you created that evening. Noor’s earlier push explains that boundary in detail.

Finish the smallest complete piece

The pressure of a cutoff can tempt you to chase the whole feature. That is how a student ends up with three open files, a partly renamed function, and no commit worth pushing.

Instead, narrow the target. Make one function correct. Run the tests that cover it. Write a commit message that says what changed. Push it while there is still time to see whether GitHub records the event.

This is not an argument for rushing bad code. It is an argument for choosing a finish line you can reach honestly. A smaller completed change gives you something concrete to review tomorrow. A sprawling unfinished change gives you a browser tab full of intent.

LifeQuest’s GitHub option is available for quests tied to a Craft-domain skill. It checks qualifying public GitHub activity after the quest was created. GitHub events can be cached for several minutes, so a push made seconds ago may not appear immediately. That delay is frustrating near a self-imposed deadline, but pretending the event is already visible would make the record less trustworthy.

Let the evidence set the reward

If the push qualifies, full XP recognizes work with a matching evidence trail. If it does not, the work still happened. You can complete the quest by honest self-report for half XP when objective proof is unavailable or impractical.

That fallback matters most on imperfect nights. Maybe the function is finished but the push was too early. Maybe the push lands, but GitHub’s event feed has not caught up. Maybe you stopped to fix a test and missed 11:47.

Half XP is a clear record of progress, not a reason to rewrite the facts. You can create the next quest with a better scope, an earlier buffer, or a clearer definition of what a qualifying push will look like.

Build a buffer before the deadline matters

Apollo 13’s engineers could not change the shape of the canister. They worked from the constraints in front of them and made the connection honestly.

Use the same discipline for a coding quest. Create it before you begin the work. Decide what one finished change looks like. Leave enough time to test, commit, push, and allow for GitHub’s delay. Then choose the verification method that actually matches what you completed.

At 11:47 p.m., the useful question is simple: what can you prove from the work you have now?