A Craft quest can earn verified full XP when you create it before a qualifying GitHub push, connect your GitHub username, and LifeQuest finds the public event. Until that check succeeds, the quest stays pending, and self-report remains available for half XP.
At 10:43 p.m. in a campus library, Jonah is staring at a failing test and a paper cup gone cold beside his laptop. His coding quest says, “Finish the API validation for my class project.” He created it before opening GitHub because he wants the work to count as full XP, not as another promise he checked off after the fact.
The assignment is due the next morning. He has already fixed the same error twice, and the bad ending is clear: he could run out of time, submit code he does not trust, and have no qualifying push after the quest was created to verify the work. The quest would still be completable by honest self-report, but it would earn half XP.
He keeps going. One small change, then another test run. When the green checks finally appear, Jonah commits the fix and pushes it to GitHub. Back in LifeQuest, the Craft quest still reads pending.
For a few minutes, that is all he sees.
Create the quest before the work begins
The order matters because GitHub verification looks for a qualifying public push made after the coding quest was created. A push from earlier in the day cannot become evidence retroactively just because you add a quest afterward.
That rule gives the quest a useful shape. Before Jonah writes the first line, he has to decide what “done” means. “Work on backend” is foggy. “Add validation and push the tested change” gives him a finish line he can recognize at midnight.
LifeQuest keeps GitHub verification specific to Craft-domain quests. That prevents a coding signal from being treated as proof for a workout, a social goal, or a reading session. Different work leaves different traces. The proof method should fit the task.
This is also why connecting GitHub is not a magic shortcut. LifeQuest checks qualifying public activity. It does not receive private-repository access, and it cannot verify work that never appears in a public GitHub event.
Pending is an honest part of the loop
Jonah refreshes the quest, then catches himself doing it again. The push was real, but a recent GitHub event may take time to appear because the backend caches events for five minutes. The app cannot promise a result before the signal is available.
That small wait matters. A pending label means the evidence has not been confirmed yet. It does not mean the work failed, and it does not quietly award full XP because someone pressed a completion button.
If the push does not qualify, Jonah still has a clear path forward. He can use self-report and earn half XP for honestly completing the quest. The lower reward reflects the difference between a confirmed signal and a claim that cannot be practically verified, without turning the app into a punishment machine.
The same principle appears across LifeQuest: choose the verification method that genuinely fits. A focus session can use server-recorded elapsed time. A photo can be reviewed for plausibility. A coding quest can use a qualifying GitHub push. Each method answers a different question.
For a deeper look at that distinction, read What Did I Actually Get Better at With a GitHub Streak?.
The verified moment has more weight
A few minutes later, Jonah opens the quest again between packing his charger and saving a backup copy of the project. The status has changed. His Craft quest is verified, and the full XP lands.
The change feels different because the rank progress now points back to something concrete: a quest he named before starting, code he completed, and a public push that followed it. The XP is a record of effort with evidence behind it.
That does not mean every coding session needs GitHub verification. Plenty of work happens in private repositories, local experiments, tutorials, and half-finished branches. In those cases, self-report still lets you acknowledge progress. The point is to match the reward to the evidence you can honestly provide.
For students especially, that can make the difference between collecting streaks and building a useful record of what they actually shipped. A Craft rank becomes easier to explain when it reflects finished changes, not only intentions.
Turn the next commit into a clear finish line
The practical move is simple: create the Craft quest first, then define the push you want to make. Keep it small enough to finish in one sitting. “Push the completed login validation” is easier to verify and easier to begin than “be productive on my app.”
Before Jonah leaves the library, he looks at the verified quest once more. The test suite is green, the change is pushed, and the next item on his list is already waiting for tomorrow.
Comments
No comments yet.