unclesystems
How every build runs, end to end
The system behind every automation: what loads first, where memory is checked, who approves, how it is tested and proven, and what keeps it safe. Hover or tab to any card for the detail.
11 STAGES · 49 STEPS
flowlive signalloop backa person approvesruns by itself
AStartevery run begins the same way
A requesttyped or spoken
Trigger. A run starts when a request comes in. The rest of the map is what happens before anything is touched.Scheduled runset times, no one typing
Trigger. Some runs start on a schedule instead, like the weekly self-review. They go through the same steps.Load the rulesone config file
Setup. One config file loads first: who the assistant is, where its memory lives, and the rules that never lapse.Safety scansecrets, backups, health
Runs by itself. A start-up check looks for exposed secrets, missing backups, injected instructions and memory problems, and reports them first.Clock + done checkon every message
Runs by itself. Every message gets the real local time, and any task gets a reminder to state what "done" means before starting.BMemorychecked before the web
Vault indexthe map of memory
Memory. A notes vault holds everything learned so far. Its index says where each topic lives.Session handoffwho holds the pen
Memory. One file records the current task, the next step and who may write. Only the holder of the "pen" edits memory.Daily noteswhat happened today
Memory. Each day has a log of what got done, what was decided and what is still open.Saved sourcesevidence, not memory
Memory. Documents and pages that a fact came from are saved, so a claim can be checked later.The web, lastonly when memory is empty
Research. The web is searched only after memory comes up empty, and what is found gets saved back.CPlannothing is built before it is approved
Done in one linemeasurable
Plan. Before any work, "done" is written as one sentence that can be checked, like "the form replies and the test passes".Map the coderead before writing
Plan. An explorer reads how the existing code works, so new work follows what is already there.Write the planfile by file
Plan. A planner turns the request into ordered, testable steps that name every file that changes.Owner approvesnothing starts before
Approval. The plan waits for a yes. If the answer is "change this", it goes back to the plan.DBuildtest first, then the smallest fix
Failing test firstproves the gap
Build. A test that fails is written first, so it proves the problem exists before anything is fixed.Smallest fixjust enough to pass
Build. Then the smallest change that makes the test pass. Less code means less to break.Full suite + buildeverything still works
Build. Every test and the full build run again, so a fix in one place cannot quietly break another.Fix if redsmallest repair
Build. If anything turns red, a build fixer gets it green again with the smallest change and re-runs to prove it.EReviewthree reviewers and a scanner
Code reviewreal defects only
Review. A reviewer reads the change cold and reports only defects it can prove with a line and a failure case.Security reviewsecrets, inputs, access
Review. Anything touching logins, user input, webhooks or outside services gets a security pass.Silent failureserrors that look like success
Review. A hunter looks for errors that get swallowed and report success, the kind nobody notices until it matters.Scannersecrets, code, packages
Runs by itself. Automated scanners check for leaked secrets, risky code patterns and known-vulnerable packages.FProve it workscheck the result, not the code
What would break?name the effect
Verify. First, name what would look different if the change did not work.Check the real thingbrowser or live system
Verify. Then look at that exact thing: the page in a real browser, the email in the inbox, the row in the table.Effect confirmedwith evidence
Verify. Only a confirmed effect counts as done. "The code looks right" does not.GShipevery step confirmed
Commiton the owner’s word
Approval. Changes are saved to history only when the owner says so.Pushon the owner’s word
Approval. Sending them to the shared copy is a separate yes.Remote matcheschecked, not assumed
Verify. The shared copy is read back to confirm it holds exactly what was pushed.Deployon the owner’s word
Approval. Going live is its own yes, never bundled with the others.Check the live siteevery page tested
Verify. A script checks the live site page by page. If it fails, roll back and redeploy.Tell search enginesnew pages found fast
Ship. Changed pages are announced to search engines so they are picked up quickly.HGuardrailsenforced by the machine
Guardevery write and command
Runs by itself. Every file write and command passes a guard first. Risky ones are stopped or sent for approval.Approval pop-upone click to allow
Approval. When the guard asks, a small desktop pop-up lets the owner allow or deny it.Blocked pathscredentials never read
Runs by itself. Files that hold passwords and keys are blocked outright. The assistant cannot open them, even by mistake.Clean-up sweepafter each edit
Runs by itself. After each edit, a sweep catches a known class of path mistakes before they cause trouble.IHandoffwork survives a full context
Context watchwarns at 30%
Runs by itself. An assistant can only hold so much at once. A watcher warns well before it fills up.Handoff updatedafter every step
Handoff. The handoff file is rewritten after every finished step, never only at the end.Pen releasedexact next steps
Handoff. Before stopping, the next steps are written out exactly and the pen is released.Next session picks upno lost work
Handoff. A fresh session, or a second assistant, reads the handoff and carries on from the same spot.JGet bettera weekly self-review
Weekly reviewstarts by itself
Runs by itself. Once a week, a self-review starts automatically at session start.Find what failedfrom the week’s logs
Improve. It reads the week’s notes for mistakes, corrections and anything that had to be redone.Fix it at the sourcethe cheapest place
Improve. Each problem is fixed in the cheapest place that will catch it next time: a rule, a check or a script.Grade last weekdid the fixes hold?
Improve. Last week’s fixes are graded: did the problem come back or not?KYour automationthe same loop, applied to your business
Audit the taskwhat eats your time
Your build. We look at the task you repeat every day: what starts it, what it touches, what goes wrong.Plan itin plain words
Your build. You get a short plan: trigger, steps, safety net and what you will see when it works.You approvenothing built before
Approval. Nothing is built until you say yes to the plan.Build in n8non your tools
Your build. The automation is built in n8n and connected to the tools your team already uses.Test on sample databefore real data
Your build. Every path is tested with sample data first, including the ones where something fails.Hand it overyou own it
Your build. You get the working automation, the logins stay yours, and a short walk-through of how it runs.Plain-English glossary
The few words on this map that need one.
n8nThe automation tool your workflows are built in. You can host it yourself, so you own it.
HookA check that runs by itself at a set moment, like at start-up or before every command.
GateA step that waits for a person to say yes.
HandoffA file that says where the work stands, so nothing is lost between sessions.
Sample dataMade-up records used to test every path before your real data is touched.
DeployPutting a change live, done only on the owner's word.