A GitHub push can earn full XP only when it happens after the coding quest was created. That order gives LifeQuest a clear sequence: you chose the work first, then produced evidence that you did it.
Picture Theo, an illustrative first-year computer science student in Porto, hunched over a kitchen table at 11:47 p.m. His tea has gone cold beside a laptop covered in two fading stickers. A portfolio review starts the next morning, and the mobile menu he promised himself he would finish still breaks on smaller screens.
He fixes the layout, runs the tests, and pushes the commit. Then he opens LifeQuest and creates a quest: “Fix the portfolio navigation.”
The push came first.
LifeQuest cannot treat it as evidence for a quest created afterward. Theo may have completed the work, but the timeline cannot show that this particular quest guided his effort. Full XP is now in doubt, with no second qualifying change left to make before bed.
A quest records intent before the work begins
A commit shows that code changed. On its own, it does not show why the change happened, which goal it served, or whether the developer decided to count it only after seeing a convenient green square on GitHub.
Creating the quest first records a small but meaningful commitment. You name the task while its outcome remains unfinished. A later qualifying push can then support a simple sequence:
Quest created. Work performed. Code pushed.
That sequence matters because evidence becomes easier to interpret when it follows a declared intention. Without it, LifeQuest would have to let any earlier push become retroactive proof. A typo fix from the afternoon could be attached to a study quest created at midnight. The activity would be real, but its relationship to the quest would be guesswork.
The rule also protects the meaning of full XP. LifeQuest always allows honest self-report for half XP when objective proof does not fit or cannot be supplied. Full XP carries a higher evidence standard, so the system needs more than a completion checkbox. The generic checkbox LifeQuest replaced explains why that distinction matters across the wider quest system.
The push confirms action, not the quality of the code
GitHub verification has a narrow job. For a suitable Craft quest, LifeQuest checks for a qualifying public push made after the quest was created. It does not grade the architecture, decide whether the code is elegant, or claim that one commit proves mastery.
That boundary keeps the evidence honest.
A push can support the claim, “I worked on this coding quest after choosing it.” It cannot support broader claims such as, “This feature is production-ready,” or, “I now understand every concept involved.” Those judgments require review, testing, and sometimes another person.
This is why verification methods differ by quest. A server-timed focus session can confirm elapsed focus time. A camera photo can undergo an AI plausibility review when visible evidence fits the task. GitHub can confirm a qualifying push for Craft work. Choosing the proof method that fits the quest preserves more meaning than applying one generic standard to every goal.
GitHub verification also has practical limits. LifeQuest links a username without OAuth, tokens, or private-repository access, and reads public events. Recent pushes may take up to five minutes to appear because GitHub events are cached. If the work lives only in a private repository, another completion method may fit better.
The order changes how you approach the session
Back at the kitchen table, Theo sees that his earlier push cannot qualify. The deadline still sits on tomorrow’s calendar, and inventing extra work for XP would turn accountability into theatre.
He takes half XP by honest self-report and leaves the completed fix alone.
Before closing the laptop, he creates tomorrow’s quest: “Add keyboard navigation to the portfolio menu.” The wording gives the next session a finish line. When he returns after the review, the quest already exists, and the work starts with a decision instead of a search through old activity.
That is the useful habit behind the rule. Write the quest while the work is still ahead of you. Make it specific enough that a later push clearly belongs to it. Then code, test, and push.
The order turns GitHub history from a collection of past activity into evidence of a commitment followed through.
Set up the evidence before opening the editor
For a coding quest you want to verify through GitHub, create it before changing and pushing the code. Keep the quest within the Craft domain, connect the GitHub username whose public activity will contain the push, and describe one concrete result you can finish.
“Work on portfolio” leaves too much room for interpretation.
“Add keyboard navigation to the portfolio menu” gives you a visible stopping point and a commit that can correspond to the declared task.
After pushing, allow for the public-event cache before checking verification. If the push cannot be used, choose honest self-report for half XP rather than manufacturing another commit or stretching unrelated work to fit.
The next evening, Theo’s quest is already waiting when he opens his editor. He knows what done means. One focused change later, the push lands after the promise that gave it context.
Comments
No comments yet.