Tooling Must Match Where the Tool Actually Loads
Agents only see what the runtime and workspace give them. Rules, configs, and paths have to match reality—or you get elegant architecture that the model never reads.
Tooling Must Match Where the Tool Actually Loads
Every environment has non-negotiables: where the IDE loads rules, where the build reads config, which env vars exist in CI vs locally. Ideal folder layouts don’t matter if the tool never reads them.
We’ve seen this: a “master” template repo that feels like the source of truth; real work lives in the application repo. Rules only apply when they sit where the editor or agent runtime actually loads them—often the workspace root, not a nested folder that looked tidy in design.
Until docs and installers say that out loud, people assume the stack “should just work” and then wonder why behavior ignores the rules.
The fix: match platform behavior, not your favorite diagram. Copy or link config to the paths the tool documents. Make the install path predictable and repeatable. Alignment is structural—not magic.
The insight: your agent stack is only as good as the paths and contracts the runtime actually honors.