The planning session started with six words. Good software hides the machinery.
Not a feature list. Not a requirements document. Not “what should the app have.” A diagnosis. The system I had been building for weeks: pipelines, nudges, monitors, income tracking, life task files: was powerful and working. The interface to it was the engine room. Not a cockpit, not a window. The engine room itself, every valve exposed, requiring you to know where everything lives and what each piece does in order to touch any of it.
The power was real. The interface was the problem.
The first question was not what features the console should have. It was what the relationship between the person and the system should feel like. Answer that first and the architecture falls out of it on its own. Skip it and you build something that works but nobody wants to sit with.
The answer arrived as an image, not a spec. A ship console. Not a dashboard, not an app. Something you exist alongside, the way you exist alongside weather. Something that runs while you are doing other things, that surfaces what matters when you look at it and asks nothing of you when you do not. Alive. Present. Yours.
Everything else was excavation.
The spec document I produced in that session has 18 resolved planning gaps. They are not 18 items worked through in order. They are a record of what surfaced when the whole system was being held in mind at once and things that needed pinning down made themselves visible before they could harden into problems.
Look at what appeared back to back. VOID default destination (user behavior, top level). Art creation method (production logistics, meta level). Console dimensions (implementation detail, bottom level). OS target (platform constraint, infrastructure level). DEBRIEF/DRIFT output display (interaction design, mid level). Five different levels of the same project, surfacing in the same breath, like bubbles from the same disturbance reaching the surface at different speeds.
A linear thinker would have sorted these by layer. Define the platform, then the architecture, then the interaction model, then the visuals, then the edge cases. These showed up together because to the mind holding all of it at once they are different questions circling the same center. What stays inside, what goes outside, where the boundary sits between user and system.
This is radial, not sequential. You stand in the center and everything is equidistant. You reach for whatever is clearest and the contact tells you something about the things adjacent to it, the way pressing one key on a piano teaches you something about the chord it belongs to. The order looks random from outside. It is not. It is the order the system offered you, and the only honest response is to take it.
Some of the decisions that fell out of this process are not really about software at all.
The no-sign-up rule. Every ambient data source: weather, air quality, news feeds, geocoding, time: pulled from open APIs and direct fetches that require no account, no key, no renewal. Philosophy wearing technical clothing. Every external service is a failure point, a maintenance burden, and a thing someone can take away from you. The console is supposed to feel like yours. Yours does not have a renewal date.
The token boundary. The AI costs nothing unless you press a button. The ambient display runs for free, all day. If it costs tokens to run all day it becomes a guilt object, something you are aware of in the wrong way, a meter ticking in the peripheral vision of every quiet hour. Free the idle display and something shifts. It can just be there. You do not owe it anything for existing.
The VOID button. Opens a curated landing spot: art, YouTube, something you love. A door out of the machinery. Not an afterthought, not something you steal from the system when it is not looking. Designed in. Rest is part of the architecture, not a failure of discipline. Every other productivity tool treats the pause as the enemy of the work. This one treats it as a structural member. Pull it out and the building comes down.
The task check-off with no confirm step. Tap it and it is done. One action. The completion writes itself back into the system simultaneously. A confirm dialog would make the action feel safer and would be wrong. Confirm dialogs exist to prevent accidents with irreversible consequences. Checking off a task is not irreversible. The confirm step would add friction to an action you want to feel satisfying and instant, a small bureaucracy inserted between you and the relief of done. Completion should feel clean. Not cautious.
The spec names five commands. Each one was named once and stayed.
INITIATE / SHUTDOWN is a dual-state button. Shows INITIATE when processes are down, SHUTDOWN when they are running. The button label is the status indicator. One element doing two jobs, the way a closed door is simultaneously a wall. The design instinct. If you need two elements to convey one state, you have one too many.
DEBRIEF fires the daily briefing: what came in, what matters, what needs attention. The compiled state of the whole system pulled into one readable surface. The morning paper for a life that does not have a morning paper.
DRIFT launches the burst picker. No agenda. Wander into whatever feels right. The name was chosen because it is a flexible vessel: it can change what it does later without the name feeling wrong. Good names outlast their first use.
VOID is the door out. Zero tokens. Zero Claude. Opens in the browser and the console does not care where you went or how long you stayed.
CONFIG slides in the settings for everything.
Five commands. That is the entire interaction surface. Five buttons and an always-on ambient display. Everything else is invisible and running underneath, the way a root system is. That compression is the design.
The write-back layer is where the console stops being a display and starts being part of the circulatory system.
Every action you take on the console writes that change back into shared state files. The next time any process runs, it reads current reality first. The nudge does not repeat tasks you already handled. The burst picker knows what mode you were in. The briefing knows when you last consumed it.
The loop closes. The system learns because you touched it.
One question followed all the way down. What would it mean for the console to actually know about me? Not know about my preferences. Know about my present tense. What I finished, what I chose, what I consumed, when. A dashboard shows you what happened. A control panel changes what happens next. The write-back layer is the membrane between those two things.
Three wireframes in 53 minutes. They are not the same wireframe refined. They are three different answers to the same layout question.
The first is terminal green. Everything in a grid, clean, monospace, functional. What you draw when you are thinking about what the thing needs to do.
The second adds asymmetry and dark chrome. The layout is structurally the same but the aesthetic is pulling toward something it cannot name yet. The Giger direction being felt for rather than decided, the way you feel for a light switch in a dark room.
The third drops to negative space. Less is defined, not more. The zones are established but the art between them is left blank: deliberately: because the wireframe’s job at this stage is to define where the Giger art cannot be. The zones are the constraint. Everything else is canvas.
The progression is not refinement. It is clarification. What does it need. What does it feel like. What do I actually need to tell the art to make this work. Three questions. Three wireframes. The last one is not more detailed than the first. It is more exactly positioned. It knows what it is for.
None of the spec documents name what the console is actually for. The planning session already knew and did not need to write it down.
It is for an ADHD brain that has built real infrastructure and keeps losing track of it. Not because the infrastructure is bad. Because there is no front door. Every day starts with the same archeological dig. What is running, what needs checking, what was I doing, what should I be doing, what did I finish that I have already forgotten I finished.
Every decision in the spec: the pull-not-push architecture, the idle-costs-nothing model, the single-action completion, the alert categorization, the DRIFT mode, the VOID button: every one is an answer to a specific friction point in that specific brain. The friction points were never named in the spec. They did not have to be. The person writing the spec was the same person who felt them. You do not name the thing you are standing inside.
The console does not look like other productivity tools because it was not designed for other productivity tool users. It was designed for one mind, by that mind, with the full weight of knowing exactly how that mind fails and exactly what it needs in order not to. That specificity is the whole product. The general version, if it ever ships, will be a translation. This one is the original language.
I am a systems thinker and UI/UX builder. Decades of dabbling in code. Enough to understand architecture, read what comes back, and know when something is wrong even when I do not speak the language it is written in. I directed an AI to write the Python. Every structural, aesthetic, and philosophical decision was mine. The planning session transcript was lost when an update wiped the Cowork roaming directory. What survived was the spec, because I had already built a system that does not trust session data. This is what the spec says when you read it as a record of how a mind works rather than a record of what it decided.
Reconstructed from: AH_Idea_SciFi_Dashboard.md (full spec, resolved planning gaps, architecture decisions), wireframe sequence v1–v3, and the structural logic of the decisions themselves.