The One-Line README Edit That Saves Your Streak, but Costs the Goal

A GitHub contribution square proves activity was recorded, not that meaningful work happened. LifeQuest ties full XP for an eligible Craft quest to a qualifying GitHub push made after that quest was created, giving the work a clear sequence and stronger evidence than a streak alone.

In 2016, investigators faced a similar gap between a healthy-looking metric and the behavior underneath it. Wells Fargo’s sales numbers appeared to show employees deepening customer relationships. The Consumer Financial Protection Bureau found something else: employees had opened more than two million deposit and credit card accounts that may not have been authorized by customers.

The target had been met. The meaning of the target had collapsed.

When the score becomes the job

Wells Fargo had built intense pressure around cross-selling, the number of products each customer used. As the CFPB documented in its 2016 enforcement action, employees boosted that measure by creating accounts customers might never have requested.

Then CEO John Stumpf defended the bank before Congress and later resigned. The episode became a lasting example of Goodhart’s law: once a measure becomes a target, people find ways to improve the measure without producing the result it was meant to represent.

Your GitHub contribution graph has much lower stakes, but the mechanism is familiar.

You want to become a better developer. You decide to code every day. Soon, the green square starts carrying more emotional weight than the work. At 11:58 p.m., a one-line README edit protects the streak.

GitHub accurately records the contribution. The square still cannot tell you whether you solved the bug, finished the feature, understood the algorithm, or kept the promise you made that morning.

That distinction matters because a visible streak can quietly change the job. “Build the authentication flow” becomes “make GitHub turn green.” The proxy wins.

What LifeQuest verifies before awarding full XP

LifeQuest starts with the work you intend to do. You create a real goal, turn it into a quest, and place that quest in the appropriate skill domain. GitHub verification appears only for Craft quests, where a code push can genuinely apply.

For full XP, LifeQuest checks for a qualifying push made after the quest was created. A contribution from last week cannot complete a quest you wrote today. A remembered streak cannot stand in for the current task. The sequence has to make sense: define the work, do the work, then verify it.

LifeQuest reads public GitHub events through the username you connect. It does not require GitHub OAuth, a token, or access to private repositories. Recent events may take up to five minutes to appear because the backend caches GitHub activity, so a push made seconds ago might need a short wait before verification succeeds.

This is temporal evidence, not a code review. LifeQuest does not claim that every qualifying push contains difficult or valuable code. It confirms that an applicable GitHub event happened after the quest began. You still carry responsibility for writing an honest quest with a meaningful finish line.

That boundary is deliberate. Evidence should make casual self-deception harder without pretending an automated check can understand every commit.

Use a quest that the push can actually prove

“Code today” leaves too much room for negotiation. A better quest names an observable result:

• Add validation to the registration form and push the change.
• Write tests for the session timeout behavior and push them.
• Fix the mobile navigation bug and push the implementation.
• Complete the first working version of a portfolio page and push it.

The push can support those claims because it follows a defined piece of work. It cannot prove that the implementation is elegant, secure, or finished to a professional standard. For that, inspect the diff, run the tests, or ask for review.

If no suitable objective proof exists, LifeQuest keeps self-report available for half XP. That matters. The system rewards stronger evidence without turning an imperfect verification method into a punishment mechanic.

This is the same principle behind why verified XP feels different from ordinary habit-app points: the evidence level changes the reward, and the product stays honest about what each method can establish.

Protect the goal from its own metric

Wells Fargo’s cross-sell number looked useful until employees learned how to satisfy it while violating its purpose. A green contribution square can drift the same way, from evidence of consistent practice into a daily box you protect with the smallest possible edit.

The fix is not to abandon streaks. Use them as feedback, then anchor each coding session to a result that exists outside the graph.

Before opening your editor, write the quest in one sentence. Make the completion condition concrete. Push the resulting work after the quest exists. Then let the green square remain what it always was: a record of activity, not a verdict on progress.