Sol37 Site Audit Skill

This file mirrors the local skill installed at: /home/david/.codex/skills/sol37-site-audit/SKILL.md

Executive Summary

This file mirrors the local skill installed at: /home/david/.codex/skills/sol37-site-audit/SKILL.md Local Skill Mirror: sol37-site-audit This file mirrors the local skill installed at: /home/david/.codex/skills/sol37-site-audit/SKILL.md It exists so the skill itself is auditable in the random repo even though ~/.codex is not currently a git repository.

Local Skill Mirror: sol37-site-audit

This file mirrors the local skill installed at:

It exists so the skill itself is auditable in the random repo even though ~/.codex is not currently a git repository.

Frontmatter

yaml
name: sol37-site-audit
description: Use when working on, reviewing, auditing, documenting, or verifying the Sol-37 site in random/www, including its retro shell, program pages, content tree, git history, local daemons, Caddy/Cloudflare publishing, logbook backend, metrics pipeline, and media-player/video ingestion path.

Body

md

Sol37 Site Audit

Use this skill for requests about the site in /home/david/random/www and its supporting services.

Scope

This skill covers:

  • site reviews and architectural summaries
  • git-history inspection for random/www and related backend scripts
  • runtime verification of Caddy, Cloudflare tunnel, IRC/logbook, and metrics services
  • content/tree mapping for the public web root
  • media-player and /video pipeline review

Canonical Audit Summary

The committed audit summary and site-server manual live at:

  • /home/david/random/docs/sol37-site-audit.md
  • /home/david/random/www/README.md
  • /home/david/random/www/site-server.html

Read those first for current architecture, service layout, boot behavior, and verification commands.

Files To Inspect First

  • /home/david/random/www/index.html
  • /home/david/random/www/README.md
  • /home/david/random/www/site-server.html
  • /home/david/random/www/sitemap.html
  • /home/david/random/www/site-metrics.html
  • /home/david/random/www/programs/logbook.html
  • /home/david/random/www/programs/star-map.html
  • /home/david/random/www/programs/media-player.html
  • /home/david/random/bin/Caddyfile.pkd_share
  • /home/david/random/bin/public_logbook_api.py
  • /home/david/random/bin/public_logbook_irc_logger.py
  • /home/david/random/bin/site_metrics_snapshot.py
  • /home/david/random/bin/video_playlist_watch.py

Standard Audit Workflow

1. Inspect repo state:
git -C /home/david/random status --short
2. Inspect recent site/backend history:
git -C /home/david/random log --oneline --decorate -- www bin
3. Map the current public tree:
find /home/david/random/www -maxdepth 2 -type f | sort
4. Verify the local web origin:
curl -I -s http://127.0.0.1:8888/
5. Verify managed services when relevant:
systemctl --user --type=service --state=running | rg -i 'caddy|cloudflared|logbook|site|video'
6. Verify timers when relevant:
systemctl --user list-timers --all | rg 'site-metrics|synthetic'
7. Verify runtime daemons and ports when relevant:
ps -ef | rg -i 'caddy|cloudflared|ngircd|public_logbook|site_index|video_playlist|irc'
ss -ltnp | rg '(:8888|:6667|:8890)'
8. Verify user-manager boot persistence when relevant:
loginctl show-user david -p Linger
9. Verify logbook API when relevant:
curl -s 'http://127.0.0.1:8890/messages?channel=public-logbook&limit=3'

Repo And Mirror Workflow

Treat the local repo and the public GitHub mirror as different things on purpose.

Local repo workflow

- The authoritative working repo is /home/david/random.
- Use normal git inspection there first:
git -C /home/david/random status --short
git -C /home/david/random log --oneline --decorate --graph --max-count=20
git -C /home/david/random diff --stat
- Make and verify changes in the local repo first. Do not assume the GitHub repo is the source of truth.
- Preserve unrelated local changes. The repo may be dirty.
- When site behavior depends on machine-local services or files outside git, call that out explicitly.

Public GitHub mirror workflow

  • The public mirror remote is currently davidlones https://github.com/davidlones/random.git.
  • origin https://github.com/08server/random.git is not reliable; verify before using it.
  • The public mirror is a curated sanitized snapshot, not a faithful push of local history.
  • Keep the mirror aligned with the public README and exclude large media, caches, runtime logs, machine-local artifacts, secrets, and other sensitive clutter.
  • Prefer rebuilding a fresh public snapshot repo and force-pushing that clean snapshot to davidlones/main instead of pushing the full local repo history.

Snapshot mirror procedure

1. Verify the local repo state and inspect what should be public:
git -C /home/david/random status --short
git -C /home/david/random ls-files
2. Build a fresh snapshot from tracked files in /home/david/random, excluding large or sensitive paths and replacing the top-level README with the curated public README when needed.
3. Scan the snapshot for obvious secrets with rg before pushing.
4. Initialize git in the snapshot, create one clean root commit, and force-push it to davidlones main.
5. Verify the remote head with:
git ls-remote https://github.com/davidlones/random.git refs/heads/main

Mirror rules

  • Exclude oversized media and binary payloads by default.
  • Exclude runtime/generated data such as caches, __pycache__, temporary artifacts, local logs, and machine-specific state.
  • Exclude untracked local secret helpers such as bin/secret_client.py and bin/secret_daemon.py.
  • Keep placeholders like OPENAI_API_KEY if they are just variable names, but do not publish live credential material.
  • When describing git state, distinguish clearly between:
  • local repo history
  • local working tree state
  • public GitHub snapshot state

Review Priorities

Prioritize:

  • what is committed vs only live locally
  • what the shell claims exists vs what the machine actually runs
  • backend dependencies that are outside git
  • archive/content discoverability
  • program-window integration in index.html
  • media-player and /video pipeline behavior

Notes

  • Treat Sol-37 as a static-site shell with runtime-backed subsystems, not as a framework app.
  • Prefer the in-tree site-server manual in www/README.md and www/site-server.html when the user asks for whole-system documentation.
  • Preserve the distinction between committed repo history and current machine state.
  • When producing summaries, call out uncommitted operational features explicitly.