A local commit cannot earn full XP for a LifeQuest coding quest. Create the quest first, then make a qualifying GitHub push after it exists so LifeQuest can verify the public event and award full XP.
At 11:43 p.m., Eli was still in a campus library, one cold coffee beside his laptop and his backpack wedged under the chair. He had fixed the failing test, committed the change, and opened LifeQuest expecting the coding quest to be done. The full-XP option was waiting for a push that did not exist.
His deadline was midnight. If he settled for half XP, he would still record the work honestly, but the proof tied to the quest would be gone. If he rushed a push from the wrong branch or discovered his GitHub account was not linked, the project update he meant to show tomorrow could stay stranded on his laptop.
A commit records work on your machine
A commit is a checkpoint in your local Git repository. It can hold real work: changed files, a useful message, and the exact version you want to keep. That matters for coding, especially when you are testing an idea or cleaning up a feature before sharing it.
But a local commit is private to the machine until you push it to a remote repository. LifeQuest cannot verify a commit that only exists on your laptop. The GitHub verification route looks for a qualifying push made after the coding quest was created.
That order protects the meaning of the quest. A push from last month may prove that you coded last month. It cannot prove you completed today’s quest. The point is not to turn every keystroke into a courtroom exhibit. The point is to give full XP a piece of evidence connected to the work you set out to do.
Eli checked the quest timestamp, then opened his terminal again. His commit was ready. His repository remote was correct. One command remained: `git push`.
The push creates evidence LifeQuest can check
When a push reaches GitHub, it creates an event outside your device. For an eligible Craft-domain quest, LifeQuest can use that event as a verification method. You connect your GitHub username in your profile, create the coding quest, complete the work, and push afterward.
A few details prevent unnecessary frustration:
- GitHub verification applies to Craft quests. A quest in another skill domain will not offer it.
- Your GitHub account needs to be linked before LifeQuest can associate a qualifying event with you.
- GitHub events may take up to five minutes to appear because the backend caches them. A push from seconds ago can be real and still not be visible yet.
- A push must happen after the quest was created. Earlier activity cannot be retrofitted as evidence for a newer quest.
At 11:51, Eli pushed. The terminal returned without drama, which somehow made the wait worse. He refreshed LifeQuest, saw no change, and stared at the clock. The quest still offered self-report at half XP, an honest fallback if the event never appeared.
That fallback matters. Work does not become worthless because a service is delayed, a repository is private, or the internet drops at the wrong moment. Self-report lets you close the quest and keep moving, while full XP remains tied to evidence that the app can actually review.
Plan the quest before the coding session
The simplest habit is to create the LifeQuest quest before you start the task. Give it a clear scope, such as “Push the completed search-filter tests” or “Publish the first draft of the portfolio component.” Then do the work and make a push when the scope is genuinely complete.
This also makes your own progress easier to read later. “Code for an hour” leaves room for fuzzy memory. A quest tied to a completed task and a push gives you a cleaner record of what you meant to ship.
Skillorum’s practice model points toward the useful part of this structure: coding is a named real-life skill, built through sessions and quests rather than a vague promise to improve someday. LifeQuest adds a choice about how a specific quest earns XP. GitHub verification suits a public coding action. A focus session suits time spent concentrating. A photo may suit physical work. Self-report remains available when objective proof does not fit.
The method should follow the quest, not force the quest to fit the method.
Keep the full-XP path honest and practical
At 11:57, Eli refreshed again. This time the GitHub option recognized the push. He completed the quest with full XP, closed his laptop, and carried the same code to class the next morning instead of trying to reconstruct what he had done from a local commit and a tired memory.
For your next coding quest, create it before opening the editor. Link GitHub if you plan to use public push verification. Push after the work is complete, then allow a few minutes for the event to appear before assuming something failed.
If the verification route does not apply, use self-report and take the half XP. Honest progress still counts. For the other timing rule that can affect a GitHub quest, see GitHub Quest Verification: Why Noor’s Earlier Push Could Not Earn Full XP.
Comments
No comments yet.