A finished focus block proves you gave the task a measured stretch of attention. A qualifying GitHub push proves a piece of coding work exists after the quest began; it does not prove the build passed, and a timer cannot prove the code ran.
At 8:42 p.m., Rowan was at the kitchen table in a shared flat in Bristol, one socked foot tucked under a chair, staring at a red build error beside a cooling mug of tea. Their focus session had ended. The server-recorded time was real, and they had stayed with the coding quest instead of checking messages every few minutes.
But the feature still failed when Rowan tried the build.
The bad ending was painfully ordinary: tomorrow’s demo would arrive with a branch that looked busy in the commit history and did nothing when someone pressed the button. Rowan had already changed the same state variable twice. The error message kept pointing somewhere else.
Time spent and code shipped answer different questions
A focus session answers, “Did I set aside and stay in this work block?” That matters, especially on projects where the hardest part is beginning and remaining present through the boring middle.
Coding evidence answers a narrower question: “Did I make a qualifying public GitHub push after creating this quest?” It gives LifeQuest a concrete event to verify for an eligible Craft quest. That is useful evidence of activity in the codebase.
Neither signal carries the whole story. A push can contain a first draft, a partial fix, a broken experiment, or a clean change that still needs review. A focus block can include reading docs, tracing logs, sketching a solution, or discovering that the task was larger than it looked.
Treating them as the same kind of progress creates a strange incentive. You may chase a timer finish when the right move is to stop, inspect the failure, and change your plan. Or you may chase a push when the responsible choice is to keep the unfinished code local until it is ready.
Rowan needed a smaller promise
Rowan had originally framed the quest as “Finish the settings feature.” By the end of the session, that promise had become too broad to evaluate honestly. The feature had three moving parts, and the build failure had turned one evening into a debugging problem.
So Rowan broke the work into a next quest with a smaller finish line: isolate the failing component, write down the error path, and push the fix once it worked.
That change did not erase the finished focus block. The time still counted as time spent on the work. It also kept Rowan from calling the feature complete simply because the session ended.
This is where evidence-weighted progress helps. You can choose the method that fits what genuinely happened. A server-timed focus session can recognize elapsed attention. A qualifying GitHub push can recognize a coding action. Honest self-report remains available at half XP when objective proof does not fit the quest.
The point is accuracy, not punishment. A broken build after a serious work block can still be progress, because it leaves you with information you did not have at 8:42 p.m.
Build failure can be the work, if the quest says so
The most useful coding quests name an observable next move instead of pretending every session ends in a finished feature.
“Trace the login redirect failure for 30 minutes” fits a focus session. “Push the test for the redirect bug” fits GitHub verification when the quest is in the Craft domain and the push qualifies. “Deploy the fix” needs its own evidence standard, because a commit alone does not establish a successful deployment.
That distinction gives you a cleaner record of your week. You can see that Tuesday held a real debugging session, Wednesday produced a pushed test, and Thursday delivered a working fix. Each step has a different shape.
It also protects against a familiar developer trap: treating visible activity as completed work. A green contribution square feels satisfying. So does a completed timer. Yet the work that changes the product may happen in the unglamorous stretch between them, where you reproduce the bug, remove the wrong assumption, and discover why the first fix could not work.
For a closer look at why LifeQuest measures focus from the server record, read Focus Session XP: Why LifeQuest Uses Server Measured Elapsed Time.
The next morning has a clearer starting point
Rowan did not force a late-night push to make the quest look complete. They wrote one line in the quest notes: “Build fails after settings save. Reproduce with empty profile.” Then they started fresh the next morning.
The red error was still there. The difference was that it had become the next target rather than proof of a wasted night.
Use a focus block when the promise is attention. Use GitHub verification when the promise is a qualifying push. When the build breaks, let the next quest describe the repair you can actually make.
Comments
No comments yet.