Unit 09 · lesson

Audit the Portfolio as a System

You are done adding major Jekyll features.

Now stop looking at the portfolio page-by-page and inspect the system you built.

The whole architecture

Your site now has interacting layers:

CONTENT
pages / posts / projects / data
      ↓
TEMPLATE SYSTEM
Liquid / layouts / includes
      ↓
CONFIGURATION + DEPENDENCIES
_config.yml / Gemfile / theme / plugins
      ↓
JEKYLL BUILD
render / convert / compose / write
      ↓
GENERATED SITE
HTML / CSS / images / metadata
      ↓
DEPLOYMENT
GitHub repository / Pages workflow
      ↓
PUBLIC BROWSER EXPERIENCE

A problem in one layer can surface somewhere else.

Build an audit inventory

Create a table:

Layer	Source owner	Evidence	Known risk
content	`_projects`, `_posts`, pages	rendered pages	stale/private content
templates	`_layouts`, `_includes`	shared generated markup	site-wide regression
configuration	`_config.yml`	generated URLs/build behavior	wrong production values
dependencies	Gemfile/lock	bundle/build	version portability
deployment	Pages settings/workflow	Actions/run + public URL	build/deploy failure

Add the layers you actually use.

Look for invisible coupling

Examples:

project layout assumes every project has summary;
navigation assumes every URL is root-relative;
theme override assumes a theme file structure;
plugin tag assumes the plugin is present in production;
project images assume one asset path convention.

Write those assumptions down.

No feature-count scoring

A smaller site you can explain and maintain is stronger than a complicated site full of unused Jekyll features.

Delete or simplify anything that no longer earns its complexity.

Checkpoint

Name the three most important architecture boundaries in your portfolio and explain the evidence you would inspect if each one failed.