What Happens When You Push Before Creating a Craft Quest?

A Craft quest can earn verified full XP when a qualifying GitHub push happens after the quest is created. Self-reported completion remains available for half XP, while verified completion triggers a distinct full-XP celebration.

The commit needs a place in the story

In 2005, Linux kernel development needed a new source-control system after the project could no longer use BitKeeper under its previous arrangement. Linus Torvalds began building Git, and the question was immediate: could a new tool handle the scale and pace of one of the world’s largest open-source projects?

Git’s history, documented in the Pro Git book, is a useful reminder that a record matters when work has to be trusted by more than the person doing it. A change that exists only in your head is hard to inspect. A change pushed into a repository has a timestamped trail others can review.

That same difference shows up on an ordinary night with a coding task. You may have fixed a failing test, shipped a small component, or finally pushed the function you kept postponing. The work counts either way. The evidence available for that work changes how a progress system can recognize it.

Set the quest before you start coding

Create a Craft quest while the task is still in front of you. Give it a title that describes a finish line you can recognize later: “Push the login validation fix” works better than “Code tonight.”

LifeQuest then gives you a choice of completion paths that fit the quest. If you finish the task but cannot provide objective proof, you can honestly self-report and receive half XP. That keeps progress moving on nights when the work is real but hard to capture.

For a qualifying Craft quest, GitHub verification can offer a full-XP route. Connect your public GitHub username in your profile, create the quest, then push after it exists. LifeQuest checks for a qualifying public push made after the quest was created.

The order matters. A push made before the quest cannot prove you completed that specific quest after setting it. That boundary may feel fussy at first. It gives the XP a clearer meaning.

For the practical edge case, GitHub events can take up to five minutes to appear in LifeQuest’s cache. If you pushed seconds ago and the app cannot find it yet, wait a few minutes before deciding the verification failed. The full explanation is in The Push Made Before the Quest, and What It Can Cost Your Full XP.

Watch the completion reflect the evidence

When the push qualifies, LifeQuest awards the quest’s full XP. Your streak, skill tree, and Craft rank move forward with progress tied to a record created after you chose the task.

That completion also earns the verified celebration, including the optional celebration sound if you have sound enabled. A self-report completion gets its own honest result: half XP, no full-verification fanfare. The distinction is deliberate. It lets the app acknowledge effort without treating every type of completion as equally supported.

This is not a claim that a GitHub push proves every minute was productive or that it measures the quality of the code. A public event can show that a qualifying push occurred. It cannot tell the whole story of a project. LifeQuest keeps the claim at that useful, limited level.

Build a habit around proof you already create

The easiest evidence system is often one that meets you inside a habit you already have. If your normal coding rhythm ends with a push, make creating the quest the first move and pushing the last move.

Start small for the first few nights. Choose a task you can finish in one sitting. Create it as a Craft quest. Push after creating it. Then see how the verified result feels compared with a self-report.

That loop mirrors the pressure Git faced in 2005: a record has value because it can connect a claim to something checkable. Your coding quest does not need to become a performance review. It needs a clear finish line and an evidence path that genuinely fits the work.