Most of it had nothing to do with what I was actually doing.
The Salesforce org guards exist for a real reason. I have production health systems under those aliases, and the wrong command in the wrong org is a genuinely bad day. But sitting in the publishing queue at midnight working on a draft, those guards weren't protecting anything. They were just there, using space, competing with the context that actually mattered.
The publishing discipline rules are non-negotiable when I'm in the publishing pipeline. But they're noise when I'm scaffolding an agent or running a codebase audit. Every rule was right somewhere. The problem was that somewhere had collapsed into always.
The Weight of Always
Here's what completeness costs you in a context window: the signal-to-noise ratio drops.
Modern models handle long contexts. That's not the issue. The issue is subtler. When a session opens and the first twelve thousand tokens are rules for projects you're not in, you've started with a premise about who you are and what you're doing that doesn't match reality. The Salesforce no-mutate-without-authorization rule is critical in a Salesforce session. As context in a publishing session, it's scenery. The publishing no-code rule is absolute when you're writing an article. In an agent-authoring session, there's a carve-out for academic papers that the rule makes explicit. The distinction matters in the right context and creates confusion in the wrong one.
I also noticed something about prompt caching economics. The always-loaded file was around 582 lines when I started auditing it. That's not just a token count; it's a cache key. When the file changes, the cache misses. When every session loads 12.8 thousand tokens of mixed-relevance rules, that's the baseline cost whether the task needs them or not.
I kept running into the same pattern from the other direction too. Rules were precise and complete in the always-loaded file, but the file had grown so large that adding a new rule meant weighing whether the universal load cost was worth it. The constraint was limiting. A rule that only applies to Salesforce work shouldn't cost every non-Salesforce session anything.
The question I kept circling was: what would it look like if the rules were context-aware?
What a Manifest Buys You
The insight was straightforward once I framed it correctly. Every project has a known context. The publishing queue is always publishing work. The Salesforce project is always Salesforce work. The agent-authoring project is always agent-authoring work. The current working directory tells you the context. The context tells you the rules.
A SessionStart hook reads a manifest file that maps project paths to their relevant rule files. When a session opens in the publishing queue, publishing rules load. When it opens in the Salesforce project, Salesforce rules load. When it opens in template-forge, agent-authoring discipline loads. The global file keeps the rules that apply everywhere: IP protection, security, git discipline, quality standards, the orchestrator mandate. The scope-specific sections got relocated into their own files. The global file kept stubs with the original section numbers intact, so every cross-reference still resolves correctly.
The pieces that moved: six major sections including the publishing pipeline, the Salesforce org scope rules, the agent self-star discipline, the UI standards, and the canonical doc formats. About 171 lines extracted from a 582-line file. Roughly 29 percent of the always-loaded context, now loading only where it's relevant.
The safety-critical rules stayed inline regardless of where you are. The concurrency policy, the IP firewall, the security hard stops. Those enforce at execution time via hooks and runtime gates, not via what the model read at session start. Moving their documentation into scope files wouldn't weaken them, but leaving them always-loaded costs nothing at session start and keeps them front-of-mind for every task.
That distinction took me the longest to get right in the design: documentation of a rule and enforcement of a rule are different layers. The Salesforce org guard runs as a hook before every command that touches an org. It resolves the alias to a username, checks the resolved identity against an allowlist, and refuses if the org is guarded. That logic runs regardless of whether the Salesforce rule documentation loaded into the current session's context. You can relocate one without touching the other.
What Proved It Out
I noticed it was working right away. Sessions in the publishing queue felt like publishing sessions. The rules that surfaced were the rules that applied. The Salesforce guards weren't competing for attention with the publishing discipline. The publishing no-code rule wasn't diluting the Salesforce org safety model.
The session-start context got leaner and more precise at the same time. The model was operating with rules that matched the task at hand. That's a different quality of assistance than operating with a universal ruleset that covers every possible session.
The principle that emerged from building this is something I think about more broadly now. Context is information. Where you are matters. A model operating in a publishing session that has publishing rules front-of-mind is more reliably useful than one that has to sort through twelve thousand tokens of mixed context to find the relevant rules. The rules didn't change. Their relevance didn't change. Only their delivery changed, and that turned out to matter more than I expected.
The manifest is a short file. The hook is a SessionStart script. The rule files existed already, just embedded in one always-loaded document. The migration was mostly extraction and routing.
The outcome is a system that shows up differently in different contexts, not because it was built differently for each one, but because it was given the right information about where it is. That's the right layer to work at.