For a Craft quest, a qualifying GitHub push can earn full XP because the repository records the work itself. Create the quest first, push a qualifying change afterward, then ask LifeQuest to verify it without uploading a screenshot or ticking a completion checkbox.
In 2005, Linus Torvalds faced a practical problem. Linux kernel development had relied on BitKeeper, but the arrangement that allowed the project to use it at no cost ended. A large, distributed engineering effort needed another way to track changes, preserve history, and let contributors work without losing confidence in where code came from.
Torvalds began building Git.
The outcome was hardly guaranteed. He was replacing infrastructure used by developers working across the world, and the replacement needed to handle the Linux kernel’s pace. The short history published in the official Pro Git book documents the break with BitKeeper and the goals that shaped Git: speed, simple design, distributed development, and support for large projects.
That history matters to one coding student finishing one last fix before bed. Git records an action with useful context: what changed, where it belongs, and when it entered the repository history. LifeQuest can use a qualifying push made after a Craft quest was created as evidence that work happened during that quest.
The push carries more weight than a completion tap
Suppose your final task tonight is fixing a failing validation check. You created the quest before opening the editor. After testing the change, you commit it and push it to the public GitHub account connected to LifeQuest.
When you choose GitHub verification, LifeQuest checks for a qualifying push made after the quest was created. If it finds one, the quest earns full Craft XP.
No screenshot needs to prove that a terminal window was open. No generic checkbox asks you to declare the work finished. The qualifying push provides evidence suited to the activity.
The order matters. A push from yesterday cannot prove that you completed a quest created tonight. If you want the reasoning behind that boundary, read why creating the quest first protects full XP.
LifeQuest reads public GitHub events using the username connected in your profile. It does not request a GitHub token or access private repositories. GitHub events can also be cached for five minutes, so a push made seconds ago may take a little time to appear.
Different work needs different evidence
A GitHub push fits coding work because the work naturally leaves a repository event. It would make little sense for an exercise quest, a study session, or a drawing practice session.
LifeQuest offers verification methods according to the quest. A server-timed focus session can measure elapsed work. An in-app camera photo can undergo an AI plausibility review. Honest self-report remains available when objective proof is impractical, awarding half XP.
GitHub verification appears only for quests in the Craft domain. If the skill catalog has not loaded or LifeQuest cannot identify the skill’s domain, the option stays hidden instead of guessing. The server enforces the same Craft requirement.
That choice follows the same practical pressure that shaped Git in 2005. The Linux kernel needed a system designed for the work developers were already doing. Your quest should use evidence that belongs to the work you actually completed.
For a broader comparison, see which LifeQuest proof method fits your quest.
Full XP marks evidence-weighted progress
The verified push awards full XP because it provides stronger evidence than self-report. That distinction gives the progression system meaning without turning it into punishment.
If the push cannot be found, you still have options. Confirm that your connected username is correct. Check that the quest belongs to Craft. Make sure the push happened after quest creation, then allow for GitHub’s event cache. If objective verification remains unavailable, complete the quest through honest self-report for half XP.
Rejected verification does not erase the work. It means the available evidence did not satisfy that method.
This also keeps the claim appropriately narrow. A qualifying push shows that repository activity occurred after the quest began. It does not judge whether the code is elegant, bug-free, or ready for production. Full XP recognizes verified action, not perfect output.
Make the final push part of finishing
Before your next coding session, create the Craft quest first. Keep the scope concrete enough that you can recognize completion: fix one validation error, finish one component, or add one tested endpoint.
Do the work. Commit it. Push it.
Then choose GitHub verification. The same kind of recorded history that helped distributed Linux contributors track real changes in 2005 can now close the loop on your own quest. One final push becomes more than a vague promise that you coded tonight. It becomes evidence attached to progress, and full Craft XP follows when LifeQuest finds the qualifying event.
Comments
No comments yet.