Portfolio Architecture Defense

This is the final checkpoint.

You are not presenting every CSS rule.

You are defending the architecture and evidence behind a real published Jekyll site.

Opening claim

In two minutes or less, explain:

• what the portfolio is for;
• who it serves;
• why Jekyll fits the project;
• the main source-to-public pipeline.

Architecture walkthrough

Use your diagram to explain:

content
→ Liquid/templates
→ configuration/dependencies
→ Jekyll rendering/build
→ generated site
→ Git/GitHub
→ Pages deployment
→ browser

Use your actual architecture, not a memorized generic diagram.

Page trace

Choose one real project page and show:

• source document;
• front matter;
• content model;
• layout/include chain;
• generated output;
• public URL;
• source commit.

Decision defense

Be ready to answer:

• Why a collection for projects?
• Why custom layouts or a theme?
• Why did you keep/reject a plugin?
• Why this deployment mode?
• What did you prioritize for accessibility/privacy?

Failure defense

Describe one failure without jumping to the fix.

State:

symptom
surviving behavior
failed evidence
bounded diagnosis
repair
verification

Change request

A reviewer may give you one new scenario:

• add another project;
• change repository path/baseurl;
• remove a plugin;
• rename a permalink;
• theme update changes markup;
• image missing in production.

Explain which source/configuration/deployment boundaries would be affected before proposing edits.

Final evidence

Submit or preserve:

• published portfolio;
• source repository;
• review-candidate commit;
• architecture diagram;
• evidence dossier;
• quality audit;
• failure/recovery evidence;
• decision records; and
• final defense notes/recording if required.

The standard

You have completed the course when the site is not just something you made.

It is something you can read, rebuild, debug, deploy, and explain.