One real problem at a time
WORKFLOW 001 · AI TOOLS AND A PRIMARY WORKFLOW
At first I only wanted to make AI run. The harder problem appeared later: keeping a real project moving after days away and across several sessions.
More tools do not help if I cannot return to the right work.
A useful primary workflow should help me start today and still know the project, context, and boundaries when I return. Models, plugins, and subscriptions can add capability, but repeated session hunting, background retelling, and permission checking are also costs.
IS THIS YOUR PROBLEM?
If your projects cross days and tools, this problem may already be costing you time.
WORKFLOW 001 · PATH AND RECEIPTS
Seven nodes form a returnable working path—not a table of contents.
Each node removes one unknown and leaves a receipt. A failed gate returns to the last safe node.
Should leaveTheme contract
Open node+State what this workflow will solve, what it must produce, and when the work should stop.
Open themeShould leaveDeliverable and entry choice
Open node+Start with the task and work setting—not a leaderboard or the longest feature list.
Open nodeShould leaveHuman handoff list
Open node+Blockers, permissions, failures, diffs, and final confirmation return to one visible place.
Open nodeShould leaveData-path boundary
Open node+Check processing, external calls, storage, updates, and deletion separately—not as one switch.
Open nodeShould leaveDelivery-check receipt
Open node+An AI completion note is not the deliverable. Check the file, test, page, or destination account.
Open nodeShould leaveFailure and recovery receipt
Open node+Stop, locate, and deduplicate before rerunning only what failed, with the failure receipt kept.
Open nodeMust leaveA testable workbench prototype
Open node+DevHub starts with project re-entry. Only real-use evidence earns a capability a place in BitShovel Desktop.
View experimentHOW I GOT HERE
I started by getting AI to run. The real drag appeared later: every return meant rebuilding the project context.
WSL2, servers, and coding agents each solved the next problem—and left a new switching or recovery cost. Records and recollection are labeled where they belong in the path below.
My early attention went to Windows, WSL2, a server, model configuration, and the first useful reply.
Recalled from experience · first date unverifiedA server, a messaging entry point, and scheduled tasks turned one local success into something that could be triggered again.
Recalled from experience · contemporary server and messaging records still need to be recoveredTwo retained repositories confirm that real project work continued through June and July 2026. Retained metadata also places Claude Code inside one of those project contexts.
Project and tool-context records · no project or commit is attributed to one toolModel flexibility and plugin ecosystems expanded capability, along with configuration, permission, failure, and maintenance cost.
Retained records place Claude Code, Codex, and ZCode in the workflow · other ordering remains recollectionEasier applications reduced setup burden without necessarily supporting deep, cross-project work over time.
Personal use · exact sequence still being checkedI now rely mainly on Codex and GPT capabilities because they better fit my current needs for continuity, automation, and visual collaboration.
Retained Codex records increase sharply from late July · not proof of productivity or a universal bestOnce tools, sessions, and plugins multiplied, recovering the right project context became a measurable problem in its own right.
DevHub solution experiment · user outcome unknownFIRST DECISION FRAMEWORK
Seven questions get closer to the real cost than “does it have more features?”
This is a decision checklist—not a ranking or objective score. Real project re-entry will revise it.
Can it finish a real project rather than a first demonstration?
Commits, running output, failure, and rollbackAfter a few days, can it return to the right project, session, and constraints?
Recovery time, omissions, mis-association, repeated contextDo primary, fallback, and specialist tools have clear boundaries?
Task allocation, switching count, duplicate capabilityHow much maintenance and cognitive load do models, plugins, and skills add?
Setup time, conflicts, breakage, and upgradesWhat do subscriptions, APIs, and rebuilding project context cost together?
Sanitized bills, usage, and time spent rebuilding contextWhich boundaries expand with servers, remote control, and plugins?
Permission list, failure modes, and reversal pathWhat new evidence would actually justify changing the primary tool?
Threshold, smallest useful comparison, and stop ruleFROM SUBJECT TO DECISION
Three questions first. No expanding tool catalog.
All three feed the same decision: how to keep projects moving without endlessly adding complexity.
Choose by duration, permission, network dependence, and maintenance cost.
Open the questionKeep extensions that change outcomes and give each one an exit condition.
Open the questionRecord the recovery baseline before adding another management layer.
Open the questionREAL, FREE ALTERNATIVES
A new workspace is not the starting point. Existing methods are often enough.
DevHub is justified only when simpler methods fail in an observable way. Otherwise, a new product merely repackages the complexity.
SOLUTION EXPERIMENT · DEVHUB
DevHub tests continuing from the project instead of restarting from the tool.
The current build puts projects, AI sessions, tool entry points, usage, and local operations in one Mac workspace. The question is project re-entry—not “manage every AI tool.”
The 12-second animation explains the relationship among three current interfaces. It does not simulate a successful use or stand in for user evidence.
EVIDENCE MAP
Experience, current reproduction, and user outcome are different kinds of evidence.
The material is enough to establish parts of this path and the current DevHub mechanism. It is not enough to prove a complete timeline, tool causality, or external user value.
Git history confirms two project timelines. Retained metadata places Claude Code in one project and Codex or ZCode in the wider workflow; none attributes a project to one tool.
Sanitized demos establish what the current build contains. They do not prove past availability or user benefit.
They remain labeled as recollection, without invented dates or universal causal claims.
Recovery time, accuracy, repeat use, and maintenance cost require new evidence.
NEXT VALIDATION
Measure what project recovery costs before DevHub enters the comparison.
Without a baseline, “faster” is advertising language. The next pass records ordinary returns, then compares under the same conditions.
Capture the previous tool, history search, repeated context, time to useful work, and whether the correct project context was found.
Compare ten recoveries while checking the branch, session, missing constraints, and cross-project mis-association.
README files, scripts, terminal history, session search, and system launchers remain real alternatives.
Watch for a second return. Completing onboarding once is not sustained value.
The current conclusion is a working hypothesis before the next real return.
New baselines, failures, mis-associations, and counterexamples enter the revision record. Tools can change, and the decision standard changes with the evidence.
Continue with the three questions