BugToBuild
My engineering workspace and toolchain — the place where a reported bug becomes a shipped build.
The Workshop is the one district with tools on the bench instead of a product in the window, because BugToBuild is not a product. It is the umbrella my own engineering work lives under — the workspace, the toolchain, and the habits.
Every other project in this city was built inside it. Including this city.
Why it has a name at all
Naming your workspace sounds like an affectation until you have four projects running at once and a scattered set of one-off scripts you rewrite every time.
Giving it a name forced a decision: anything I have solved twice gets promoted out of the project it started in and into the shared workspace, with a real interface and a real place to live. Anything I have solved once stays where it is. That single rule is most of what separates a toolchain from a folder of scripts.
What lives in here
Scaffolding and project bootstrapping, local automation for the repetitive parts of setup and deploy, and the shared TypeScript configuration and conventions that every project inherits so I am not re-deciding the same things monthly.
The name is the method
A bug report is the cheapest specification you will ever be handed. It is a reproducible statement about a gap between what the system does and what it should do — which is exactly the thing a feature request usually is not.
So the pipeline runs one way: bug, to reproduction, to the smallest change that closes it, to a build. Not “bug to patch.” Bug to build — because if closing it did not leave the thing shippable, it is not closed.