Evidence before excitement
Open the original release, documentation, paper, or advisory. Check dates, versions, availability, limits, and whether the claim is more than marketing.
A personal engineering system
Less noise.
Better work.
My decision.
I built the AI Research Command Center to shorten the distance from a meaningful technical development to a tested improvement in my own projects—while keeping every release decision mine.
COMMAND CENTER
Signal
→ action
→ action
Sources
Projects
Local draft
You decide
Evidence goes in. A reviewable choice comes out.
01 / THE REASON
Ideas move fast.
Ideas move fast.
Attention does not.
New models, APIs, security advisories, libraries, and standards arrive faster than I can evaluate them. A headline alone does not tell me whether anything changed in code I actually maintain. I wanted a repeatable way to find the signal, test the project fit, and make progress without handing over the final decision.
Relevance before code
Compare a finding with the current repository—not a stale copy or a broad topic match. Most interesting news should remain research, not become an automatic edit.
Progress with a stop point
Let the system prepare a small local draft and demonstrate it. Then I choose whether to approve, revise, or decline that exact change.
02 / THE SYSTEM MAP
One loop. Four different jobs.
The research conversation finds and remembers what changed. A separate draft chat only starts when there is a verified, bounded improvement. The two paths meet at a review packet, then stop for my decision.
Primary sourcesReleases · docs · papers · advisories
Active repositoriesCurrent code · versions · open work
Research memoryCoverage · findings · watch items
01 / OBSERVE
Verified digest
Critical · Important · Watch
02 / QUALIFY
Project-fit gate
Specific code + bounded local check
03 / PREPARE
Isolated draft
New chat · branch · tests · proof
04 / DECIDE
Your review
Approve · revise · decline
Research-only pathWATCH, no code match, or weak evidence stays in the report. A quiet run creates no empty draft; an older queued candidate may still advance.
Separate release pathApproval can permit guarded local integration. A push, PR, or deployment still needs a separate decision.
The diagram shows the decision boundaries. Every connection is explained in the steps below.
THE CONNECTING LINES / A FLOWCHART
Get the Mermaid source
Follow one finding through the whole loop.
The arrows show the actual handoffs and stop points. A finding can stay research-only, wait for the draft slot, or become a local proposal. No arrow goes straight from a report to production.
INPUTSSources + current repos + research memory
READ ONLYVerify the developmentThen save a sourced digest.
ELIGIBILITY GATEDirect code match and bounded local check?
NO / WATCHResearch-only recordNo draft chat.
YES ↓Stable queueOne unfinished draft.
NEW TASKFuegoWork Apps chatOne chat per selected draft.
CODE HOMEIsolated target-repo worktreeLocal branch, edit, and checks.
BACK TO THE SAME CHATReview packetExact diff, results, and demonstration.
HUMAN DECISIONApprove · request changes · decline
APPROVEGuarded local integration
REVISE ↶Same chat and branch
DECLINERetain branch
SEPARATE BOUNDARYPush, PR, or deploy only by explicit decision.
03 / EVERY STEP
From a source to a choice.
There is one recurring research task. It does not edit projects while it researches. Drafting is a separate, supervised phase after the report has been saved.
ObserveResearch conversation
- 01
A weekday trigger
At 8:00 AM New York time, Monday through Friday, the same task picks up where the last successful check ended. The local computer and desktop app need to be running for local repository access.
- 02
Find the actual change
Search AI, software, security, developer tools, APIs, agent systems, startups, and standards. Prefer original documentation and releases; use credible reporting for context. Verify event dates, versions, availability, and limitations.
- 03
Compare with real projects
Refresh the active repository inventory and group related repositories. Check relevant remote default-branch code, dependencies, instructions, commits, and open work before saying a project needs a change.
- 04
Save the digest and memory
Publish a dated CRITICAL / IMPORTANT / WATCH report with sources, project connections, and bounded next actions. It closes with attention priorities, one experiment, one project improvement, and an evidence-backed opportunity when justified. Keep a 48-hour search overlap, suppress repeats, retain failed-source gaps, and say when nothing significant qualifies.
QualifyEligibility + queue
- 05
Check the draft gate
Only a CRITICAL or IMPORTANT finding with a verified match to current code and a bounded local change with a measurable check can advance. WATCH, coursework, speculation, and already-addressed work remain research-only.
- 06
Give it one place in line
A separate ledger identifies the underlying finding, material version, and target repository. It prevents duplicate dispatch, allows only one unfinished draft across the system, and starts at most one draft per report. Later candidates wait their turn.
PrepareNew FuegoWork Apps chat
- 07
Open a fresh draft chat
Every selected candidate starts a new chat in my FuegoWork Apps Codex project. The chat is the home for the proposal, implementation, evidence, and approval request.
- 08
Work on an isolated branch
The target repository gets its own named local branch and worktree. When the target is another repository, its code stays in that separate worktree; the FuegoWork Apps chat's own worktree remains untouched.
- 09
Demonstrate the change
The draft runs appropriate local checks with synthetic data and makes a local commit. Its review packet includes the exact diff, results, limits, and before/after screenshots or fixture output.
DecideHuman control
- 10
Ask me in that same chat
I can approve the exact reviewed commit, request changes on the same branch, or decline and retain the branch. Approval permits only a guarded local integration if the remote base has not advanced and the target checkout is clean.
- 11
Keep publication separate
Pushing code, opening a pull request, deploying, spending money, running GitHub jobs, and submitting coursework are outside this automatic draft flow. A local approval is not a release.
04 / THE FORK
A finding can take different paths.
The gate is selective on purpose. Choose a situation to see what the system does next.
ROUTE 03 / DRAFT
A reviewable local draft begins.
The candidate takes the open ledger slot. A new FuegoWork Apps chat makes the change in an isolated target worktree and returns a packet for your decision.
RESULTNo push or deployment. You decide the next move.
05 / THE TWO WORKSPACES
One review conversation.
One review conversation.
Code in the right repository.
FuegoWork Apps is the place I review every draft. The project being changed owns the branch and files. That distinction matters when a finding applies to a different repository.
REVIEW HOME
New FuegoWork Apps chat
Scope, context, implementation story, evidence, and the final approval question all live together.
CODE HOME
Target repository worktree
A named local branch holds the edit. Tests run here. Other checkouts and active work stay in place.
Exact patchWhat changed
Before / afterWhat it does
Checks + limitsWhat passed and what did not
Local commitThe precise revision under review
06 / A REAL DRAFT SHAPE
The demonstration is part of the work.
One pilot examined an AI CLI stream boundary with synthetic events. The earlier behavior accepted extra events after a terminal result. The local draft made those sequences fail as protocol errors, while a valid single result still succeeded.
The packet records the actual fixture output and test results, including limits from the broader suite. Synthetic input demonstrates the adapter rule; it does not claim the real CLI emitted those sequences.
The point of a draft is to make a claim inspectable before it becomes part of a project.
synthetic stream / local fixture
BEFORE
result→late event→acceptedAFTER
result→late event→protocol error Single result remains valid Local proof only
07 / THE HUMAN BOUNDARY
The system prepares.
The system prepares.
I decide.
The completed draft asks in its own FuegoWork Apps chat. The decision applies to the exact reviewed work, not an open-ended permission to change or publish later.
Use this exact draft
Recheck the base and target checkout. If clean and unchanged, integrate the reviewed commit into the local default branch. If conditions changed, return it for review.
Keep working here
The same chat and branch receive the revision. A changed commit gets a new evidence packet and a fresh decision.
Leave it local
The branch is retained for inspection until I choose what to do with it. Nothing is silently merged or removed.
Publication is another boundary.
Approval here is not a push, pull request, deployment, paid job, or assignment submission. Those are separate, explicit choices.
THE IDEA
Back to top
A better way to keep up is a better way to decide.
This is a working, supervised research-to-draft workflow for my own development projects. It lets me keep learning without turning every announcement into a task—or every draft into a release.