Every single Write step in every feature in this catalog says some version of "add this section to admin\AGENT_INSTRUCTIONS.md." None of them, individually, say what to do if that file already has content in it that has nothing to do with this catalog — because the assumption baked into every feature file is that either the file doesn't exist yet, or that something else handles the merge. That assumption is false the moment a single feature gets installed into a project that already has its own agent instructions. It was found the direct way: a person installed FTR-15 (Project Cache) into an existing project, dependency resolution correctly pulled in FTR-13/07/06/05, and the resulting AGENT_INSTRUCTIONS.md write overwrote what was already there. Nothing in the chain had ever been asked to check.
The rule, stated once, unconditionally, for every install this catalog ever performs — single feature or "install everything," regardless of which features are or aren't chosen:
Before writing anything to a project's admin\AGENT_INSTRUCTIONS.md:
- Check whether the file already exists.
- If it does, read it in full first.
- The write is always an additive merge — add or update only the section(s) belonging to the feature(s) actually being installed right now (each feature's own
◆ SECTION NAMEheader marks its boundary). Every other section stays untouched, regardless of where it came from: a prior Claude Project Assistant install, a full Bootstrap run, the Alignment Companion, or content that predates this catalog entirely and has nothing to do with it. - If a section this install would add already exists (a prior version of the same feature), update it in place rather than duplicating it.
- Never replace the whole file. Never assume an empty or missing file without checking first.
Why this isn't a dependency, and isn't satisfied by installing FTR-01: FTR-01 (Bootstrap Operating Behavior) documents this same principle — but as content written into a downstream project, describing how that project's own future bootstrap reruns should treat existing instructions. It has no effect on how this catalog's own install action behaves right now, and it only ever runs at all if someone happens to choose to install it. The rule above is not something a person opts into by picking a specific feature — it governs the install mechanism itself, the same way copyright limits or safety guardrails aren't something a request opts into; they're just always active. Making FTR-01 a formal dependency of all other features would be the wrong fix even if it worked, because dependencies in this catalog mean "this structural thing must exist first" — they've never meant "this behavioral safety rule must be followed," and conflating the two would make the dependency graph lie about what it's actually tracking.
What this doesn't replace: once a merge is confirmed safe by the rule above, FTR-01/FTR-04/FTR-24's own installed content (if those specific features are chosen) still governs the quality question — see Merge philosophy below. That's a real but separate, higher-level concern (is the merged result sharp and specific, or generic and thin) layered on top of the baseline safety this section establishes.