Generation Overview

Now that you understood the folder structure, let's get a birds-eye overview of how the generation of the website happens.

The 2 main folders: build/ and projs/
The build/ folder can be left empty if you want. Once FillPouch does its magic, finally all the files generated by FillPouch will be seen in a sub-folder under that folder. Both these folders are two sub-folders in the same folder where the fillpouch.exe executable file is residing. (That's the default. This can be changed with some advanced settings)

You would be working mainly in your project's own folder, which is a sub-folder inside the projs/ folder. Inside your project's own folder, you would be depositing all the fragments (explained later).

The actual representation of the "root" of your website should be in a folder that is normally named "www/" and it is a sub-folder under your project's own folder. i.e. the www/ folder is sibling of the fragment files present in the project's own folder.

Your Project file
This is the file that you supply to fillpouch.exe executable to work on. At the very bare minimum, it should contain the root(...) instruction (explained earlier in these docs)

What does FillPouch actually do?
FillPouch will pick up each of the file(...) instructions and then search for that file under the "projs/" folder. Often these have an extension of .sd and it can contain a mixture of "pouch" meta-instructions and your content. (But the recommended practice, is to shift the contents to its own fragment file after leave behind just a pouch in the original place.)

FillPouch will methodically parse through each of the files it finds, and then after processing them, it generates the final html files... with the same names as the original .sd but with the .html extension. It is generated in the equivalent branch the builds/ folder as that of the original .sd file.

From version 0.5.3 onward, Fillpouch can also process unlisted files i.e. files that are present somewhere under the www/ folder of your project's own folder; but are themselves absent in the main project file instructions. Such files cannot be used to form auto-links for the project nor can they be cloned. But other than those two limitations, they are processed like other files (e.g. once you insert pouches in them, etc)

The bare minimum project
The bare minimum project (i.e. one that uses very little to almost none of the FillPouch capability) would be simply a complete website you create under the www/ folder of your project's own folder. You'll simply create a set of .sd files just like in a regular, manually created website, and place those at the correct locations under www/. In the project's main project file, you will only give the "root(...)" instruction just to point out where this "www/" folder is residing. Nothing else.

Note in the above case those .sd files will have exactly the same content as manually written HTML files. If that be the case, FillPouch's own capabilities will not be used and instead FillPouch will simply copy the files over to the equivalent folders under the build/ folder and create the site there. (renaming the extension from .sd to .html)

If you had named the original file as .html (and not with .sd extension) then FillPouch will simply copy it over to the equivalent folder under build/ folder! Such a site can be made using one of the various HTML editors around.

Obviously, you would be at a major disadvantage because FillPouch did not really help you in the above scenario-- but this is a good way to understand how FillPouch works. And also, it points out to the gradual manner by which one can work:

You can start like this, but then you realize you can "fragment" the content of the file, store each such fragment separately above the "www/" folder, and you insert a "pouch" meta-instruction at the original location where the fragment once was!

Once you become comfortable with this kind of refactoring, where you fragment files, you can achieve a lot!

That's all you need to know for now. You will understand the balance nuances from the rest of the documentation here.