A coding tutorial can teach a lesson, but LifeQuest awards full XP only when a qualifying GitHub push shows coding activity after the quest was created. The push does not prove mastery; it provides time-linked evidence that the student applied the lesson.
In 1986, physicist Richard Feynman sat before the Rogers Commission in Washington, D.C., investigating the Space Shuttle Challenger disaster. Engineers had discussed how cold affected the shuttle’s rubber O-rings, but explanation alone had failed to settle the issue. During a televised hearing, Feynman compressed a sample of O-ring material with a clamp, placed it in ice water, then showed that it did not quickly return to its original shape.
That small demonstration made an abstract concern visible. The uncertainty did not disappear because Feynman offered a better description. It changed because he produced evidence other people could inspect.
The gap between following and doing
A student finishes a tutorial on API requests. The instructor’s example works. The student understands each step while watching it happen.
Then the video ends.
That moment is easy to misread. Recognition feels like recall, and copied code feels close to independent work. Yet the real test begins when the student opens a project, decides where the request belongs, handles an error, and makes the code run without the instructor moving first.
LifeQuest draws a line between those moments. The student can create a Craft quest such as “Add an API request to my weather app,” complete the work, and verify it with a qualifying GitHub push made after the quest was created. If LifeQuest finds that push in GitHub’s public events, the quest can receive full XP.
The timing matters. A push from last week cannot verify work claimed today. Creating the quest first establishes a starting point; the later push supplies evidence of activity after that point.
GitHub verification can take a few minutes to see a recent public event because the backend caches events for five minutes. It also uses a linked GitHub username, without OAuth tokens or access to private repositories.
What the push proves, and what it does not
A qualifying push proves something narrow and useful: coding activity happened after the quest began, under the linked public GitHub identity.
It does not prove that every line was written without help. It cannot judge code quality, confirm deep understanding, or establish that the pushed change perfectly matches the tutorial topic. A commit can be tiny. A working feature can still contain mistakes.
LifeQuest treats evidence according to what it can honestly support. GitHub verification earns full XP because it offers stronger evidence than a completion checkbox, while avoiding claims that a push can reveal skill mastery.
That distinction protects the meaning of progress. XP reflects the strength of the completion evidence available for that quest. Skill still develops through repetition, debugging, review, and building work that survives outside the tutorial.
The same principle appears in The AI Explained It, But Can You Do It?: receiving an explanation and producing something yourself are different events. One can support the other, but they should not be recorded as though they are identical.
Half XP keeps honest progress available
Sometimes the student learns something real without producing a qualifying public push. Perhaps the exercise happened in a browser sandbox. Perhaps the repository is private. Perhaps the lesson focused on reading unfamiliar code rather than changing it.
LifeQuest still allows honest self-report for half XP. That fallback matters because useful work does not always leave objective evidence, and a verification system should not pressure someone to manufacture proof that does not fit the task.
The choice is practical:
- Create the quest before beginning if a public GitHub push genuinely fits the work.
- Push a qualifying change afterward and use GitHub verification for full XP.
- Use self-report for half XP when the work happened but suitable proof is unavailable.
Rejected proof and failed provider calls do not consume paid usage, and GitHub verification remains included in the free plan. The complete real-life RPG loop is free, including unlimited goals, quests, self-report, focus and GitHub verification, XP, streaks, skill trees, ranks, learning resources, and notifications.
Turn the next lesson into evidence
Feynman’s ice-water demonstration did not explain every cause of the Challenger disaster. It made one disputed mechanism observable. That modest scope gave the evidence its force.
A GitHub push should be read the same way. It does not certify a developer. It marks a concrete action after a declared starting point.
Before opening the next coding tutorial, create a Craft quest tied to a small deliverable: add input validation, write one test, repair one failing request, or build one component. Finish the lesson, close the instructor’s finished example, and make the change in your own project.
Then push it.
The lesson gave you a path. The repository now contains evidence that you walked part of it.
Comments
No comments yet.