Dev’s old GitHub activity cannot verify the quest. Full XP needs a new public push.

A GitHub contribution square earns full XP only when it can verify a qualifying public push made after you created a coding quest. Earlier commits, unrelated pushes, and a busy green calendar do not prove that specific quest happened.

At 11:48 p.m., Dev is at a library table in Lisbon with a cold espresso beside their laptop and a coding quest due before they sleep: “Fix the validation message in my portfolio form.” Their GitHub graph already looks busy from a project they touched that afternoon. They expect the quest to clear easily.

Then the verification result does not arrive.

The green squares cannot show which change belongs to this quest. If Dev counts old activity as proof, the rank and streak could advance for work that was already finished before the quest existed. The uncertainty matters because the quest may need half XP through an honest self-report instead.

Dev opens the project again, fixes the message, and makes a qualifying push after creating the quest. That push gives LifeQuest a time-bound connection between the work and the commitment. When GitHub verification finds it, Dev gets full XP. The calendar may look almost identical the next morning. The progress record does not.

A contribution graph records activity, not intent

GitHub’s contribution graph is useful evidence that work happened on a given day. It does not explain the purpose of each contribution. A cluster of commits could come from a class assignment, a maintenance task, a weekend experiment, or work completed before you chose your next quest.

LifeQuest treats a coding quest as a promise with a starting point. The relevant proof needs to happen after that point. That keeps the XP tied to the action you set out to take, instead of turning accumulated GitHub activity into a general-purpose completion token.

This is a small distinction, but it changes the feeling of the system. Your quest list can stay honest when you create a task late in the day, after you have already pushed code. You still did real work. That earlier work simply belongs to a different moment.

The qualifying push connects the work to the quest

GitHub verification applies to quests in the Craft domain. First, connect the GitHub username you actually use for public activity. Then create the coding quest before making the push you want to use as evidence.

The push does not need a dramatic release or a perfect commit history. It needs to qualify under the verification rules and appear after quest creation. LifeQuest checks public GitHub events, so private-repository activity cannot serve as this proof path. GitHub events can also take up to five minutes to appear in the backend’s cached view. A push made seconds ago may be real and still unavailable for verification for a short time.

That delay can be frustrating at midnight, especially when Dev has already closed the editor and packed their charger. But waiting for evidence to appear is different from treating an old square as new proof. The record stays connected to what actually happened.

For a closer look at the case where a coding quest has no usable public push, read What Happens When Your Coding Quest Has No Public GitHub Push?.

Half XP keeps an honest fallback open

A public push will not fit every coding task. You may be reading documentation, sketching an architecture, debugging a local issue, working in a private repository, or practicing without committing anything useful. Those tasks still count as effort.

LifeQuest lets you complete a suitable quest by honest self-report for half XP when objective proof is impractical. The fallback prevents the system from forcing every useful task into a public GitHub-shaped box. Full XP has a higher evidence bar; half XP lets you record real progress without pretending you met it.

Dev uses that distinction later in the week. They create a quest to study an unfamiliar testing pattern, spend the evening running local experiments, and make no public push. They choose self-report, receive half XP, and keep the record accurate. No awkward throwaway commit. No false claim that GitHub proved the study session.

Set up coding quests before you open the editor

Create the quest while the work is still ahead of you. Give it a concrete outcome you can recognize, such as “Push the accessibility fix for the settings form” or “Publish the parser test update.” Then make the qualifying public push after the quest exists.

That sequence gives the proof method its meaning. Your GitHub graph remains a useful history of activity, while the quest becomes a clear record of a commitment you made and completed.

Dev’s next coding quest is waiting in the list before the laptop opens. This time, the push has somewhere specific to go.