Do not create a # folder inside a publish template

What you'll see

You are working inside a folder whose .docly says "Schema": "Publish template". You need to add site configuration, so you follow the documentation, which consistently writes the path as #/site.json. You create a folder called #, put site.json inside it, and nothing happens — no headers, no image policy, no error either.

The same misreading produces #/API/, #/Root/ and #/Folder/ nested one level too deep. Everything stays silent, because a stray folder inside a template is not an error; it is simply never consulted.

The reverse mistake is just as common in the other direction: assuming a file placed in a publish template is definitive, and deleting or rewriting it as though it were the only copy.

What's actually happening

A publication resolves its # namespace in layers, first match wins:

1. The publication's own # folder
2. The publish template assigned to the publication
3. Platform defaults

A publish template is therefore the fallback layer behind #, not a folder that contains one. Its root is #. That is why every #/… path in the documentation maps to the template's root with the prefix removed — the prefix is already accounted for by what the folder is.

This is the same defaulting rule that #/Root/ and #/Folder/ apply one level further in: a file is used unless something more specific overrides it. A publication that ships its own #/Header.hash shadows the template's. A publication with no template assigned has only its own # folder, which is then the whole story.

You can confirm the mapping from any template that includes a shared header. <!--#include file="/#/Header.hash" --> resolves to Header.hash sitting in the template's root, not in a subfolder.

What to do

Strip the #/ prefix. Inside a publish template, the root of the folder is #:

#/site.json           →  ./site.json
#/Root/               →  ./Root/
#/Folder/index.hash   →  ./Folder/Index.hash
#/API/                →  ./API/

Never create a folder named # inside a publish template. If one already exists, its contents belong one level up.

Treat everything in the template as a default, not as the only copy. You are editing the fallback for an unknown number of live sites, and you cannot see from inside the template which of them override what:

• Removing a file does not remove it from sites that carry their own copy. It removes the safety net from every site that does not.
• Adding a file does not guarantee it takes effect. A publication may already shadow that path.
• A file that is missing from the template is not necessarily missing at runtime — some assets are served by the platform.

There is no staging: the folder on disk is production for every site that names it. Back up to a dated folder outside the drive, because a _backup-* folder left inside the template propagates to all of them.

Put the agent instruction file at .claude/CLAUDE.md inside the template and state the layering there. Nothing under # is served as a static file, so it is not reachable over HTTP, and an agent whose working directory is the template picks it up automatically. An agent that does not know the folder is a # folder will create the # subfolder; an agent that does not know these are defaults will delete files it believes are unused.