Stress-Test the Build

A final project should survive more than the one happy path you used while building it.

Test 1: clean rebuild

From a safe clean state, regenerate the site from source and declared dependencies.

Goal:

prove you do not depend on an accidental hand-edited _site file or stale output.

Test 2: new project

Add a small temporary/project-test document using the same content model.

Does it automatically receive:

• expected layout;
• generated URL;
• project-index listing;
• technology metadata rendering;
• responsive design?

If adding one project requires editing four unrelated templates, your architecture may still be too manual.

Test 3: missing optional data

Remove an optional field from a test project.

Does the template fail, render blank junk, or handle the absence intentionally?

Test 4: dependency recreation

On a clean compatible environment if available, use the repository dependency files to reproduce the build.

Do not reinstall/change the classroom host destructively for this test.

Test 5: invalid content

Use a disposable syntax error and prove your diagnostic process still finds it quickly.

Stress-test record

Test:
Expected:
Observed:
Pass/fail:
Revision required:
Re-test:

Checkpoint

Choose the stress test that revealed the weakest architecture assumption and explain what you changed.