SCOPE (read in code 2026-09-22 night): ONE writer - ProvisioningApplier, lines 99 and 105 - through 10 XML ops (AddSkill, AddKnowledgeArticle, AddSetting, AddAgency, AddActorProfile, AddActorSkill; AddSiteBlueprint, AddSkillBinding, ActivateFeature). AddListItem rows are ALREADY in the database and out of scope. WHY AN OVERLAY FILE IS NOT ENOUGH: AddSetting, AddActorSkill, AddSkillBinding and ActivateFeature MODIFY shipped elements (a Setting into a shipped SettingScope, a skill into a shipped Actor, a binding into a shipped blueprint), and every handler dedupes against ctx.Parts - a runtime-only file would re-add shipped ids and PartLibrary refuses duplicates at boot. DESIGN, THE SHAREPOINT WAY: the hive stays read-only (the image); every successful XML-touching delta is appended to a JOURNAL (SharePoint keeps solution and feature state in its configuration database); at boot the working copy = shipped files + journal replayed, written to a runtime root (a volume in the container). Handlers already record Already exists; skipped, so replay is idempotent, and a new release's files are picked up because the working copy is rebuilt from them. The 12 readers that build the manifest path themselves go through one IEngineHost.ManifestPath / PartsPath pointing at the runtime root; MirrorToBinOutput goes. DONE WHEN: (1) boot leaves git status clean on Config/ - the manifest trap #29 is this same bug seen from the dev box; (2) a part created over MCP by an app principal survives a simulated redeploy (fresh shipped files + replay). Default for Development can keep today's behaviour so self-build commits still land in git; Production points the runtime root at the volume.