Test Blogs

Test blogs

Four production blogs, one per sync client, at https://{handle}.blot.im:

Related: investigate-dropbox-sync-issue, investigate-macserver-sync-issue, data-volume (read-only freeze). Design of the asset move: app/storage/README, app/storage/assets.js.

Rules

1. Ask the operator before every production command: ssh blot, ssh macserver, docker exec. State the exact command; approval covers that command only. List the planned commands together so they can be approved in one go. If the harness blocks a prod read, do not retry or rephrase: give the operator the command to run and paste back.
2. Only write to these four blogs' folders/repos. Never touch any other blog.
3. Writing into the four synced folders and pushing to gittest need no per-action approval once the operator has invoked this skill (they are their own test blogs), but say what you are writing and where.
4. Public repo: no credentials, account IDs, email addresses or ssh details here or in scripts/test-blogs/, and no production sizes or counts.
5. Read-only AWS calls (AWS_PROFILE=blot AWS_REGION=us-west-2 aws s3api head-object ...) are fine without asking; say what you ran.
6. Hand mechanical polling and verification (curl loops, header checks) to a cheaper subagent (sonnet/haiku) when it helps; judge the results yourself.
7. End every run by appending an entry to the run log below.

Test content

Names must be unique and recognisable: prefix everything skilltest-{unix timestamp} (e.g. skilltest-1760000000/post.md) so cleanup is a glob. Keep it small and write only what the question needs:

• Markdown post: fastest; exercises sync, build, render. Put Title: Skilltest {ts} and Link: skilltest-{ts} metadata lines at the top so the post is at a known URL, /skilltest-{ts}.
• Post with a JPEG/PNG (from anywhere on disk, copied in beside the post and referenced ![alt](photo.jpg)): exercises _image_cache and _thumbnails (thumbnails need the image in the post body or a Thumbnail: metadata line).
• .docx / .odt / .epub: exercises the converters and _assets.
• A second file edit or a delete + re-add: exercises update/removal paths.

Use one blog for a quick check; all four when checking the sync clients or a deploy. Always note which blog(s) and file names you used for the log.

Writing

Dropbox, Drive, iCloud: mkdir -p a skilltest-{ts} folder in the blog's folder above and copy the files in.

If a copy fails with "Operation not permitted", macOS privacy controls (TCC) are blocking the shell from the cloud folder. Do not work around it. The process macOS holds responsible is not Claude.app but the Claude Code binary it bundles (a disclaimer helper starts it), at a versioned path; find it with ps -o pid=,ppid=,comm= -p <pid> up the chain from $$, e.g. ~/Library/Application Support/Claude/claude-code/<version>/<hash>/claude.app. Ask the operator to add that claude.app under System Settings → Privacy & Security → Full Disk Access (⌘⇧G to paste the path) and restart Claude. The grant follows the version, so it needs redoing after a Claude Code update.

Git: the remote URL, with credentials, is the single line of ~/.config/blot/test-blogs/gittest-remote (mode 600, outside every checkout so any worktree's session finds it; the email in the URL is written %40). The operator creates it once. If the file is missing, tell the operator to create it; never ask for credentials in chat. Never print, log or echo the URL.

R=~/.config/blot/test-blogs/gittest-remote
git clone -q "$(cat $R)" "$SCRATCH/gittest" >/dev/null 2>&1   # SCRATCH = session scratchpad
cd "$SCRATCH/gittest"
# add skilltest-{ts}/..., then:
git add -A && git -c user.name=skilltest -c user.email=skilltest@localhost commit -qm "skilltest-{ts}"
git -c credential.helper= push -q "$(cat $R)" HEAD 2>&1 | sed 's#https\?://[^ ]*#<remote>#g'
git ls-remote "$(cat $R)" HEAD 2>&1 | sed 's#https\?://[^ ]*#<remote>#g' | cut -c1-12   # matches `git rev-parse HEAD`?

Redirect or redact all git output, since errors can echo the remote URL. Do not run git remote -v, git config --list or set -x.