Design a Markdown documentation folder that can travel

Design a Markdown documentation folder that still works when moved or shared: a root entry page, relative links, local assets and a simple manifest.

Make one place to begin

The Portable Docs Lab is an original fictional package. Its root README.md is the entry point; docs/ holds an overview and a decision; assets/ holds an SVG. A reader can see the path before choosing an app. The README also explains the one intentionally broken example so it is not mistaken for a defect in the main package.

This layout separates narrative documents from assets without requiring a build system. It does not prescribe one universal directory tree. A small project may put every file together; a larger one benefits from stable names and a manifest.

Prefer relationships the recipient can keep

Inside docs/overview.md, the image path ../assets/reading-path.svg means “one directory up, then assets.” It works only while those folders remain in that relationship. A URL to a remote image is easier to paste but depends on connectivity and ownership of that server. An absolute /Users/... path names one machine. Choose deliberately, and document any external dependencies.

Keep essential navigation as ordinary Markdown links when portability matters. Tool-specific syntax may be valuable inside its native app, but test it outside that environment before using it for a handoff. An index or manifest should name the files that must travel together.

Ship the tested copy

Copy the whole folder to a different location, open its README, follow important links, and inspect images with the network off. Record the renderer used and unresolved items. The moving-folder experiment isolates what happens if you move one file instead. The handoff checklist applies the same principles to a recipient-facing package.

This is an editorial design recommendation, not a claim that Aero Markdown automatically repairs paths. The Mac app is not yet public.