Repository Guidelines

Project Structure & Module Organization

This repository is a Jekyll site published through GitHub Pages. Blog articles live in _posts/ and use YYYY-MM-DD-title.md filenames; unfinished content belongs in _drafts/. Wiki entries are stored in _wiki/, while standalone routes such as About, Archives, and Tags are under pages/. Shared Liquid markup belongs in _includes/, page templates in _layouts/, and site-wide data in _data/. CSS, JavaScript, images, and third-party libraries live in assets/. Treat assets/vendor/ as vendored code and avoid editing it unless intentionally upgrading a dependency.

Build, Test, and Development Commands

• gem install bundler installs the Ruby dependency manager used by CI.
• bundle install installs the gems declared in Gemfile.
• bundle exec jekyll serve --livereload serves the site locally, normally at http://127.0.0.1:4000.
• bundle exec jekyll build renders the production site into _site/; run this before submitting changes.

The GitHub Actions workflow performs the same Jekyll build on pushes to master and deploys the generated site from the built branch.

Coding Style & Naming Conventions

Use two-space indentation in YAML and Liquid/HTML templates. Preserve the surrounding style in legacy CSS and JavaScript. Markdown pages must begin with valid YAML front matter; use _posts/template.md as the baseline. Keep front-matter keys lowercase and descriptive, for example layout, title, categories, description, and keywords. Use lowercase, concise filenames for new wiki pages and date-prefixed filenames for posts. Do not commit _site/, editor files, or Jekyll cache metadata.

Testing Guidelines

There is no dedicated automated test suite. A clean bundle exec jekyll build is the required validation. For layout, navigation, CSS, or JavaScript changes, also inspect the affected pages locally at desktop and narrow viewport sizes. Check links, code highlighting, search, and front-matter-driven category/tag pages when relevant.

Commit & Pull Request Guidelines

Recent history uses short Conventional Commit-style subjects, primarily feat: ... and fix: .... Keep commits focused and use an imperative summary, such as feat: add Docker wiki entry. Pull requests should describe the change, list local validation performed, link related issues, and include before/after screenshots for visual changes. Never commit access tokens or new credentials; use GitHub repository secrets for deployment values.