George Starcher

Repository Instructions

Repository Instructions

Build and Verification

Use project-local Ruby and Bundler dependencies for this GitHub Pages Jekyll site.

Run this before proposing or merging site changes:

bundle exec jekyll build

For GitHub Pages correctness, verify:

  • url is https://www.georgestarcher.com
  • baseurl is empty for the root domain
  • generated CSS is available under /assets/css/style.css
  • robots.txt does not accidentally block the whole site

Review Guidelines

When reviewing pull requests, prioritize bugs and regressions over style nits. Focus especially on issues that would affect the live GitHub Pages site, the Journey page, Airtable sync, generated data, or deployment reliability.

For Journey changes, verify:

  • scoring behavior matches the configured settings and intended practice weights
  • generated _data/journey.yml remains consistent with exporter code
  • date, timestamp, and timezone handling stays correct for Central time
  • meditation, sleep, hydration, macros, steps, and HeartMath coherence data are not double-counted
  • mobile layouts remain stable across iPhone-sized screens and desktop Safari
  • selected-day interactions update rings, cards, hero art, path stones, or tooltips without jitter

For Airtable and data-sync changes, verify:

  • field IDs and slugs match the live Airtable schema
  • visible/completed filters do not accidentally publish hidden records or drop valid records
  • generated data changes are intentional and not broad churn from unrelated sync output
  • data-sync workflows still validate YAML, check pantry URLs, build the site, commit generated data, and trigger Pages deploy

For UI changes, verify:

  • text does not overlap or overflow on mobile
  • decorative elements do not push primary artwork or cards out of frame
  • controls remain usable by touch and mouse
  • visual indicators are clear without adding unnecessary explanatory text

For GitHub Actions or deployment changes, verify:

  • permissions are least-privilege for the workflow purpose
  • secrets or tokens are not exposed in logs, generated files, or summaries
  • the distinction between Jekyll build success and GitHub Pages deploy success is preserved
  • failure summaries remain useful before reading raw logs

Do not flag copy edits, wording preferences, or tiny formatting differences unless they affect meaning, accessibility, data interpretation, or user-facing clarity.

GitHub Actions Failure Review

When asked to check failed GitHub Actions, use gh against georgestarcher/blog.

Start with:

gh run list --repo georgestarcher/blog --status failure --limit 10

Before reading raw logs, check whether a corresponding AI Workflow Failure Summary workflow run exists for the failed workflow. If it completed, read the GitHub Actions run summary generated from GITHUB_STEP_SUMMARY first and use that as the starting point for the failure report. If the summary is not available from the CLI, include the summary workflow run URL and then inspect the raw failed run logs.

For each relevant failed run, inspect the run and logs:

gh run view RUN_ID --repo georgestarcher/blog
gh run view RUN_ID --repo georgestarcher/blog --log

Summarize:

  • workflow name and run URL
  • branch, event, and commit if available
  • most likely root cause
  • shortest safe confirmation command
  • recommended fix sequence
  • whether rerun should be full workflow or a narrower job first

Do not change code while summarizing failures unless the user explicitly asks for a fix.