A GitHub push can earn full XP in LifeQuest only when it happens after the coding quest was created. The quest timestamp sets the starting line, so earlier work cannot be claimed as proof of a new commitment.
In 1980, Rosie Ruiz crossed the Boston Marathon finish line ahead of the other women. Her recorded finish looked decisive. What happened before that moment was far less clear.
Race officials and reporters could not establish that Ruiz had run the full course. Witnesses had not seen her at key points, and her appearance at the finish raised questions among experienced observers. After an investigation, officials disqualified Ruiz and recognized Jacqueline Gareau as the women’s winner. The Boston Globe documented the controversy as it unfolded.
The finish line showed where Ruiz appeared at the end. It could not establish where she started or what she completed along the way.
A result needs a starting line
Imagine creating a LifeQuest coding quest at 7:15 p.m.:
“Fix the broken mobile navigation and push the change to GitHub.”
You make the fix, push it at 8:02 p.m., then ask LifeQuest to verify the quest. The order is clear. The commitment came first, the qualifying work followed, and the public GitHub event gives the system something concrete to check.
Now reverse that order. You pushed the same change at lunchtime, then created a matching quest that evening. The push may represent valuable work, but it cannot prove that you completed the new quest. It happened before the quest existed.
That distinction protects the meaning of full XP. A visible result alone does not establish which commitment produced it. LifeQuest therefore checks whether a qualifying push was made after quest creation.
The rule is intentionally narrow. GitHub verification appears for quests in the Craft domain, and it reads public GitHub events using a linked username. LifeQuest does not request a GitHub token or access private repositories. Since GitHub events may be cached for five minutes, a push made moments ago may take a little time to appear.
Why the timestamp matters
A timestamp creates a before-and-after boundary.
Before the quest: existing work, prior commits, and unrelated activity.
After the quest: work that can qualify for this specific commitment.
This boundary reduces ambiguity without pretending to know everything about the code. A push does not measure its elegance, difficulty, or business value. It confirms a smaller and more defensible claim: after creating this Craft quest, the player made a qualifying public push.
That is enough to support full XP for the verification method. It also avoids turning GitHub activity into a vague productivity score. You choose the quest first. LifeQuest then checks for the event that can unlock it.
This follows the broader approach described in Which LifeQuest Proof Method Fits the Quest You Actually Completed?. Different quests leave different kinds of evidence. A coding quest may leave a public push. A study quest may fit a server-timed focus session. When objective proof is impractical, honest self-report remains available for half XP.
Commitment changes the meaning of evidence
The order of events affects what the evidence can support.
A photo taken last month may show that a bookshelf exists. It does not prove you assembled it for a quest created this morning. A focus session completed before a study quest was written cannot verify that later commitment. A GitHub push from yesterday cannot unlock a quest created today.
This is more than a technical filter. Creating the quest before doing the work forces a useful decision: what, exactly, are you committing to complete?
“Work on my app” leaves room for reinterpretation.
“Fix the mobile navigation and push the change” gives the effort a finish line.
The quest does not need to describe every implementation detail. It needs enough specificity that you can recognize completion without rewriting the promise after seeing what you happened to accomplish.
That makes LifeQuest’s progression easier to trust. XP reflects declared work followed by suitable evidence, while locked titles, badges, skill trees, streaks, and E-to-S domain ranks retain a connection to actions taken after commitment.
Put the marker down before you move
Before your next coding session, create one Craft quest with an observable finish. Then do the work and make the qualifying push. If GitHub verification does not see it immediately, allow for the event cache before trying again.
If your work cannot appear in public GitHub events, choose another verification method that genuinely fits. A server-timed focus session may work for the effort itself, while self-report always remains available at half XP. The system should reflect the evidence you can honestly provide, rather than pressure you to expose private code.
The lesson from Boston in 1980 is simple: crossing a finish line carries weight because a defined course and starting point came before it. In LifeQuest, the quest timestamp supplies that starting point. Create the commitment, complete the work, and let the later push unlock the claim.
Comments
No comments yet.