The Productivity Brain

The original scope

Four CLI commands. That was it.

• digest — morning summary from local memory
• focus — one recommended task for today
• review — unfinished task list
• weekly-summary — what happened, what is still open

The demo test: give me yesterday’s work, unfinished tasks, today’s suggested focus, and one warning. If it can do that from local memory, Week 3 counts as done.

All of that got built. The problem was getting the focus suggestion to actually be useful.

The first scoring version was wrong

The first version treated every task as equal. It picked a focus the same way a random number generator would.

That is not a focus suggestion. That is a list with extra steps.

So the scoring engine got rebuilt. It now ranks tasks by signals that actually matter:

• due language — “today” beats “tomorrow” beats “this week”
• priority language — “urgent,” “deadline,” “ship,” “finish” all add weight
• stale task age — things sitting too long get surfaced
• blocked language — blocked tasks get flagged, not ranked
• active project match — tasks tied to active projects score higher
• admin detection — routine low-priority tasks get pushed down

There was also a scoring bug: “today” was not correctly outscoring “tomorrow.” Small mistake. But it would have broken trust in the output every single morning.

What else got added

Two more commands got built alongside the original four.

• plan — builds a daily plan from the scored task list
• status — shows what the assistant knows and how fresh it is

The voice loop now responds to two natural phrases:

• “Where do I stand?”
• “Plan my day.”

The weekly summary was also improved. It now includes open loops and a next-focus suggestion, not just a flat list of what happened.

One more change: the assistant now explains why it chose a task. A focus recommendation without a reason is just a guess. If it cannot justify the pick, the pick is not good enough.

The memory freshness problem

During testing, the progress and yesterday commands were pulling stale data.

The fix was simple: rebuild both from the conversation log before answering, instead of pulling from a cached snapshot.

It is a small change. In practice, it made a noticeable difference to the quality of the responses.

The browser panel

A local browser panel got added for typed testing. This was not in the original scope.

The reason: testing CLI commands one at a time is slow. The browser panel lets me type questions and see the reasoning in one place.

It supports typed chat, spoken replies, a speak-last-reply button, and auto-speak for hands-free testing. The Ollama connection uses gemma3:4b with fallback handling for internal errors.

This is a testing tool, not a user interface. That distinction mattered when the mic experiments started failing.

What got cut

Three things were attempted and removed:

• browser speech-recognition path
• Python mic fallback inside the browser server
• PortAudio browser mic capture

Each one caused instability. The browser mic path created more problems than it solved.

The stable voice path is back to:

.\talk-assistant.bat

Browser for typing. Bat file for voice. That separation is clear now.

Rolling these back was the right call. A stable system that uses a bat file is more useful than a broken system that supports browser mic.

Where it ended up

DeskSpirit now has six CLI commands, two voice phrases, a scored task list, a local browser test panel, and a fixed memory layer. Everything still runs locally on one machine. No external services. No accounts.

The useful lesson from Week 3 was not the feature list. It was this:

The first version of anything that “decides” something will be wrong. Build it anyway. Then figure out why it is wrong. Then fix the logic.

That is the only way to find out what the scoring should actually look like.