boondoggling.ai — Owner's Guide

Getting In

Admin login: https://www.boondoggling.ai/admin/login
Password is set in the Vercel dashboard as the ADMIN_PASSWORD environment variable. Sessions last 7 days.

If you get logged out mid-edit, your blog post draft is in sessionStorage — it survives the redirect to login. Log back in and it will still be there.

Publishing Content

Blog Post

1. /admin/dashboard/blog → New Post
2. Write in the Tiptap editor. Upload cover image via the toolbar.
3. Add tags. Set slug (auto-generated from title — edit if needed).
4. Save Draft → Preview → Publish.
5. Post appears on /blog immediately on next page load. No redeploy.

Video

1. /admin/dashboard/videos → New Video
2. For YouTube: paste the video ID (the part after ?v= — e.g., dQw4w9WgXcQ).
3. For uploaded video: upload an MP4/WebM (max 500MB) — it goes to Vercel Blob.
4. Add title, description, tags. Pin it to surface it at the top.
5. Publish. Appears on /videos immediately.

Tool (System Prompt)

1. /admin/dashboard/tools → New Tool
2. Set tool_type to prompt.
3. Paste the full system prompt into prompt_text.
4. Set quality_signal to curated.
5. Set version (e.g., 1.0).
6. Write a one-paragraph description: what it does, who it's for, how to install it.
7. Publish. Appears on /tools immediately.

Community SDD Doc (/dev)

1. Receive submission via email or DM.
2. /admin/dashboard/dev → Upload Draft → select the HTML file.
3. Fill in: title, slug, description, category (WWW / Agents / Games), submitted_by (name/handle — no email).
4. Click "Upload Draft." File goes to Vercel Blob. Draft record appears in the queue.
5. Run the doc audit before publishing — see the Audit section below.
6. In the draft queue, click "Publish." Set quality_signal, add build_url if provided, paste the audit report into the notes field.

Nik-authored /dev docs

Drop the HTML file into the correct subdirectory, commit, and push. Vercel rebuilds in ~1 minute.

Files in /gru/ subfolders automatically get the "Built with Gru" badge. The HTML file needs two tags and the scanner does the rest:

<title>Your Project Name</title>
<meta name="description" content="One sentence about what this build is.">

Adding a new category

mkdir -p public/dev/NewCategory/gru

Add at least one HTML file, commit, and push. The new category appears on /dev on the next deploy. No code change required.

Quality Signals

Every /dev doc and /tools entry carries a quality signal visible on its card.

To change a quality signal: edit the entry in the admin dashboard. Updates immediately on next page load.

Running the Doc Audit

Every community submission should go through the audit before publishing. The audit tool lives at /tools — find "Admin: Doc Audit Prompt."

1. Open /tools/admin-doc-audit-prompt and copy the prompt.
2. Open a new Claude Project (or fresh conversation). Paste the prompt into Project Instructions.
3. Paste the submitted HTML content into the conversation.
4. Read the audit report — it flags missing sections, methodology errors, incomplete Boondoggle Scores, and quality signal recommendation.
5. Decide: publish as Featured, publish as Community, return with feedback, or decline.
6. Paste the audit report into the "Audit report" notes field in the admin dashboard before publishing.

The audit is not a technical gate — it is your judgment call after reading the report. The tool assists. You decide.

Making Changes to the Site (Frick-Fracking)

For small changes — a layout tweak, a copy edit, a new edge case that surfaced:

1. Open Claude Code (or Claude.ai with the codebase in context).
2. Name the change in one sentence. Include: what file, what behavior currently, what behavior needed.
3. If the change touches architecture (new DB column, new API route, new component), check it against the SDD first. One minute. Worth it.
4. Run the prompt. Verify the output. Ship.

Environment Variables

Set in Vercel dashboard → Project → Settings → Environment Variables. Never commit these to git — they live in .env.local for local development only.

Deployments

Automatic: push to main → Vercel builds → new deployment goes live in ~1 minute. Previous deployment stays live during the build.

Rollback: Vercel dashboard → Deployments → click any previous deployment → Redeploy. Instant. No DB rollback needed for code-only changes.

When a deploy fails: previous deployment stays live. Check Vercel dashboard for build error. Fix locally, push again.

Database (Neon)

Backups: Neon Pro plan runs automated backups with point-in-time recovery. Use Neon dashboard → Branches → Restore if something goes wrong.

Running SQL directly: Neon dashboard → SQL Editor. Useful for one-off fixes, backfills, or checking table state.

Vercel Blob

Blob stores blog cover images, uploaded course videos, and community HTML files.

To view stored files: Vercel dashboard → Storage → Blob → browse.

Orphaned files accumulate when an upload succeeds but the DB insert fails. They are not publicly accessible. Clean them up periodically by comparing Blob file names against dev_docs slugs — delete anything with no matching record.

To delete a file manually: Vercel Blob dashboard → find file → delete. Also delete the corresponding dev_docs record in Neon if one exists.

What Requires a Redeploy

Only one thing requires a git commit and push (and a ~1 minute Vercel rebuild):

Adding Nik-authored HTML files to /public/dev/ or /public/tools/

Everything else — publishing blog posts, tools, videos, dev docs, changing quality signals — happens through the admin dashboard with no redeploy.

Monitoring

Noodling (New Features)

When a new idea surfaces — a feature, a new tool, a new /dev category, a change to how the site teaches:

1. Write it in one sentence: "I want [feature] for [who] so that [outcome]."
2. Check the SDD P2 (out-of-scope). Is it explicitly excluded? If so, name why before proceeding.
3. If it passes: run /v1 with Gru to define it properly before building anything.
4. If it's small enough (new blog post, new tool entry, new /dev category): skip the SDD, frick-frack it.
5. If it's large enough to change the architecture, add a new route, or touch the DB schema: it gets its own SDD section before it gets code.

"Could this break something that already works?" If yes — SDD first. If no — frick-frack.