# File management

New file/New folder and file-tree item menus mutate server source. Create/rename/delete are not reader deployments. Verify account, exact physical path, unsaved work and recovery before changing files, especially shared folders.

# Operation matrix

The server rejects invalid/outside-content paths and enforces physical assigned sections. Editors cannot write/rename/delete their top-level section folder itself. Symlinks or .. are not supported ways to reach another section/private runtime. Admin global scope still does not authorize accidental destructive targets.

# Choose location first

The editor creation dialog lists authorized folders at available nesting depths. Admin also gets / (top level). Root toolbar preselects current file’s parent; item menu preselects clicked folder or clicked file’s parent. When preferred path is not available, picker uses its available fallback.

Preselection is a convenience, not proof of destination. Verify engineering versus support before using the same workstation-check.md name. New page in Admin catalog has a simpler top-level/section picker; nested creation belongs to editor’s full folder list.

A disappeared parent returns Parent folder not found rather than inventing a missing selected folder. Refresh tree and inspect another writer’s rename/delete before repeating creation.

# Name normalization

My New File becomes my-new-file.md; Test Folder! becomes test-folder. Punctuation/non-ASCII removal can make two different names collide or produce surprising empty/dot-like forms. Read actual returned path and errors. Do not assume every original name remains recognizable or every weird input is rejected by normalization alone.

Top-level section rename additionally requires the strict section-name pattern. Creation/folder normalization and later assignment validation are not identical APIs. Prefer uncomplicated lowercase ASCII names matching section rules for top-level folders.

Existing target is refused 409 and not overwritten. Case/normalization can make seemingly new names existing targets. Investigate before deleting anything to make a dialog succeed. A file extension represents Markdown source, not a route promise.

# Create a complete source page

1. Select intended authorized physical location.
2. Enter a deliberate filename and create.
3. Read returned path and starter frontmatter/body.
4. Replace generic description/start text with a complete useful task.
5. Save and reopen/verify source.
6. Build and inspect title-derived route/search/media.
7. Publish/release when approved and verify actual host.

A new page includes title/description/H1/starter body from normalized basename. New folder includes _index.md title/description/H1/welcome text. These are writing scaffolds, not finished documentation. Add purpose, audience, steps, expected results, failure/recovery and useful links.

Creating a page opens it after tree refresh; if another unsaved page was open, file-switch discard behavior can apply. Preserve that work first. Creating a folder refreshes tree and reveals parents; it does not automatically open/finish its landing or assign new writers.

# Rename source without assuming route stability

Rename dialog changes basename in current parent, not a general relocation tool. It normalizes name like creation. Saved frontmatter/body is not automatically rewritten by a filename rename. Build title-derived paths and source relative link resolution separately before release.

If rename affects currently open file or ancestor, departure guard offers Stay/Keep draft/Save-and-leave. On successful same-editor rename, current text/path and baseline rebind; old draft key is removed and new path remembered. Dirty text can become recovery under new key. This does not migrate every other profile/tab’s recovery.

Supported top-level administrator folder rename updates editor assignment names, raises versions and ends affected sessions. It attempts filesystem rollback if grant update fails; inspect actual state on failure. Renaming through some unrelated operating-system/Git action does not imply the same assignment handling.

Ask writers to save/preserve and plan source links/old-host redirects before shared rename. No automatic reader redirect, universal draft migration or realtime collaboration is provided. Sections and pages covers metadata-plus-rename partial saves.

# Delete is permanent source removal

Read exact path and descendant scope in confirmation. Keep Git/private backups and necessary text outside the destructive workflow. A Keep draft choice before deletion is not a retained-archive promise: successful deletion removes current draft record. Drafts and saving explains this interaction.

The content root itself is not deletable. Editor cannot delete section root. Admin Sections deliberately lacks a bulk whole-section Delete control, but file-tree folder Delete is still destructive. Do not use deletion to hide/sidebar-order content or clean up ambiguous target errors.

Retirement should plan replacement/deprecation text, media retention and redirects/removal. Hidden content still builds/searches; removed source may remain hosted if deployment only adds files. Deleting a page/link does not automatically delete its static attachments or make previously disclosed secrets private.

# Error and completion checks

A lost response is uncertainty, not a reason to repeat destructive actions. Refresh current tree/source and inspect old/new paths. Saving an old loaded path can recreate source if still authorized; compare moved/deleted files before saving old drafts.

After creation/rename/delete, verify source, account assignments when affected, fresh writer access, build collisions, planned/actual links and deployed old URL response. Source success does not prove reader-host success. Use disposable synthetic content for destructive and negative-permission exercises.