DEV Community

Building Bug Graveyard (Next.js + Sanity) with Claude Code

Claude Code 719 messages September 28, 2026
by jashanpreet_kaur_917e774f
Building Bug Graveyard (Next.js + Sanity) with Claude Code claude-opus-5-5
You

I'm building "Bug Graveyard" for the DEV Sanity Challenge (Path 2: vibe-code something strange).
It's a site where developers bury bugs they fixed. Each bug gets a tombstone. If a bug comes back
(regression), it rises as a "zombie" linked to its previous grave.

Stack: Next.js (App Router, TypeScript, Tailwind) + Sanity with the Studio embedded at /studio.
Deploy on Vercel.

Don't write code yet. Give me a short phase-by-phase plan, the folder structure, and the Sanity
schema you propose. Keep it simple enough to finish in 5 days.

Agent
Agent

Your folder is empty, so this plan starts from scratch.

Phases (one per day)

Day 1: Skeleton, schema and a first deploy
- Run create-next-app (TypeScript, Tailwind, App Router), then npx sanity@latest init inside it. That command sets up the sanity/ folder, sanity.config.ts, the /studio route and the env vars for you.
- Add the bug schema and Studio previews. Add about 10 sample bugs, including one zombie chain three graves deep.
- Push to GitHub and deploy to Vercel. Add the Vercel domain to Sanity's CORS origins with credentials allowed.
- Done when: /studio works on the live URL. Deploying on day 1 catches env and CORS problems while they're cheap.

Day 2: Show the bugs on the site
- Write the GROQ queries: all graves (with whether each is a zombie or has risen), and one grave by slug (with its past lives and any zombies that rose from it).
- Build the home grid and the grave page with plain tombstones.
- Use next-sanity's defineLive so edits in the Studio show up without a redeploy.
- Done when: you can click from a zombie to its previous grave and back.

Day 3: Make it strange (the part judges see)
- Build one Tombstone component with 3 looks: resting, disturbed (the bug rose, so the grave is empty) and zombie.
- Add a lineage view that shows the chain of past lives as stacked graves.
- Add atmosphere: night colours, fog, a grass line, an icon per species and a filter by species.
- Done when: it's worth a screenshot.

Day 4: Let developers bury bugs
- Add a /bury form. A server action uses a write token to create the bug as a draft, and you publish it in the Studio. That gives you moderation without writing any extra code.
- Add an optional "This bug came back" picker that sets previousLife.
- Add a "Press F to pay respects" button that increments a counter (patch().inc()).
- Add a hidden honeypot field and basic validation against spam.
- Done when: a stranger can submit a bug and it goes live once you publish it.

Day 5: Polish and ship
- Make an OG image per grave with next/og, a 404 page that says "This grave is empty", mobile fixes and metadata.
- Write the README and the DEV post with screenshots or a GIF.
- Keep half the day as a buffer.

If you fall behind, cut in this order: OG images, then the respects counter, then the species filter. Don't cut zombie linking, because it's the whole idea.

Folder structure

bug-graveyard/
├── app/
│   ├── layout.tsx                   # root <html>/<body> only
│   ├── (site)/                      # group so /studio doesn't get the graveyard layout
│   │   ├── layout.tsx               # fog, nav, fonts
│   │   ├── page.tsx                 # the graveyard grid
│   │   ├── grave/[slug]/page.tsx    # one grave + lineage + zombies that rose from it
│   │   ├── grave/[slug]/opengraph-image.tsx
│   │   └── bury/page.tsx            # public burial form
│   ├── actions.ts                   # server actions: buryBug, payRespects
│   └── studio/[[...tool]]/page.tsx  # embedded Studio
├── components/
│   ├── Tombstone.tsx                # variants: resting | disturbed | zombie
│   ├── GraveyardGrid.tsx
│   ├── Lineage.tsx
│   └── BuryForm.tsx
├── sanity/
│   ├── env.ts
│   ├── lib/client.ts
│   ├── lib/live.ts                  # defineLive
│   ├── lib/queries.ts               # all GROQ in one place
│   ├── schemaTypes/index.ts
│   ├── schemaTypes/bug.ts
│   └── structure.ts                 # sidebar: All / Resting / Zombies / Pending burials
├── sanity.config.ts
├── sanity.cli.ts
└── .env.local                       # PROJECT_ID, DATASET, READ_TOKEN, WRITE_TOKEN (server-only)

Sanity schema: one document type, bug

A zombie is still a bug that gets fixed and buried again, so it needs the same fields. Using one type with a self-reference means zombies of zombies work automatically, and you only need one query and one component.

Field Type Notes
title string, required The bug's name on the stone
slug slug (from title), required Used in the URL
epitaph string, ≤ 80 chars, required The line carved on the stone: "Here lies i <= arr.length"
species string from a list off-by-one, null/undefined, race condition, timezone, cache, CSS, dependency, works-on-my-machine, other. Decides the icon
causeOfDeath string The fix, in one line
obituary Portable Text, optional The full story
stack array of strings (tags) Languages and frameworks
bornAt date, optional When the bug was introduced
diedAt date, required When it was fixed. Must be on or after bornAt
buriedBy string Name or @github handle. No separate author type, to save time
fixUrl url Link to the PR or commit
previousLife reference → bug If set, this bug is a zombie. The reference picker hides the bug itself
respects number, read-only, starts at 0 Counts "Press F" clicks

States are worked out in GROQ, not stored:
- Zombie: defined(previousLife)
- Disturbed grave: another bug's previousLife points to this one, i.e. count(*[previousLife._ref == ^._id]) > 0
- A bug can be both: a zombie that was fixed again and then rose again.

GROQ can't follow references recursively. The grave query will fetch previousLife-> three levels deep and show "…and older lives" beyond that, which is plenty for a demo.

Decisions I made that you may want to change: one type instead of a separate zombie type, a plain-string buriedBy, and public submissions landing as drafts you have to publish. Changing any of them later is easy.

Separately, your Gmail, Google Calendar and Google Drive connectors need authorizing in your claude.ai connector settings before I can use them. This plan doesn't need them.

You

Set up the project now:
1. Create the Next.js app in this folder (App Router, TypeScript, Tailwind, ESLint).
2. Initialise Sanity inside it with the Studio embedded at /studio (use the official
next-sanity setup). Guide me through the interactive steps: I'll log in and create a new
project called "bug-graveyard" with the "production" dataset.
3. Put the project ID and dataset in .env.local and make sure .env.local is gitignored.
4. Tell me how to add http://localhost:3000 as a CORS origin in sanity.io/manage.
5. Initialise git and make the first commit.
Explain each file you create in one line.

Agent

I'll start by checking your toolchain, then create the Next.js app.

Agent
Agent
Agent

Node 24, npm 11 and git are all ready, and your git identity is set. Next I'll check the flags create-next-app accepts so it runs without prompts.

Agent
Agent
Agent
Agent

The Next.js app is in place, and .gitignore already covers .env*. Next I'll check the current sanity init options so my prompt-by-prompt guide matches your CLI version.

Agent
Agent
Agent

I've done step 1. Step 2 needs you in a terminal, because signing in to Sanity opens a browser. Once you've run it, I'll do steps 3 and 5.

Step 1: Next.js app (done)

I made it with Next 16.3.6, React 19.2, TypeScript, Tailwind v4, ESLint and the App Router. I skipped create-next-app's own git setup, so the first commit can include the Sanity files too.

File What it is
package.json Lists the dependencies and the dev, build, start and lint scripts
package-lock.json Pins the exact installed versions
next.config.ts Next.js settings (empty for now)
tsconfig.json TypeScript settings, including the @/* import shortcut
next-env.d.ts Type references Next.js generates; ignored by git
eslint.config.mjs Linting rules from eslint-config-next
postcss.config.mjs Connects Tailwind v4 to the CSS build
app/layout.tsx Root layout: <html>, <body> and fonts
app/page.tsx Starter home page; the graveyard will replace it
app/globals.css Global styles; imports Tailwind
app/favicon.ico Default tab icon
public/ *.svg Starter logos; we'll delete them with the starter page
.gitignore Already ignores .env*, node_modules and .next
README.md The default readme
AGENTS.md Next 16's notes for coding agents; next dev adds it back if it's removed
CLAUDE.md One line that points Claude Code to AGENTS.md

Step 2: Your turn, run sanity init

Open the VS Code terminal (Ctrl+`) in the bug-graveyard folder and run:

npx sanity@latest init

Answer the prompts like this. The wording may differ slightly in CLI v6, and some prompts may not appear.

Prompt Answer
Login provider Choose any. A browser tab opens; log in, then come back to the terminal
Create new project / select existing Create new project
Project name bug-graveyard
Organization (if asked) Your personal organization
Use the default dataset configuration? Yes. This creates a public dataset called production. Anyone can read published bugs, but drafts and writes still need a token, which suits a public graveyard
Add configuration files … in this Next.js folder? Yes
Use TypeScript? Yes
Embedded Sanity Studio? Yes
Route for the Studio /studio
Project template Clean project with no predefined schema types
Add project ID and dataset to .env.local? Yes (this covers step 3)
Package manager npm
AI editor / MCP / agent skills No for now. The skills option installs globally on your machine, so it's worth deciding on separately
Initialize git / commit No, so the first commit has everything

Step 4: Add localhost:3000 as a CORS origin

  1. Go to https://www.sanity.io/manage and open bug-graveyard.
  2. Open the API tab, find CORS origins and click Add CORS origin.
  3. Enter http://localhost:3000 and tick "Allow credentials". The embedded Studio sends your login with each request, so without this /studio fails with a CORS error.
  4. Save. Your Vercel URL will need the same setup later.

init may have added this origin already, so check the list first. You can also do it from the terminal:

npx sanity@latest cors add http://localhost:3000 --credentials

When you're done

Reply "done". I'll then:
- check that .env.local has NEXT_PUBLIC_SANITY_PROJECT_ID and NEXT_PUBLIC_SANITY_DATASET, and confirm git ignores it
- run a build and check that /studio loads
- explain in one line each file Sanity added
- run git init -b main and make the first commit

You

can uh do this ny yourself

Agent

I can do almost all of it. The one thing I can't do is sign in to Sanity as you. I'll start the login, a browser tab will open, and you just approve it there. First I'll check how the login command behaves when it isn't run from an interactive terminal.

Agent
Agent

Which account do you sign in to Sanity with? The login needs to use the matching provider.

Agent
Agent

I'm starting the Google login now. A browser tab should open; approve it there and I'll carry on once it finishes.

Agent
Agent
Agent

A browser tab should now be open on the Google sign-in page. Choose your Google account and approve the login. When it finishes, I'll pick up automatically.

If no tab opened, use this link: https://api.sanity.io/v1/auth/login/google?type=token&label=Jashanpreets-MacBook-Air+%2F+MacOS&origin=http%3A%2F%2Flocalhost%3A51647%2Fcallback

Agent

You're logged in. Next I need your Sanity organization ID, because the CLI requires one to create a project without prompts.

Agent
Agent
Agent

This is a new Sanity account with no organization yet, so one has to be created first. I'll check how.

Agent
Agent

I'll create a personal organization named after you. You can rename it later.

Agent
Agent

Organization created (o0zfmcbiy). Now I'll run sanity init with every answer passed as a flag, the same answers I listed earlier.

Agent
Agent

The Sanity project is created (ID rzjmw6lg), .env.local is written and localhost:3000 is already in CORS. Next I'll check the files it added and whether that CORS entry allows credentials.

Agent
Agent
Agent
Agent

The files look right. cors list doesn't show whether credentials are allowed, so I'll query the API directly.

Agent
Agent
Agent

Both localhost origins allow credentials, so step 4 is done. Next I'll run a production build and check the audit warnings.

Agent
Agent
Agent
Agent

/studio returns 200. Now step 5: I'll set up git and confirm .env.local is ignored before committing anything.

Agent
Agent

.env.local is ignored and nothing unwanted is staged, so I'll commit.

Agent
Agent

All five steps are done. The site builds, /studio loads, and the first commit (f59e00d) is on main. I haven't opened /studio in a browser; it will ask you to sign in with the same Google account.

What I did in Sanity:
- Logged in with your Google account ([REDACTED]).
- Created an organization called Jashanpreet Kaur (o0zfmcbiy). New Sanity accounts don't have one, and a project can't be created without it. You can rename it in sanity.io/manage.
- Created the bug-graveyard project (rzjmw6lg) with a public production dataset.
- sanity init added http://localhost:3000 (and :3333) as CORS origins with "Allow credentials" on. I checked this through the API, so step 4 needs nothing from you. You'll add your Vercel URL the same way later.

Files Sanity added:

File What it does
app/studio/[[...tool]]/page.tsx Shows the Studio at /studio and every page under it
sanity.config.ts Studio settings: /studio path, project, dataset, schema, and the Structure and Vision (GROQ query playground) plugins
sanity.cli.ts Tells npx sanity … commands which project and dataset to use
sanity/env.ts Reads the project ID, dataset and API version, and stops with an error if one is missing
sanity/lib/client.ts The client the site uses to query content
sanity/lib/image.ts urlFor(), which builds image URLs
sanity/lib/live.ts sanityFetch and <SanityLive />, so Studio edits show on the site without a redeploy
sanity/schemaTypes/index.ts The list of content types; empty until we add bug
sanity/structure.ts The Studio sidebar layout; still the default
.env.local NEXT_PUBLIC_SANITY_PROJECT_ID="rzjmw6lg" and NEXT_PUBLIC_SANITY_DATASET="production". Git ignores it, and I checked it isn't in the commit

Sanity also added sanity, next-sanity, @sanity/vision, @sanity/image-url and styled-components to package.json. The CLI chose sanity 5.31 rather than the newest 6.x, and I kept that.

One warning: npm audit reports 9 vulnerabilities. All of them come from packages Sanity's command-line tool depends on, not from code the site sends to browsers. The only fix npm offers is downgrading to older major versions of sanity and next-sanity, so I left them alone.

To see it, run npm run dev and open http://localhost:3000/studio. The Studio will be empty until we add the bug schema, which is the next part of Day 1. Nothing has been pushed anywhere; there's no GitHub remote yet.

You

Create a NOTES.md file in the project root for my DEV challenge build log.
From now on, at the end of every phase, automatically append an entry with:
- Phase name and date
- What I asked for (my prompt, summarized)
- What you built (files changed)
- Anything that broke or went wrong, and how we fixed it
- Anything surprising or interesting about Sanity I should mention in my write-up

Also add this instruction to CLAUDE.md so you remember it in future sessions.
Start by adding an entry for Phase 1 (the Next.js + Sanity setup we just did).

Agent

I'll check the local date for the entry. The setup ran across midnight, so the timestamps could disagree.

Agent
Agent
Agent
Agent

Written for: you. NOTES.md is your own build log for writing the DEV post, not the post itself.

I created NOTES.md with the Phase 1 entry and added the build-log rule to CLAUDE.md. The @AGENTS.md line at the top of CLAUDE.md is still there, so the Next.js notes keep loading.

The Phase 1 entry has four parts:
- What I asked for: the plan request, the setup request, and your switch to "do it yourself".
- What was built: every file, one line each, plus the Sanity account changes (organization, project, dataset, CORS).
- What went wrong: five setup problems and how each was solved. The build itself never broke. The audit warnings are logged as deliberately not fixed.
- Sanity notes: eight points for the write-up. The strongest are that sanity init detects Next.js and does the embedding itself, and that the whole setup can run without prompts except the browser login. One point is still an open question: why init installed sanity@5 when npm's newest is 6.x.

How "automatically" will work: it's an instruction in CLAUDE.md that every future session reads. Nothing in Claude Code fires on its own when a phase ends, so it depends on me noticing that a phase is done. If I seem unsure, I'll ask first. You can also say "wrap up this phase" to make me write the entry.

Not done yet:
- NOTES.md and CLAUDE.md aren't committed. Tell me if you want them committed now or with the next phase.
- The 5-day plan only exists in this chat, so a future session won't know what Day 2 or Day 3 means. Should I add it to the top of NOTES.md?

You

Phase 2: create the Sanity schema, following our plan.

Files: sanity/schemaTypes/language.ts, causeOfDeath.ts, bug.ts, and register them in index.ts.

  • language: name (string, required), color (string, hex, validated)
  • causeOfDeath: title (string, required), description (text)
  • bug:
    • name (string, required), slug (from name, required)
    • language (reference → language), causeOfDeath (reference → causeOfDeath)
    • severity (string list: low | medium | critical)
    • epitaph (text, max 140 chars with validation)
    • killedBy (string), hoursToKill (number, min 0)
    • bornAt (date), fixMergedAt (date, readOnly), buriedAt (date, readOnly)
    • status (string list: suspected-dead | fix-merged | buried | zombie, default suspected-dead)
    • previousLife (reference → bug, optional; only relevant for zombies)
    • timesResurrected (number, default 0, readOnly)

Add helpful descriptions on every field, group fields sensibly (e.g. "The Bug", "The Death",
"Afterlife"), and a preview showing name as title and "status · language" as subtitle,
with an emoji per status (🪦 buried, 🧟 zombie, 💀 suspected-dead, 🩹 fix-merged).

Then write scripts/seed.ts that creates 5 languages (JavaScript, Python, TypeScript,
Java, C++ with brand colours) and 6 causes of death (Off-by-one, Null reference,
Race condition, Timezone, Infinite loop, Works on my machine). Tell me how to run it
(I may need a Sanity API token with write access; explain how to create one safely and
keep it out of git).

Agent

Before writing anything I'll check a few Sanity APIs against the installed version: how sanity exec runs scripts, how tokens are created, and whether the getPublishedId helper is exported.

Agent
Agent
Agent
Agent

That output was too noisy. I'll check the exports more precisely.

Agent
Agent
Agent

Both helpers exist in the installed Sanity version. Next I'll write the three schema types.

Agent
Agent
Agent
Agent
Agent
Agent

Now the seed script. It uses fixed document IDs and createIfNotExists, so you can re-run it without creating duplicates or overwriting Studio edits.

Agent
Agent
Agent

Next I'll verify: type-check, lint, Sanity's own schema validation, and a production build.

Agent
Agent

The type-checker rejected the seed script because TypeScript read the language and cause-of-death documents as two incompatible shapes. I'll give the list one shared type.

Agent
Agent
Agent
Agent
Agent
Agent
Agent

The schema and seed script are written. Type-check, lint, Sanity's schema validation (0 errors, 0 warnings) and the production build all pass. I haven't written anything to your dataset yet, and I haven't opened the Studio in a browser.

What I built

File What it does
sanity/schemaTypes/language.ts Name (required) and a hex colour, rejected if it isn't like #3178C6
sanity/schemaTypes/causeOfDeath.ts Title (required) and description
sanity/schemaTypes/bug.ts The bug, with every field you listed, a description on each, the three tabs, and the list preview
sanity/schemaTypes/index.ts Registers the three types
scripts/seed.ts Creates the 5 languages and 6 causes of death

Choices I made in bug:
- Status appears in both "The Death" and "Afterlife", because it covers both. Choosing it shows the emoji: 💀 Suspected dead, 🩹 Fix merged, 🪦 Buried, 🧟 Zombie.
- "Previous life" is hidden unless the status is Zombie. Its picker leaves out the bug itself, so a bug can't be its own previous life.
- fixMergedAt, buriedAt and timesResurrected will stay empty for now. They're read-only, so you can't edit them in the Studio, and nothing fills them in yet. Their descriptions say "filled in automatically", which only becomes true once a later phase adds that automation. If you want to type them in by hand until then, drop readOnly.
- The emoji in the list preview is unchecked. I couldn't sign in to the Studio to look at it.

Running the seed: no API token needed

npx sanity exec scripts/seed.ts --with-user-token

--with-user-token borrows the login you already have from sanity login. That login is stored in your home folder, not in this project. The script uses fixed IDs like language-typescript and only creates documents that don't exist yet, so running it twice is safe and won't overwrite anything you change in the Studio. It prints "created" or "skipped (exists)" for each document. I checked that without the flag it stops with a message saying exactly that, before writing anything.

Creating a write token safely (you'll need one on Day 4)

The public "bury a bug" form will run on the server without your login, so it needs its own token:

  1. Create it in sanity.io/manage → bug-graveyard → API → Tokens → Add API token, with the Editor role. Or run npx sanity tokens add "bug-graveyard server" --role=editor in your own terminal. It's shown only once.
  2. Add it to .env.local as SANITY_API_WRITE_TOKEN=.... Don't use the NEXT_PUBLIC_ prefix, because Next.js sends anything with that prefix to the browser.
  3. It stays out of git: .gitignore covers .env*, and I checked that git ignores .env.local. Don't paste it into this chat or into any code file.
  4. On Vercel, add it under Project → Settings → Environment Variables and mark it Sensitive.
  5. Use a separate token for each job (local, Vercel), so a leak means revoking one. If one leaks, delete it on the same Tokens page and create a new one.

I added the Phase 2 entry to NOTES.md. It says the seed hasn't been run yet; tell me when you've run it and I'll update the entry. Nothing is committed yet, including the Phase 1 notes.

You

Please do all of this yourself:

  1. Run the seed: npx sanity exec scripts/seed.ts --with-user-token
  2. Write scripts/seed-test-bugs.ts that creates 3 PUBLISHED test bugs (use fixed IDs starting with "test-bug-" so I can delete them later, and make it safe to re-run):
    • "NullPointerException in checkout", status buried, language TypeScript, cause Null reference, epitaph "It pointed to nothing, and so do we."
    • "Timezone bug in scheduler", status buried, language Python, cause Timezone, epitaph "Died at 00:00 UTC. Still alive in IST."
    • "Timezone bug in scheduler (Zombie #1)", status zombie, previousLife → the timezone bug, timesResurrected 1, epitaph "You can't kill what lives in every timezone." Fill in sensible bornAt, fixMergedAt, buriedAt, killedBy ("Jashanpreet") and hoursToKill.
  3. Run it, then verify with a GROQ query that all 3 exist, the references resolve (language, causeOfDeath, previousLife), and the zombie points to the right grave.
  4. Update the Phase 2 entry in NOTES.md (the seed has now run), then commit Phase 1 + Phase 2.

Tell me when it's done so I can check the Studio in my browser.

Agent

I'll start by running the seed.

Agent
Agent
Agent
Agent

I swapped your straight apostrophe in the zombie's epitaph for a curly one. I'll change it back to exactly what you wrote.

Agent
Agent
Agent

Type-check and lint pass. Now I'll run it, then run it a second time to confirm re-running is safe.

Agent
Agent

The first run created all 3 and the second skipped all 3. Now the GROQ check: I'll follow every reference and run explicit pass/fail checks.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

NOTES.md is unchanged since I wrote it. I'll update each section of the Phase 2 entry.

Agent
Agent
Agent
Agent
Agent

Now the commit. I'll check exactly what will go in.

Agent
Agent
Agent

All four steps are done and committed as 9eeccd8 on main. Nothing was pushed, because there's no GitHub remote yet. You can check the Studio now.

1. Seed: you'd already run it; the 11 documents were created at 00:38. My run printed "skipped (exists)" for all 11, so running it again is safe.

2. Test bugs: scripts/seed-test-bugs.ts creates the 3 published bugs. I ran it twice: the first run created them and the second skipped all 3. To delete them later, run:

npx sanity exec scripts/seed-test-bugs.ts --with-user-token -- --delete

This removes the zombie and its grave together, because Sanity won't delete a grave while a zombie still points to it. It also removes any Studio drafts of them.

Two choices you might want to change:
- I left the zombie's fix date, burial date, killer and hours empty. Its status is Zombie, so it hasn't been fixed again yet. Filling them in would contradict that.
- I set severity even though you didn't ask: critical for the checkout bug and the zombie, medium for the original timezone bug.

3. The GROQ check found a bug in my script, now fixed. My first query used path("test-bug-*") and found nothing, because that wildcard only matches whole dot-separated parts of an ID, not the start of one. The --delete option used the same pattern, so it would have deleted nothing without any error. I switched to string::startsWith. Then I tested --delete for real (3 deleted, then "nothing to delete") and recreated the bugs. After the fix, every check passes:
- 3 bugs, 0 drafts.
- Language, cause of death and previous life all resolve for every bug.
- The zombie's previous life is test-bug-timezone-scheduler, and querying from that grave finds the zombie.
- A plain curl to the public API with no token returns all 3. The site will read them the same way.

4. Notes and commit: the Phase 2 entry in NOTES.md now covers the seed run, the path() problem, and five more Sanity notes. The main one: readOnly only affects the Studio, and API writes ignore it.

In your browser: run npm run dev, open http://localhost:3000/studio, and sign in with Google. You should see:
- Bug list: 🪦 two buried bugs and 🧟 one zombie, each with a subtitle like "Buried · Python". I haven't seen this preview rendered yet, so it's the thing to check first.
- The zombie: the Afterlife tab shows Previous life → Timezone bug in scheduler.
- A buried bug: the Previous life field is hidden.
- The dates and resurrection count are greyed out and can't be edited.

You

Phase 3: build the public graveyard homepage.

  • Put the site pages in an app/(site) route group with its own layout, so /studio doesn't get the graveyard styling.
  • Write GROQ queries in sanity/lib/queries.ts: all bugs with language->{name,color}, causeOfDeath->{title}, and whether each bug has been "disturbed" (another bug's previousLife points to it).
  • Use sanityFetch + <SanityLive /> so Studio edits appear without a redeploy.
  • Homepage "/": a dark spooky graveyard (night gradient, subtle fog, grass line at the bottom). Each bug is a Tombstone card (rounded top) showing name, born–died dates, epitaph, and a language colour badge. Three looks: resting (buried), disturbed (the grave is empty because the bug rose), zombie (cracked with a green glow).
  • Filters at the top by language and cause of death.
  • Responsive: 1 column on mobile, 3–4 on desktop. A gothic display font for titles via next/font, readable body text.
  • Make Tombstone.tsx a reusable component; we'll reuse it inside Studio later. Run the build and lint at the end, add the Phase 3 entry to NOTES.md, and commit.
Agent

This phase is mostly Next.js code, and AGENTS.md says Next 16 differs from what I know and to read the bundled docs first. I'll do that, and also read the next-sanity 13 docs for sanityFetch/SanityLive.

Agent
Agent
Agent
Agent

The README only links out, so I'll read the defineLive type definitions directly. The live/cache-life export hints that v13 depends on Next's Cache Components.

Agent
Agent

The live.ts that sanity init generated uses the default mode, without Cache Components, which our Next config also doesn't enable. Next I'll check what sanityFetch and <SanityLive /> accept.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

The docs check is done. Next I'll write the queries and set up TypeGen.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Now the layouts and styles. The root layout shrinks to a bare <html>/<body>, and everything graveyard-specific (Tailwind, fonts, scenery, <SanityLive />) moves into the (site) layout.

Agent
Agent

The moves worked. The ls error only happened because public/ is now empty and git removed the folder. Next I'll write the styles and both layouts.

Agent
Agent
Agent
Agent

I used a different import-brace style in the site layout than in the new components, so I'll make it consistent.

Agent
Agent

Now the homepage itself.

Agent
Agent

All the files are written. Next: type-check and lint.

Agent
Agent

The only error is in .next/types, which is left over from the last build and still points to the old app/page.tsx. I'll regenerate Next's route types and check again.

Agent
Agent

Type-check and lint pass, which also shows sanityFetch is picking up the generated query types. Now the production build.

Agent
Agent
Agent
Agent
Agent
Agent
Agent

Now a visual check. I'll look for a headless browser to take screenshots at desktop and phone widths.

Agent
Agent

Chrome is installed. I'll rebuild with the fix and take screenshots using a throwaway Chrome profile, so your own browser data isn't touched.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Now I'll rebuild and retake both screenshots. This time Chrome gets a fixed time limit instead of waiting for the page to go idle, and each run gets its own profile.

Agent
Agent

While that runs, I'll check how sanityFetch caches without Cache Components, since that decides whether a Studio edit really shows up without a redeploy.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

The mobile screenshot is ready. Next I'll close its Chrome so the empty-state screenshot can run, then check the mobile layout.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

parseTags checks that every tag starts with sanity:, the same way the default action does. Before writing the action, I'll confirm updateTag's rules in the Next 16 docs.

Agent
Agent

That confirms it: updateTag expires the cache at once, and the next request waits for fresh data. I'll write the action and use it in both <SanityLive /> places.

Agent
Agent
Agent

My sed also changed the <SanityLive /> mention inside the comment. I'll put the comment back.

Agent
Agent
Agent
Agent
Agent

sips cropped from the middle of the image, not the top. I'll crop again from the top.

Agent
Agent
Agent

sips still isn't cropping from the top. The full screenshot is small enough to view as it is.

Agent
Agent
Agent

Everything passes: lint, a fresh build, and TypeGen reports no changes. Now the Phase 3 entry for NOTES.md.

Agent
Agent

Now the commit.

Agent
Agent

Phase 3 is built, verified and committed as d8fe434. Your npm run dev on port 3000 was left running, so refresh http://localhost:3000 to see it. I moved files into the route group, so if dev shows a stale error, restart it.

What's there:
- The site lives in its own route group. app/(site)/layout.tsx holds the fonts, Tailwind, sky, moon, fog, grass and header. The root app/layout.tsx is now a bare <html>/<body>. /studio loads 0 stylesheets from the site.
- Tombstone.tsx shows all three looks: resting (grey), disturbed (tilted, open hole, crossed-out R.I.P., "The grave is empty") and zombie (green glow, cracks, "Rose from …"). It's styled with a CSS module rather than Tailwind so it will still look right inside the Studio later.
- Filters are links that set ?language= and ?cause=. Each filtered view has its own URL, and they work without JavaScript. Options with no bugs are hidden, and a filter with no matches shows an empty state.
- Query results are typed automatically. npm run typegen generates sanity/types.ts from the schema and queries, so sanityFetch needs no hand-written types.

One thing you'd have hit after deploying: live updates didn't work in production as set up. I tested against a production build, because npm run dev hides both problems:
1. Publishing from /studio didn't reach the site. The site's cache is only cleared by a page that has <SanityLive />, and the Studio didn't have one. I added it.
2. An open site tab stayed one change behind. next-sanity's default refresh hands the tab the old page once more. I replaced it with an action that expires the cache immediately.

After both fixes, the homepage showed a newly published bug within 1.8 seconds with only the Studio open. An open site tab updated within 3 seconds without reloading.

Still open: an edit made while neither the site nor the Studio is open, such as from a seed script, waits for the next change someone sees live. Fixing that needs a Sanity webhook, which is best added once the site is on Vercel.

Also checked:
- Build, lint, type-check, and TypeGen reporting no changes.
- The page HTML: 3 graves with the right looks, dates formatted in UTC, and every filter combination.
- Screenshots at desktop and at a real 390px phone width: one column, no horizontal overflow. They caught a crack running through "Zombie" and the moon covering the tagline on phones; both are fixed.
- Not tested: a real phone, Safari, or a screen reader.

Things to know:
- I deleted the unused starter logos in public/.
- Never use <Link> from the site to /studio; use a plain <a>. Next.js doesn't unload the site's CSS on client-side navigation, so it would leak into the Studio.
- The Phase 3 entry in NOTES.md covers all of the above.

You

Phase 4: build the single grave page at /grave/slug.

  • GROQ query by slug: all bug fields, language, causeOfDeath, previousLife-> up to 3 levels deep (name, slug, epitaph, dates, status), plus all zombies that rose FROM this bug.
  • Big Tombstone at the top (reuse the component), then details: cause of death, hours to kill, severity, killed by, born / fix merged / buried dates.
  • "Past lives" section: the chain of previous graves as stacked mini-tombstones, oldest first, each linking to its own page. Show "…and older lives" beyond 3 levels.
  • "Risen from this grave" section if zombies came from it, linking to them.
  • Make every tombstone on the homepage link here (normal Next <Link> is fine within the site).
  • generateStaticParams + generateMetadata (title "RIP <name>", description = epitaph).
  • A custom not-found for unknown slugs: "This grave is empty." Use sanityFetch so live updates keep working. Build, lint, type-check, then add the Phase 4 entry to NOTES.md and commit.
Agent

Phase 4. First the Next 16 docs for generateStaticParams, generateMetadata, notFound() and not-found.tsx, since AGENTS.md says Next 16 may differ from what I know.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Next, the Tombstone gets three new props: size (mini, regular or large), href (makes the whole stone a link) and headingLevel (so the grave page can use the bug's name as its <h1>).

Agent
Agent
Agent
Agent
Agent
Agent
Agent

border-radius: inherit on the ::after does nothing, because it inherits from the inline link, not the stone. I'll remove it.

Agent
Agent
Agent

That comment sits above PAST_LIFE but describes the query. I'll fix it, then run TypeGen to see whether it can follow the ${PAST_LIFE} interpolation.

Agent
Agent
Agent

TypeGen followed the interpolation and produced full nested types for all three past-life levels, so the shared field list costs nothing in type safety. Now the grave page and its not-found page.

Agent
Agent
Agent
Agent

A blank line went missing after the imports. I'll add it back, then type-check and lint.

Agent
Agent
Agent

It doesn't accept newline-delimited JSON. I'll try a JSON array.

Agent
Agent

The chain is linked 1 ← 2 ← 3 ← 4 ← 5. Next I'll build and check the grave pages are prerendered.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Still working on Phase 4. The grave page works, and I'm fixing what the checks found: the not-found page's title, a 16px overflow on phones, and a cache problem.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Still one failure, even after clearing the fetch cache and restarting. The publish → page → delete → 404 cycle itself works, within 2.7 seconds each way. I'll see what's on disk for that slug.

Agent
Agent
Agent
Agent
Agent
Agent

The build prerenders exactly the 3 real graves, and the stale test pages are gone. I'll check the aligned past-lives row.

Agent
Agent
Agent
Agent

Phase 4 is built, verified and committed as 1f2ba81. Your dev server should show it: try http://localhost:3000/grave/timezone-bug-in-scheduler-zombie-1, or click any tombstone on the homepage.

What's there:
- Grave page: app/(site)/grave/[slug]/page.tsx shows a big tombstone, a "Death certificate" with the details, "Past lives" as small linked stones (oldest first, with "…and older lives" past 3 levels), and "Risen from this grave".
- For a zombie, the death fields read "Nobody yet" and "Not yet" rather than going blank.
- All 3 graves are prerendered at build time.
- The title is "RIP <name>" and the description is the epitaph.
- An unknown slug gets "This grave is empty." with a real 404 status.
- Tombstone.tsx gained size (mini/regular/large), href (the whole stone becomes a link, lifts on hover and gets a green focus ring) and headingLevel.
- Homepage: every stone now links to its grave.
- Headings: the "Bug Graveyard" title is no longer an <h1>, so each page's own subject can be its <h1>.

How I checked it: type-check, lint and build all pass. I briefly published a five-grave zombie chain and ran 27 checks against a production build, covering links both ways, past-lives order, the 404, and screenshots at desktop and 390px. All of them passed except one, which turned out to be leftover cache from a crashed earlier run (last bullet below). The chain has been deleted again.

Fixed along the way: the grave page was 16px too wide on phones, because the big stone's earth mound stuck out. The past-lives arrows also didn't line up with the stones.

Things to know:
- Live updates reach the prerendered pages. With /studio open, an edit showed up in 2.0s, a new slug went from 404 to a page in 2.6s, and a deleted grave became a 404.
- The 404 page's <head> says "Bug Graveyard". On a 404, Next.js delivers the page's own title later in the page load. A browser does end up showing "This grave is empty", and 404s aren't indexed anyway, so I left it.
- A locally running production server can serve stale pages after a restart. next start saves pages as files, but its record of which ones are out of date is lost on restart. Running next build again clears it. This doesn't affect npm run dev, and I don't expect it on Vercel.
- Still open from Phase 3: changes made while neither the site nor the Studio is open need a Sanity webhook, which is best added at the Vercel deploy.
- Your data only goes one life deep, so "…and older lives" won't appear in the demo. Want me to add a permanent deeper zombie chain to scripts/seed-test-bugs.ts?

The Phase 4 entry in NOTES.md has the details, including the cache problems.

You

Deploy time. Help me get the site live on Vercel now (I'll finish features after).

  1. Create a public GitHub repo "bug-graveyard" and push main. If the gh CLI is installed and logged in, do it yourself; otherwise give me exact steps.
  2. Deploy to Vercel: use the Vercel CLI if available (I'll approve the login in the browser), otherwise give me click-by-click steps for importing the GitHub repo. Tell me exactly which environment variables to set on Vercel.
  3. Add the Vercel production URL as a Sanity CORS origin with credentials allowed.
  4. Set up the Sanity webhook you mentioned so content changes made while nobody has the site or Studio open still refresh the live site. Keep any secret out of git.
  5. Verify on the live URL: homepage, a grave page, the 404, /studio login, and that publishing a change in the live Studio shows up on the live site.
  6. Add a Phase "First deploy" entry to NOTES.md and commit.
Agent

This touches your GitHub account, Vercel and Sanity, and you've asked me to do it, so I'll go ahead. First I'll check which CLIs are installed and signed in.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

parseBody(request, secret) checks the signature and waits for Sanity's data to be consistent before answering. Now I'll write the tag wrapper and the route.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

The test script lives outside the project, so Node couldn't find @sanity/webhook. The test never ran and nothing was published. I'll resolve the package from the project folder instead.

Agent
Agent
Agent

Vercel is still waiting for your approval. Meanwhile I'll commit the webhook code, so the first push and deploy include it.

Agent
Agent

I'm waiting on you for two things. The webhook code is ready and committed (f05f0da) and was tested locally against a production build.

1. Approve the Vercel login: https://vercel.com/oauth/device?user_code=[REDACTED] (code [REDACTED]). The CLI is still waiting, and I'll carry on as soon as you approve.

2. Create the GitHub repo:
1. Go to https://github.com/new.
2. Set Repository name to bug-graveyard and choose Public.
3. Leave README, .gitignore and license unticked.
4. Click Create repository, then reply with its URL.

Once I have both, I'll:
- push main;
- create the Vercel project and set its three environment variables:
- NEXT_PUBLIC_SANITY_PROJECT_ID = rzjmw6lg
- NEXT_PUBLIC_SANITY_DATASET = production
- SANITY_REVALIDATE_SECRET = the secret now in your .env.local (I'll pipe it in; it won't be printed);
- deploy;
- add the production URL to Sanity's CORS origins with credentials allowed;
- create the Sanity webhook;
- check everything on the live site.

What's already done:
- Webhook route: app/api/revalidate/route.ts accepts only requests signed with that secret, then immediately expires a sanity-content tag. sanity/lib/live.ts now adds that tag to every sanityFetch, so future pages get it automatically.
- Tested with nothing open in a browser: a publish left the homepage stale, an unsigned request got 401, a signed one got 200, and the next page load showed the change.
- The secret is only in .env.local, which git ignores.

When you push, your commits will show your git email, [REDACTED]. If GitHub refuses the push because of your email privacy setting, I'll tell you what to change.

You

do this by yourself

Agent

I'll handle the GitHub side myself, using the GitHub login already saved in your keychain: I'll read the token into memory only, never print it, and use it only with github.com. For Vercel, the one step I can't do for you is approving the login, because only you can sign in to your account. I'll open the approval page in your browser, and then it's one click. First, where the Vercel login stands.

Agent
Agent

The login is still waiting, so I'll open the approval page in your default browser now.

Agent
Agent

Next I'll check what the saved GitHub token is allowed to do. The script prints only the account name and the token's permission scopes, never the token itself.

Agent
Agent
Agent

Vercel is logged in as imt-2023036-3419, under the Hobby team "Jashanpreet kaur". Next I'll create the public GitHub repo (unless it already exists) and push main.

Agent
Agent

The repo is live at https://github.com/jashanpreet-k/bug-graveyard (public), and main is pushed. Next is the Vercel project. I'll check the CLI options for linking and environment variables first.

Agent
Agent
Agent
Agent
Agent
Agent

All the variables are intact. Next I'll check the options for vercel env add, especially how to pass a value and mark it sensitive.

Agent
Agent
Agent

The command printed nothing, and env ls shows no variables, so something failed quietly. I'll run the first one unfiltered to see the error.

Agent
Agent

That worked. The earlier calls apparently never ran properly inside my shell function. I'll add the other two one at a time and check each result.

Agent
Agent

All three are added. The env ls table was cut off by my tail, so I'll show the whole listing.

Agent
Agent
Agent
Agent

The build itself succeeded (same routes as locally), but Vercel then looked for a dist folder. The project wasn't created with the Next.js framework preset. I'll check what it was set to.

Agent
Agent
Agent
Agent

The deploy finished. Next I'll find its production URL (its aliases) and check whether it's actually live.

Agent
Agent
Agent
Agent
Agent
Agent

Sanity rejected it with "name is required", so the body probably wasn't sent as JSON. I'll retry with an explicit Content-Type: application/json header, using the same temporary-file handling.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Everything is staged correctly (the error only came from giving check-ignore -q two paths at once). I'll check each path separately, then commit and push.

Agent
Agent

The site is live at https://bug-graveyard.vercel.app, and the code is public at https://github.com/jashanpreet-k/bug-graveyard. Everything is committed and pushed (afae328).

What I did:
- GitHub: gh isn't installed, so I created the repo through GitHub's API. I used the GitHub login already saved in your macOS keychain, without printing it, then pushed main and set the repo's website to the live URL.
- Vercel: created the bug-graveyard project and deployed from the CLI. The first deploy failed because Vercel had created the project with the wrong framework setting ("Other"). A small vercel.json now pins it to Next.js. .vercelignore keeps .env files out of uploads.
- Environment variables on Vercel:

| Variable | Value | Environments |
|---|---|---|
| NEXT_PUBLIC_SANITY_PROJECT_ID | rzjmw6lg | All |
| NEXT_PUBLIC_SANITY_DATASET | production | All |
| SANITY_REVALIDATE_SECRET | the secret in your .env.local | Production only, stored as a sensitive secret |

  • Sanity: added https://bug-graveyard.vercel.app as a CORS origin with credentials. Created the webhook "Refresh the live site", which fires when bugs, languages or causes of death change. The secret exists only in .env.local, on Vercel and in Sanity, never in git.

Checked on the live site, and everything passed:
- The homepage, a grave page, the zombie page with its past life, and the real 404 ("This grave is empty.").
- /studio shows Sanity's sign-in screen with no CORS errors.
- An unsigned call to the webhook address is refused.
- Publishing with nothing open: the new bug appeared on the live homepage 5.9 seconds later. Sanity's delivery log shows both webhook calls returned 200.
- Publishing with a tab open: the tab updated 3 seconds after the change, without reloading.

The test publishes came from the command line, which writes to Sanity exactly like the Studio. A test document was used and deleted.

Two things only you can do:
1. Try a real Studio publish. Sign in at https://bug-graveyard.vercel.app/studio with Google, edit an epitaph, publish, and watch the site.
2. Turn on automatic deploys from GitHub. Vercel refused to connect the repo because your Vercel account has no GitHub login connection. Add one in Vercel → Account Settings → Authentication → Connect GitHub, then tell me and I'll connect the repo. Until then, pushes don't deploy; ask me, or run npx vercel@60 deploy --prod.

Also worth knowing:
- Your git email is now public in the repo's history.
- The Vercel CLI added a VERCEL_OIDC_TOKEN to .env.local on its own. It's harmless and not committed.
- Preview deployments won't have a working Studio or live updates, because only the production URL is in Sanity's CORS list.
- The "First deploy" entry in NOTES.md covers all of this.

You

Phase 5: add custom Sanity document actions that model a bug's lifecycle, and fill in the
read-only fields (fixMergedAt, buriedAt, timesResurrected) that nothing sets yet.

Actions on the bug type (register them in sanity.config.ts via document.actions, keep the
default Publish/Delete etc.):

  1. "🩹 Mark fix merged": enabled only when status = suspected-dead. Sets status = fix-merged and fixMergedAt = today, then publishes.
  2. "🪦 Declare buried": enabled only when status = fix-merged AND at least 7 days have passed since fixMergedAt. When disabled, the label/title says how many days are left (e.g. "Can bury in 4 days"). Sets status = buried and buriedAt = today, then publishes.
  3. "🧟 Report resurrection": enabled when status = fix-merged or buried. Creates a NEW bug document: status = zombie, previousLife = this bug, timesResurrected = old + 1, name = "<original name> (Zombie #n)", same language/cause, a new unique slug, bornAt = today. Then open the new zombie in the Studio so I can write its epitaph. Show a confirm dialog first: "Are you sure? This bug will rise from its grave."

Rules:
- Use dates in UTC like the rest of the app.
- Handle drafts correctly (act on the published doc, don't leave stray drafts).
- A zombie can later go through the same lifecycle (fix merged → buried → resurrect again),
so zombies of zombies work.
- Make the 7-day rule a single constant so I can mention it in the write-up.

Test it end to end with temporary test bugs (delete them after), confirm the homepage and
grave pages update live, then run build/lint/type-check, add the Phase 5 entry to NOTES.md,
commit and deploy. Also explain in plain words how document actions work in Sanity, for my
write-up.

Agent

Phase 5 is Studio code, so I'll start with the document action API in the installed Sanity 5.31: the props an action receives, what it can return (label, disabled, title, confirm dialog), and how to register actions and open another document.

Agent
Agent
Agent
Agent
Agent
Agent
Agent

Still in Phase 5 prep. I've mapped the document action API and am checking how to sign in a headless Studio for tests. Next I'll write the lifecycle actions.

Agent
Agent
Agent
Agent
Agent
Agent

Before building on these helpers I'll check them quickly with Node's built-in TypeScript support, including a late-evening IST time that is still the previous day in UTC.

Agent
Agent
Agent
Agent
Agent
Agent

Type-check and lint are clean. Next I'll check Sanity's own schema validation, whether TypeGen still runs now that sanity/ contains Studio-only code, and the production build.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Everything is cleaned up, and the dataset is back to your 3 bugs. Next: the final build, lint and type-check.

Agent
Agent

All clean: type-check, lint, 0 schema errors and 0 warnings, and a passing build. I'll commit the code, deploy it to Vercel, and check the live Studio before writing the NOTES entry.

Agent
Agent

It's deployed and aliased to https://bug-graveyard.vercel.app. Next is a read-only check of the live Studio: it opens your three real bugs and reads their action menus without clicking anything.

Agent
Agent
Agent

The lifecycle actions are live in the Studio at https://bug-graveyard.vercel.app/studio (open a bug, then the "…" menu next to Publish). They're committed (4352c77, notes in f638d72), pushed and deployed. Type-check, lint, schema validation and the build all pass.

What's there: sanity/actions/lifecycle.tsx holds the three actions, and sanity/lib/lifecycle.ts holds BURIAL_WAIT_DAYS = 7 plus the date helpers. sanity.config.ts adds the actions right after Publish, for bugs only. Dates are UTC, so at 02:00 in India they record the previous day.

Decisions that go beyond your brief:
- "Mark fix merged" also works on a walking zombie. Otherwise a zombie could never start its own lifecycle.
- The actions change the published bug directly, in a single change that fails if someone else edited the bug first. No draft is ever created. They're disabled while you have unpublished edits, because your draft would later overwrite the new status.
- The new zombie is created already published, so it shows on the site straight away, then opens for you to write its epitaph.
- A grave only rises once. A second resurrection belongs on the zombie's grave, which keeps each chain a single line.

How I tested it: a script clicked the real Studio buttons against a production build, using five temporary bugs, and all 34 checks passed. They cover:
- every enabled/disabled state, including "🪦 Can bury in 4 days";
- today's UTC dates, with no drafts left behind;
- cancelling the confirm dialog;
- being blocked by unpublished edits;
- zombies of zombies (named "(Zombie #2)");
- the site updating within about 1.5 seconds, including an already open grave page.

The test bugs are deleted. After deploying, a read-only check confirmed the live Studio shows the right menu for your 3 real bugs.

A bug the test caught: right after one action changed a bug, "Report resurrection" was briefly disabled. My check for "has this grave already risen?" restarted after every change and blocked the button while running. It now only disables once a zombie is known to exist, and checks again when you confirm.

Still open: the dates and resurrection count are read-only and the actions always use today. So an old bug can't be given its real historical dates in the Studio; only a script or the API can do that.

Be careful trying it: these actions change your real data. "Report resurrection" on "NullPointerException in checkout" will create a real zombie.

For your write-up: how document actions work
- Every button at the bottom of a Sanity document (Publish, Duplicate, Delete) is a document action, and you can add your own.
- An action is a small React component. Sanity gives it the document's current state (the published version and any unpublished draft), and it describes a button: label, disabled or not, tooltip, what happens on click, and optionally a confirm dialog.
- Because it's a component, it updates whenever the document changes. That keeps labels like "Can bury in 4 days" current with no extra code.
- It runs in the browser as the signed-in person, using their permissions, so there's no API token in the code.
- You register actions in sanity.config.ts with document.actions. That function receives Sanity's default list and returns the list to show. The first one becomes the big button, and the rest go in the "…" menu.

There's a longer version of this in the Phase 5 entry of NOTES.md.

You

Phase 6: add a live "🪦 Tombstone" preview inside the Studio for bug documents.

  • Use the structure tool's defaultDocumentNode to add a second view tab on bug documents, next to the form: "Editor" (default form) and "🪦 Tombstone".
  • The Tombstone view renders the SAME Tombstone component the website uses (resting / disturbed / zombie looks), large, on a small night-sky background so it looks like the site.
  • It must update live as I type (use the draft if there is one, otherwise the published doc), including epitaph, name, dates and status. Resolve language and cause of death references so the badges show.
  • Show the 140-char epitaph limit as a small counter under the stone.
  • For zombies, show "Rose from <previous life name>" like the site does.
  • Also improve the Studio sidebar in sanity/structure.ts: "🪦 All graves", "🧟 Zombies", "💀 Suspected dead", "🩹 Fix merged", "Buried", then Languages and Causes of death. Add icons for the document types.

Test it (open a bug, type in the epitaph and watch the preview), then build/lint/type-check,
add the Phase 6 entry to NOTES.md, commit and deploy.

Agent

Phase 6. First I'll check the structure tool APIs in the installed Sanity: the defaultDocumentNode resolver type, and the props a custom view component receives. The props matter most, because live preview depends on whether the view gets the draft as you type.

Agent
Agent
Agent
Agent
Agent
Agent

That className no longer interpolates anything, so I'll turn it back into a plain string. Then the epitaph limit becomes one exported constant that both the validation rule and the new counter use.

Agent
Agent
Agent
Agent
Agent
Agent
Agent

listenQuery's parameter types don't allow null, so a missing reference will be passed as an empty string, which matches no document.

Agent
Agent
Agent
Agent
Agent

The sidebar is exactly right. Opening the "Zombies" list timed out, which is probably my assumption about how list panes appear in the page. I'll dump what the Studio actually renders at that URL.

Agent
Agent
Agent
Agent

The query itself is correct in every perspective, so the problem is in how I subscribe to it inside the Studio. I'll look at what the view actually rendered.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

All clean. I'll commit and deploy.

Agent
Agent
Agent
Agent

The Tombstone preview and the new sidebar are live at https://bug-graveyard.vercel.app/studio. They're committed (56e3296, notes in 37e2c2f), pushed and deployed. Type-check, lint, schema validation (0 errors) and the build all pass.

What's there:
- The Tombstone tab (TombstoneView.tsx) renders the site's own Tombstone component from the draft you're editing, or the published bug if there's no draft. It sits on a night sky with the moon and grass, and uses the site's gothic font.
- Badges and "Rose from" come from the language, cause of death and previous life. They update live, so recolouring a language changes the badge in an open preview.
- The counter shows "Epitaph: 87 / 140", and above the limit, "150 / 140 · 10 too long" in red. The limit is one constant, EPITAPH_MAX_LENGTH, shared with the validation rule.
- The sidebar (structure.ts) lists 🪦 All graves, 🧟 Zombies, 💀 Suspected dead, 🩹 Fix merged and ⚰️ Buried, then ⌨️ Languages and ☠️ Causes of death. The document types have icons too: 🐛, ⌨️ and ☠️.

Tested in the real Studio, all 22 checks passed:
- Sidebar: the order and icons are right, and the status lists filter correctly.
- The three looks: the badges show in the right colours.
- Live typing: with the form and preview side by side (as in the screenshot), the epitaph, counter, name and status all updated the stone within a few milliseconds of each keystroke. Switching the status to Zombie made it glow.

The test bugs and drafts are deleted. A read-only check of the live Studio showed the right preview for all three of your bugs.

To see it yourself: open a bug, click 🪦 Tombstone, then open the "…" menu at the top of the document and choose Split pane right. Put the form on one side and the tombstone on the other, and type.

Decisions to check:
- The sidebar emoji sit in each item's icon slot, so they line up with Languages and Causes of death.
- "Buried" got ⚰️, since you'd used 🪦 for "All graves".
- Only "All graves" and "Suspected dead" have a "create" button. A new bug always starts as suspected dead, so one created from "Zombies" would vanish from that list straight away.
- The fonts moved to the root layout, so the Studio can use the site's gothic font. This only adds font variables; the Studio's own fonts don't change.

Fixed during testing: the badges and "Rose from" took several seconds to appear, because my first approach re-ran a slow live query every time the draft loaded. They now come from the Studio's preview store, the same fast cache it uses for its own reference previews, and appear within about 100ms.

The Phase 6 entry in NOTES.md has the details, plus Sanity notes for your write-up on custom views, reusing site components and split view.

You

Phase 7 (two parts):

A) "Most Haunted" leaderboard at /leaderboard (in the (site) group, same spooky style):
- Deadliest bugs: top 5 by hoursToKill
- Most haunted languages: count of zombies per language
- Most common causes of death: count of bugs per cause
- Most resurrected: the bug chain with the highest timesResurrected
- Use GROQ aggregations, sanityFetch for live updates, and add nav links
(Graveyard / Most Haunted) in the site header. Mobile friendly.

B) A content importer so I can add my real bugs with historical dates:
- Create content/graves.ts where I write bugs as a simple list (name, language, cause,
severity, epitaph, killedBy, hoursToKill, bornAt, fixMergedAt, buriedAt, status,
and an optional "risesFrom" pointing to another entry's key to make zombie chains).
- Create scripts/import-graves.ts that turns that list into published Sanity documents
with fixed IDs (safe to re-run, updates existing ones), resolves language/cause by name,
links previousLife from risesFrom, and computes timesResurrected from the chain.
- Add 2 example entries (one zombie chain) so I can see the format, but DON'T add my real
content, I'll write that myself.
- Add a --delete-test flag that removes all "test-bug-" documents.

Build/lint/type-check, add the Phase 7 entry to NOTES.md, commit and deploy.

Agent

Phase 7. Part A includes ranked lists with proportional bars, which is a chart, so I'll load the data-visualisation guidance before writing that part.

Agent
Agent

I'll read the guidance that applies here: choosing a form, bar mark specs, interaction and anti-patterns. These are small, single-series ranked lists.

Agent
Agent
Agent
Switched to <synthetic>
Agent

API Error: Can't reach the API server — check your internet or DNS (ENOTFOUND)

You

.

Switched to claude-opus-5-5
Agent

Continuing Phase 7. The chart guidance is loaded, so next I'll check the bar colours against the dark card background with the validator script rather than judging them by eye.

Agent
Agent

Both colours fail the dark-mode lightness band (they're too light), and the bone colour reads as grey. I'll take the reference palette's dark-mode steps rather than guess.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Next I'll add pastLivesOf to lib/graves.ts, switch the grave page to the shared LifeChain, add the chart colour tokens, and put the nav in the header.

Agent
Agent
Agent

The leaderboard page derives its prop type with an awkward getLeaderboard helper. TypeGen can supply LEADERBOARD_QUERY_RESULT instead, so I'll regenerate the types and use that.

Agent
Agent

Part A type-checks and lints. Next I'll build and look at /leaderboard at desktop and 390px widths, then check the nav on the homepage and a grave page.

Agent
Agent
Agent
Agent
Agent
Agent
Agent

One bug in my own date check: new Date('2026-02-30…').toISOString() throws on an impossible date instead of returning false. I'll guard it, then write the CLI.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Phase 7 is committed (90f50e6). The deploy command finished without printing its usual "Aliased" line, so I'll check whether it actually went out.

Agent
Agent

It didn't deploy: the newest deployment is from Phase 6, and /leaderboard returns 404 on the live site. I'll rerun the deploy with its full output visible.

Agent
Agent

The build succeeded on Vercel, but the final upload failed with "fetch failed", which looks like a temporary network error. I'll retry once.

Agent
Agent
Agent
Agent
Agent

The dataset is exactly as before: your 3 test bugs, no drafts and no leftovers. Now the Phase 7 entry in NOTES.md, then commit and push.

Agent
Agent

Phase 7 is done and live. The leaderboard is at https://bug-graveyard.vercel.app/leaderboard. The code is committed as 90f50e6 (notes in 76347be), pushed and deployed. Type-check, lint, schema validation and the build all pass.

A) Most Haunted leaderboard
- Four cards from one GROQ query: deadliest bugs (top 5 by hours to kill), most haunted languages, most common causes of death, and the most resurrected chain, shown as linked mini tombstones.
- It updates live. Importing two bugs refreshed the live leaderboard within about 2 seconds.
- Every row is a link: a bug goes to its grave page, and a language or cause goes to the homepage filtered by it.
- The header has Graveyard / Most Haunted links, and grave pages count as Graveyard.
- It works on phones, with no horizontal scrolling at 390px.
- Chart colours: I followed the charting guidance and checked the bar colours with its validator. My first colours failed (too light), so the bars are the reference palette's aqua and violet. Every value is printed at the end of its bar.
- One choice to check: "haunted" counts every bug that ever came back, not only zombies still walking, so a zombie that's fixed and buried still counts for its language.

B) Importing your real bugs

Write them in content/graves.ts. Every field is explained in content/types.ts, and the two examples show a grave plus the zombie that rose from it. Then run:

npx sanity exec scripts/import-graves.ts --with-user-token -- --dry-run      # check only
npx sanity exec scripts/import-graves.ts --with-user-token                   # import
npx sanity exec scripts/import-graves.ts --with-user-token -- --delete-test  # remove the test bugs
  • Each entry becomes a published bug called grave-<key>. Its page is /grave/<key>, so don't change a key after importing.
  • Re-running updates in place. The file wins over Studio edits to imported bugs, and the script warns if you have unpublished Studio edits on one.
  • Nothing is written if any entry has a problem. It lists every problem, such as an unknown language (with the valid names), an impossible date, dates out of order, an epitaph that's too long, a risesFrom that doesn't exist or loops, or a grave rising twice.
  • --delete-test refuses if anything still points at a test bug, and names it.

Tested:
- 32 checks on the list-checking logic, including about 20 kinds of mistake.
- 18 checks on the live site. I imported the examples: the homepage, zombie page and leaderboard updated through the webhook within about 2 seconds, and re-running updated them without duplicates. I ran --delete-test for real after backing up your 3 test bugs, then restored them field for field and removed the examples. Your dataset is back exactly as it was.

Fixed along the way:
- Scripts were missing drafts. Sanity queries default to published documents only, so seed-test-bugs --delete would never have found Studio drafts of test bugs. It's fixed there, and the importer asks for drafts wherever they matter.
- One deploy failed at the upload step with a network error. My filtered output hid it until the live /leaderboard returned 404. A retry worked, and the live page is verified.

When your real bugs are in: run --delete-test to remove the test bugs. The examples in content/graves.ts get imported too if you leave them in, so replace them first. The Phase 7 entry in NOTES.md has the details and the Sanity notes for your write-up.

You

Phase 8: real content.

  1. Seed: add these causes of death: CSS, Cache, Dependency hell, Floating point, Encoding,
    Merge conflict. Add a language "CSS" (#663399). Run the seed.

  2. Replace the 2 examples in content/graves.ts with these graves. Pick realistic
    historical dates (bornAt < fixMergedAt < buriedAt, buriedAt at least 7 days after
    fixMergedAt, spread over 2024–2026), sensible hoursToKill (1–40) and severities.
    killedBy = "Jashanpreet" unless noted. Keep my epitaphs word for word.

  • loop-skipped-last | Loop that skipped the last item | Python | Off-by-one | "Almost made it to the end. Almost."
  • undefined-not-function | undefined is not a function | JavaScript | Null reference | "It was never a function. It was never anything."
  • floating-invoice | The 0.1 + 0.2 invoice | JavaScript | Floating point | "Owed ₹0.30000000000000004. Paid in full."
  • div-center | The div that refused to center | CSS | CSS | "Stood slightly to the left of everything, forever."
  • my-machine | Works only on Jashan's laptop | Python | Works on my machine | "It worked on my machine. Now it rests there."
  • dst-cron | Cron job that ran twice at DST | Java | Timezone | "Died twice in one night. Twice as dead."
  • stale-cache | Stale cache after deploy | TypeScript | Cache | "Showed you yesterday, every day."
  • npm-install | npm install broke the build | JavaScript | Dependency hell | "Killed by a package it never imported."
  • race-counter | Two threads, one counter | Java | Race condition | "Both threads won. The counter lost."
  • while-true | while (true) with no break | C++ | Infinite loop | "Still running. Please do not disturb."
  • emoji-username | Emoji broke the username | Python | Encoding | "Here lies é. It was once 'é'."
  • merge-head | <<<<<<< HEAD in production | TypeScript | Merge conflict | "Both versions were right. Neither survived."
  • index-minus-one | Array index -1 | C++ | Off-by-one | "Wrote where no one should write."
  • null-profile | Null user on the profile page | Java | Null reference | "Nobody was home. It crashed anyway."

Zombie chain (3 levels):
- tz-scheduler | Timezone bug in scheduler | Python | Timezone | buried | "Died at 00:00 UTC. Still alive in IST."
- tz-scheduler-z1 | risesFrom tz-scheduler | status buried | "Came back after daylight saving. Buried again."
- tz-scheduler-z2 | risesFrom tz-scheduler-z1 | status zombie (still walking) | "Every time zone. Every time."

Also make one more zombie: stale-cache-z1 | risesFrom stale-cache | zombie | "Cleared the cache. The cache remembered."

  1. Dry run, then import, then --delete-test to remove the test bugs.
  2. Verify on the live site: homepage shows all graves with correct looks (disturbed/zombie), the 3-level chain shows past lives on tz-scheduler-z2, and the leaderboard makes sense.
  3. Add the Phase 8 entry to NOTES.md, commit and push.
Agent

Phase 8, the real content. I'll start with the seed: six new causes of death (each with a one-line description, like the existing ones) and the CSS language.

Agent
Agent
Agent
Agent
Agent
Agent

Both new rules behave correctly. Now step 3: the dry run first.

Agent
Agent

The dry run is clean: 18 creates, the chain counted 1× and 2×, and the stale-cache zombie 1×. Now the real import, then --delete-test to remove the three test bugs.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Your real graveyard is live at https://bug-graveyard.vercel.app: 18 graves, and the test bugs are gone. Everything is committed as 96a6d42 and pushed.

What I did:
1. Seed: added the six causes of death, each with a one-line description like the existing ones, plus CSS as a language (#663399). The run created exactly those 7 and skipped the existing 11.
2. content/graves.ts now holds your 18 graves:
- The 14 bugs are all buried, dated February 2024 to April 2026, with every burial 8–12 days after its fix and 1–38 hours to kill.
- The timezone chain starts on real daylight-saving switches: 30 March 2025, 26 October 2025 (Zombie #1, "Came back after daylight saving") and 29 March 2026 (Zombie #2, still walking). "Cron job that ran twice at DST" is dated to the night European clocks fell back in 2024.
- Zombies follow the Studio's naming, "(Zombie #n)", with the same language and cause as their grave.
- Walking zombies only have a birth date, since they haven't been fixed.
- All 18 epitaphs are word for word, confirmed by a separate check.
3. Dry run, import, then --delete-test: the dry run showed 18 creates, with the chain counted 1× and 2×. The dataset now has exactly 18 graves and no drafts.

Checked on the live site (the webhook updated it within about a second):
- Homepage: "18 graves · 2 zombies walking". The original timezone bug, timezone Zombie #1 and the stale cache show as disturbed; timezone Zombie #2 and stale-cache Zombie #1 glow as zombies; the other 13 rest. <<<<<<< HEAD, ₹0.30000000000000004 and "é" all render correctly.
- Grave pages: all 18 load, and the old test pages return 404.
- Zombie #2's page lists its past lives oldest first (the original, then Zombie #1) and shows "Times resurrected: 2".
- Leaderboard:
- Deadliest: 38h race condition, 22h index −1, 20h, 16h, 14h.
- Haunted languages: Python 2, TypeScript 1.
- Causes: Timezone leads with 4.
- Most resurrected: Zombie #2, with its three-stone chain.

Added to the importer: two rules the Studio already enforces:
- A burial must come at least 7 days after the fix.
- A zombie can't be born before the fix it regressed.

Both were tested and neither affected your content.

Worth knowing:
- Two of my live checks failed, but my expectations were wrong, not the site. You use 12 distinct causes of death, not 14, and my helper looked for the wrong heading level. I confirmed both against the live page.
- One small layout issue on the leaderboard: on desktop, the three-stone chain in "Most resurrected" wraps onto a second line, and the long causes list leaves empty space beside it. I can rearrange the cards if you like; that needs a redeploy.
- A redeploy would also prerender your 18 grave pages at build time. Right now each one is rendered on its first visit and then cached, which works fine.

The Phase 8 entry in NOTES.md has the details.

You

Before the polish pass: make 2–3 graves in content/graves.ts come from bugs I really fixed.

  1. Look through my other coding projects on this Mac (check ~/Desktop, ~/Documents and ~/Projects for git repos, but skip node_modules and this repo). Read their git logs for commits that fixed bugs (messages with "fix", "bug", "crash", "error", "broken" etc.). Don't open or print any .env files or secrets.
  2. Show me a short list of the 5 most interesting real bug fixes you found (repo, date, commit message, what the bug probably was).
  3. Then ask me which 2–3 to use and one question each about what happened (how long it took, how I found it). If you find nothing useful, interview me instead: ask me 3 short questions about real bugs I've fought in college projects or LeetCode.
  4. Turn my answers into graves (real dates from the commits where possible, funny epitaphs in the same style), replacing the weakest 2–3 current entries.
  5. Mark them with a comment "// real bug" in content/graves.ts, re-run the import, verify the live site, add a note to NOTES.md listing which graves are real, and commit.
Agent

I'll look for git repos in ~/Desktop, ~/Documents and ~/Projects, skipping node_modules and this project. I'll only read commit history (messages, dates and authors), not files, and never .env files.

Agent
Agent
Agent
Agent

I found no real bug fixes to use.

What's on this Mac:
- ~/Desktop/BTP_BEST (GitHub: UMCS): 3 commits, all yours, all on 18 July 2026: "Initial commit", "Update .gitignore" and "Remove local config and log files". It's housekeeping, not bug fixes.
- ~/Desktop/ml_challnege: a git repo with no commits.
- ~/Documents/color-norm-btp: 7 commits, all by Niharika Saxena, so not your fixes.
- ~/Projects doesn't exist.

None of the 10 commit messages contain fix, bug, crash, error, broken, issue, resolve, patch, wrong or fail. So I can't list 5 real fixes. I read only commit messages, dates and authors: no file contents, and no .env files.

As you asked for this case, here are three short questions. Answer as loosely as you like:

  1. College project: what's the worst bug you've hit in a college project (your BTP, the ML challenge, anything else)? Which language, roughly which month and year, and about how many hours did it take?
  2. LeetCode: which problem fought back the hardest? What was the mistake (off-by-one, integer overflow, time limit exceeded, a wrong edge case…) and how did you finally spot it?
  3. The comeback: did a bug ever come back after you thought you'd fixed it, or break at the worst moment, like a demo, a submission or a viva? What happened?

One optional extra: was the "Remove local config and log files" commit on 18 July 2026 cleaning up an accidental commit? If so, that could be a grave with a real date.

Once you answer, I'll replace the weakest two or three entries. My candidates are "Loop that skipped the last item" (your second off-by-one), "undefined is not a function" (your second null reference) and "while (true) with no break". I'd keep the zombie chains. Tell me if you'd rather drop different ones.

You

Skip the real-bug interview: keep content/graves.ts as it is. Note in NOTES.md that the
graves are classic, well-known developer bugs (not claimed as my personal history).

Then do Phase 9, the polish pass before submission:

  1. Fix the leaderboard layout: rearrange the cards so "Most resurrected" (the 3-stone chain) doesn't wrap and there's no empty space on desktop.
  2. Vary tombstone heights/shapes slightly on the homepage so the graveyard looks natural (deterministic per bug, based on its ID, so nothing jumps on reload).
  3. Favicon (a tiny tombstone), a site-wide OG image, and a per-grave OG image with next/og showing the tombstone name + epitaph, so links look great when shared on DEV.
  4. Check every page at 375px and 1440px; fix any overflow or awkward spacing.
  5. Accessibility: aria labels, colour contrast on muted text, visible keyboard focus on filters, nav and tombstones, respect prefers-reduced-motion for fog/animations.
  6. Page titles and descriptions everywhere; a footer: "Built with Next.js + Sanity for the DEV Sanity Challenge" with a link to the GitHub repo.
  7. A proper README: one-line pitch, screenshot, live link, features (zombie chains, lifecycle document actions, live Tombstone view in Studio, leaderboard, content importer), the schema design and why, stack, how to run locally. No secrets.
  8. Check the repo and git history for secrets (tokens, .env, the webhook secret).
  9. Build/lint/type-check, deploy so all grave pages are prerendered, verify the live site, add the Phase 9 entry to NOTES.md, commit and push. List anything you couldn't fix.
Agent

Skipping the interview. Phase 9 touches several parts of Next 16 I haven't used here yet (the icon and opengraph-image file conventions, ImageResponse and its fonts), so I'll read those docs first, as AGENTS.md asks.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Small slip: defineLive doesn't expose its client, so I'll use the imported client directly.

Agent
Agent
Agent
Agent
Agent
Agent
Agent

Both look right. The ₹ comes through, which confirms the symbol fallback font works, and the curly quotes render. Now the zombie version.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Now NOTES.md. The note about the graves goes near the top, where readers will see it, and the Phase 9 entry goes at the end.

Agent
Agent
Agent

Everything is pushed. One last check: that the README's screenshots actually load from GitHub.

Agent
Agent

Phase 9 is done and live at https://bug-graveyard.vercel.app. The code is 43f8d2e (deployed, with all 18 grave pages served prerendered) and the README and notes are efd51b7. Both are pushed, and the README's screenshots load on GitHub.

What changed:
1. Leaderboard: "Most resurrected" now spans the full width, so the three-stone chain sits on one line. Below it, two columns end level, and the short lists use one-line rows.
2. Natural stones: each grave gets one of four shapes, plus small differences in height, width and tilt, all from a hash of its ID, so nothing moves on reload. Only resting stones tilt, and the stones share a ground line.
3. Icons and share images: a tombstone favicon and home-screen icon, a site-wide share image, and one per grave with its stone, name, epitaph and "Rose from …". The ₹ renders, thanks to a small fallback font.
4. 375px and 1440px: all 8 page types, including the Studio and both 404s, have no horizontal overflow. I also widened a column that was cutting off "Works on my machine".
5. Accessibility:
- a skip link, and a visible focus ring at every one of 142 keyboard stops across three pages;
- screen readers still hear the captions on small stones;
- three muted texts that were under 4.5:1 contrast now pass;
- reduced motion stops the fog, the zombie glow and the hover lift.
6. Titles and footer: every page has a title ("Most Haunted · Bug Graveyard"; your "RIP <name>" is kept), a description, share tags with absolute URLs, and large-image Twitter cards. The footer links to the repo. Unknown URLs get a styled 404.
7. README.md: the pitch, three screenshots, the live link, the features, the schema design and why, the stack, local setup and deployment. It ends with a note that the graves are classic developer bugs, which I added there as well as in NOTES.md, since DEV readers will see the README.
8. Secrets: none of the three real secrets (the webhook secret, the Vercel token and your Sanity CLI token) appears in any file or in any of the 13 commits. There are no token patterns, and no .env file was ever committed.

Fixed along the way:
- The site's CSS leaked into the Studio. My first 404 page pulled Tailwind into /studio; it now uses a scoped CSS module.
- A build would have prerendered your deleted test bugs from a stale local cache. The list of graves to prerender is now always fetched fresh.
- The leaderboard's share image went missing. It's back.

What I couldn't fix:
- Pushing to GitHub still doesn't deploy. You need to add GitHub as a login connection in Vercel's account settings first; until then, I deploy from the command line.
- Share images show emoji or non-Latin text as empty boxes. The fallback font only covers ₹ € £ ¥, curly quotes and dashes. The site itself is fine.
- An unknown grave's 404 page sends the site's name as its initial title. Browsers then show "This grave is empty", and 404s aren't indexed anyway.
- The leaderboard columns end level by stretching one card, so very different content could leave some empty space inside it.
- No real screen reader or real phone testing, only automated checks and emulation.

The Phase 9 entry in NOTES.md has the details and the Sanity notes for your write-up.

You

Bonus investigation (time-box: 3 hours, don't break anything that works):

The judges gave bonus points for Sanity Workflows ("model a process as data next to
the content, so an agent can move a draft forward and a person can approve it through
the same transitions") and the App SDK.

  1. Check the current Sanity docs (npx sanity@latest docs / workflows commands) and tell me honestly whether Sanity Workflows is usable on my project/plan right now, and what it would take to model the bug lifecycle (suspected dead → fix merged → buried → zombie) as a Workflow, keeping the existing document actions working.
  2. If it's feasible in under 3 hours, build it on a separate git branch, test it, and show me before merging.
  3. If Workflows isn't practical, propose the smallest App SDK app instead, e.g. a real-time "Morgue" dashboard showing the graves that can be buried today and walking zombies, with one-click actions. Don't deploy until I say so. Add findings to NOTES.md.
Agent

I'll start by checking what the current Sanity CLI offers for Workflows, and what its built-in docs command says.

Agent
Agent
Agent

docs search failed with "Invalid response format from documentation search API". I'll retry with a different query and look at how docs read works.

Agent
Agent
Agent

/docs/workflows exists. I'll save the full article and read it closely, looking for plan requirements, the definition format, and how it interacts with documents and the Studio.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

--legacy-peer-deps skipped the CLI's required peer @sanity/workflow-blueprint. I'll install that explicitly (its TypeScript 6/7 peer is optional) and rerun the offline check.

Agent
Agent

Both definitions pass Sanity's validation, checked offline without contacting the dataset. Now the in-memory tests, which run the real Workflows engine against the lifecycle with a controlled clock.

Agent
Agent

Same cause: --legacy-peer-deps also skipped vitest's peer, vite. I'll install it and rerun.

Agent
Agent
Agent
Agent
Agent
Agent

The experiment branch explore/workflows passes type-check and lint and has two commits. It's local only: not merged, not pushed, not deployed. Last step, the findings go into NOTES.md on main.

Agent
Agent

Workflows is usable on your project and plan today, but a proper integration doesn't fit in 3 hours, so I didn't wire it in. I proved the model works on a separate branch, and propose a small App SDK app as the bonus you can actually ship. Nothing was deployed, no workflow definitions were written to Sanity, and main works exactly as before. This took about 2 of the 3 hours.

What the current docs say:
- It's early access (version 0.35, pre-1.0, so minor versions can break things). It's a library plus a CLI that stores its data as ordinary documents. I found no plan restriction, so your free plan works.
- The Studio plugin needs Sanity Studio 6.15 or later. You're on 5.31.
- Nothing runs by itself. Anything the workflow should do automatically, like writing status back onto the bug, needs something you operate to carry it out, such as a Sanity Function. Sanity's generated setup for that is marked experimental.
- Its checks don't stop anyone. Disabled actions and "guards" only grey out buttons; anyone with a write token can bypass them.
- Deploying a workflow shares its definition with Sanity by default. You can opt out.
- It clashes with your ESLint setup. Workflows' CLI wants TypeScript 6 or 7, while your ESLint needs TypeScript below 6.1. TypeScript 6.0.x would satisfy both.
- Sanity's docs search is currently broken ("Invalid response format"), so I read the articles by path.

What I built on explore/workflows (local only: not merged, not pushed):
1. The Sanity 6 upgrade, as a trial. It needed only two small changes. Type-check, lint, schema validation and the build all pass. A look at the Studio (no clicks, nothing written) found the sidebar, the Tombstone view and the action menus all correct on real graves. I haven't clicked the lifecycle actions on v6, since that writes data.
2. Your lifecycle as a Workflow in workflows/bug-lifecycle.ts: suspected dead (or walking, for zombies) → fix merged → buried → risen.
- "Declare buried" is blocked until 7 days after the fix. It's a rule checked at the moment someone asks, so no timer is needed, and it reuses your BURIAL_WAIT_DAYS.
- It passes Sanity's own validation, checked offline.
- 4 tests pass against the real Workflows engine, run in memory with a controlled clock. Burial is refused until exactly day 7 and then allowed; a regression before burial goes straight to risen; zombies start as walking; and only one lifecycle runs per bug.

What a real integration would take: about 1.5 to 2 days. The hard part is deciding which copy of the status is the real one:
- If the workflow drives, writing the dates back onto the bug needs a runtime (a Sanity Function) that you run.
- If your actions also fire the workflow, you have two copies of the state that can drift apart.

On top of that: merging the upgrade, starting workflows for your 18 existing graves at the right stage, building a UI, and testing.

What I'd build instead: a "Morgue" App SDK app, about 2–3 hours. It's a live dashboard inside the Sanity Dashboard with four columns: "Ready to bury today", "Waiting (N days left)", "Walking zombies" and "Suspected dead". Each card has one-click Mark fix merged / Declare buried / Report resurrection buttons, using the same rules as the Studio actions. It needs no Studio upgrade and touches nothing that works, and it could later host a Workflows screen, because the Workflows App SDK packages only need React 19.

To look at the experiment:
- run git log main..explore/workflows and git diff main..explore/workflows -- workflows sanity.workflow.ts;
- run the tests with npx vitest run workflows/ in the worktree, which is in my session's temporary folder (the path is shown next to the branch in git branch -vv).

The findings are in NOTES.md, committed on main as a3d7a4d but not pushed.

What would you like to do?
1. Should I build the Morgue app? It would stay local until you say deploy.
2. Keep, push or delete the explore/workflows branch?
3. Push the NOTES commit?

You

Do my whole DEV submission yourself. Only stop to ask me for logins/approvals.
Work in ~/Desktop/bug-graveyard. The post draft is bug-graveyard-dev-post.md
(if it's not in the project folder, find it in ~/Downloads and move it here).

  1. MEDIA: using Playwright/Chromium, capture PNGs of the LIVE site
    https://bug-graveyard.vercel.app at 1440px: homepage, the "Timezone bug in scheduler
    (Zombie #2)" grave page with Past lives, and /leaderboard. From the Studio (local dev if
    needed), capture the "…" menu showing the three lifecycle actions. Record a demo in the
    Studio split pane (form + 🪦 Tombstone view): type a new epitaph and switch status to
    Zombie so the stone glows. Use a TEMPORARY test bug and delete it after, so no real
    data changes. Convert to an optimized GIF (<10MB, ≤1200px, ~12fps) with ffmpeg
    (install via Homebrew if needed).
    Put all media in the repo under docs/post/, commit and push, and use their
    raw.githubusercontent.com URLs as images in the post.

  2. POST: fill every [ADD ...] with the right image URL. Fill every [YOUR WORDS] spot with
    short, honest, first-person lines based ONLY on what really happened in NOTES.md and our
    sessions (I directed each phase, tested in the browser, and Claude Code wrote most of the
    code). Don't invent feelings or personal bug stories. Say clearly that the graves are
    classic developer bugs. Fact-check every claim, number and code snippet against the real
    code and NOTES.md, and fix anything wrong. Remove the HTML comment blocks.

  3. AGENT SESSION: find this project's Claude Code transcripts in ~/.claude/projects/,
    redact all secrets (Sanity tokens, webhook secret, Vercel token, API keys, .env values)
    as [REDACTED], and save the clean copy to ~/Desktop/bug-graveyard-session.jsonl.
    Tell me what kinds of things you redacted (not the values).

  4. DEV DRAFT: walk me through creating a DEV API key (dev.to → Settings → Extensions).
    I'll paste it into .env.local as DEV_API_KEY. Never print or commit it.
    Create the article via the DEV API as an UNPUBLISHED draft (published: false) with tags
    devchallenge, sanitychallenge, sanity, nextjs. Then show me the full final post text and
    the draft link, and WAIT. Only publish (published: true) after I reply "publish".

  5. After publishing: verify the live article loads, images show, and links work.
    Add a final entry to NOTES.md, commit and push. Then give me a short list of anything
    left for me to do by hand.

Agent

This is a long run. I'll only stop for the DEV API key and for your "publish". First I'll find the post draft and check the tools I need: ffmpeg, Homebrew and Playwright.

Agent
Agent
Agent
Agent

Playwright 1.63 is ready, and ffmpeg is installing in the background. Meanwhile I'll read the post draft.

Agent
Agent
Agent
Agent
Agent
Agent
Agent

Playwright's ffmpeg is installed (1MB, in Playwright's cache folder). I'll rerun just the recording step.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

The GIF is 1200×814 at 12 fps, 114 frames (about 9.5 seconds) and 2.2MB, well under the 10MB limit. I'll check its final frame to make sure the zombie glow made it in before the cut.

Agent
Agent
Agent
Agent

It's clean: 18 bugs, 0 drafts, and the live homepage no longer shows the demo bug. Before committing, I'll look at the live screenshots, starting with the homepage and Zombie #2's grave page.

Agent
Agent
Agent
Agent

The retake failed with a Node error; the files still have their old timestamps. I'll run it again and look at the actual error.

Agent
Agent

It worked this time, so the first failure was probably a one-off timeout. I'll confirm the new homepage shows 18 graves and no demo bug, and that the leaderboard counts are back to normal.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

All the claims have now been checked against NOTES.md. Before writing, I'm pulling a few of your actual prompts from the session logs so the "My Build Process" section can quote you accurately.

Agent
Agent
Agent
Agent
Agent
Agent

The dataset is public (18 bugs, no token needed). Next I'll check that the screenshots actually show what the captions say.

Agent
Agent
Agent

The screenshots match their captions: all three stone looks are visible, and the menu shows the three actions, including "Can bury in 4 days". Last check is the webhook timing.

Agent
Agent

Now two last details: how the site links to /studio, and the exact burial rule on the Workflows branch.

Agent
Agent
Agent

Everything checks out. One fix: the site never links to /studio at all, so I'm dropping that claim. Writing the final post now.

Agent
Agent
Agent

All 9 links and images return 200, and no [ADD], [YOUR WORDS] or HTML comments are left. One more look to check the grave-page alt text against the screenshot.

Agent
Agent

The post is finished and fact-checked. Next is Step 3, the redacted transcript. First I'll see which transcript files exist and where the secrets live, looking at file names only, not their contents.

Agent
Agent
Agent

Base64 screenshot data in the transcript could trip the broad token patterns and corrupt images. I'll switch the script to walk each parsed JSON line, skipping image data and thinking signatures.

Agent
Agent
Agent
Agent
Agent
Agent
Agent

The redacted copy is saved at ~/Desktop/bug-graveyard-session.jsonl. Next I'll prepare the DEV draft script. It will be ready to run as soon as your API key is in .env.local.

Agent
Agent
Agent

Steps 1–3 are done. I've stopped at Step 4 because I need your DEV API key to continue.

Done so far
- Media: 4 screenshots plus the Studio GIF (1200px wide, 12fps, 2.2MB) are in docs/post/, committed and pushed. The temporary test bug is deleted, so the site still has its 18 real graves.
- Post: bug-graveyard-dev-post.md is finished.
- It follows the challenge's Path Two template headings: What I Built, Demo, Code, My Build Process, Sanity Project Details, Agent Session.
- Every placeholder is filled with a working image URL or a factual first-person line, and the HTML comments are gone.
- All 9 links and images return 200.
- Fact-check fixes in the post:
- The lifecycle actions sit after Publish in the "…" menu; they aren't buttons next to it.
- Only the fix date, burial date and resurrection counter are read-only; the importer script also sets dates.
- vercel.json sets "framework": "nextjs"; it isn't "two lines".
- The CSS leak came from the root 404 page.
- The timezone and dotted-ID items were traps avoided from the start, not things that went wrong, so they're now labelled that way.
- The Workflows burial rule is quoted as it's actually written.
- Session copy: saved to ~/Desktop/bug-graveyard-session.jsonl (35.8MB).

What I redacted (kinds only, no values)
- Checked by exact value, found 0 times: the Sanity webhook secret, the Vercel OIDC token, the Sanity login token, the Vercel CLI token and the GitHub token. None of them were ever printed in the session.
- Checked by pattern, 0 real hits: API keys (Sanity/Anthropic/OpenAI style), GitHub tokens, JWTs, Bearer and api-key headers, and …SECRET=, …TOKEN= and …KEY= assignments.
- Actually replaced with [REDACTED]:
- 14 mentions of the one-time Vercel device login code.
- 16 mentions of a teammate's two email addresses. They came from the git log of their repo during the real-bug scan. They aren't secrets, but I didn't want someone else's email in a public upload.
- Left in on purpose:
- Your Sanity project ID and dataset name, which are public.
- Your own email addresses: the Gmail one is already on your public commits, and your university email also appears.
- The names of your other local repos, and your teammate's name and public repo URL in the repo-scan part.
- Tell me if you want any of these removed.
- Screenshots in the session were left untouched.
- I'll regenerate this file after the draft exists, so it covers the rest of the session and the DEV key is redacted too.

Step 4: create your DEV API key
1. Sign in at https://dev.to.
2. Open https://dev.to/settings/extensions (Settings → Extensions).
3. Scroll to DEV Community API Keys.
4. Enter a description such as bug-graveyard draft and click Generate API Key.
5. Copy the key and open .env.local in VS Code. It's gitignored.
6. Add a line DEV_API_KEY=your-key-here, with no quotes or spaces, and save.
7. Don't paste the key in this chat. Just reply done.

Once you reply, I'll check that DEV accepts the key (I'll print only your username). Then I'll create the post as an unpublished draft with the tags devchallenge, sanitychallenge, sanity and nextjs, show you the full final text and the draft link, and wait. I'll publish only after you reply "publish". You can revoke the key on the same settings page afterwards.

You

done

Agent
Agent

DEV accepted the key. Creating the unpublished draft now.

Agent
Agent

The draft exists and DEV confirms published: false. Next I'll see whether the preview renders, checking that the images, the code blocks and the template intro line came through.

Agent
Agent
Agent
Agent

The draft is created as unpublished. I'm waiting for you to reply "publish".

Draft link (only visible when you're logged in to DEV): https://dev.to/jashanpreet_kaur_917e774f/bug-graveyard-where-fixed-bugs-are-buried-and-regressions-rise-as-zombies-4934-temp-slug-6480696

Edit link: https://dev.to/jashanpreet_kaur_917e774f/bug-graveyard-where-fixed-bugs-are-buried-and-regressions-rise-as-zombies-4934-temp-slug-6480696/edit

The DEV API confirmed published: false, and the tags are devchallenge, sanitychallenge, sanity and nextjs. I couldn't check how it renders because the preview needs your login, so please look at it once.

Before you reply "publish", in the DEV editor:
1. Agent session:
- Go to https://dev.to/agent_sessions/new and upload ~/Desktop/bug-graveyard-session.jsonl.
- If it's too big (35.9MB), use ~/Desktop/bug-graveyard-session-slim.jsonl instead (8.6MB, same text, with the 74 screenshots replaced by "[screenshot omitted]").
- Trim it if you want, click Make Public, and paste its embed under the "## Agent Session" heading in the draft. Save the draft, but don't publish from the editor.
- Both files were regenerated just now. The DEV key is on the redaction list and never appeared in the session.
2. Cover image (optional): the template suggests adding one.

When you reply "publish", I'll check that the session embed is in the draft, then change only published to true, so your editor changes are kept. If you'd rather skip the agent session, say so and I'll remove that heading first.

Full post text (title: Bug Graveyard: where fixed bugs are buried, and regressions rise as zombies):

*This is a submission for the [Sanity Challenge, Path Two: Vibe-Code Something Strange](https://dev.to/challenges/sanity-2026-09-16)*

![Sanity Studio in split pane: typing a new epitaph in the form updates the tombstone on the right, and switching the status to Zombie makes the stone crack and glow green](https://raw.githubusercontent.com/jashanpreet-k/bug-graveyard/main/docs/post/studio-live-tombstone.gif)

*The Studio in split pane: the form on the left, the live 🪦 Tombstone view on the right. (This is a throwaway test bug, deleted afterwards.)*

## What I Built

**Bug Graveyard** is a memorial site for the bugs we fixed.

Every fixed bug gets a tombstone with its dates, cause of death and an epitaph. Most of them stay dead. But some come back (a regression), and when they do, they **rise from their grave as a zombie**, linked to the life they had before. The old grave is left disturbed and empty.

A few of the residents:

> **The 0.1 + 0.2 invoice**: *"Owed ₹0.30000000000000004. Paid in full."*
>
> **Timezone bug in scheduler (Zombie #2)**: *"Every time zone. Every time."*
>
> **<<<<<<< HEAD in production**: *"Both versions were right. Neither survived."*

The graves are classic bugs that every developer has met at some point: off-by-one errors, `0.1 + 0.2`, the div that won't centre. They aren't a record of my own personal disasters, and their dates are made up but realistic.

The idea is one joke taken literally: a regression is a bug that came back from the dead, so here it comes back as a zombie. Most of the work went into modelling that lifecycle properly in Sanity, not just drawing tombstones.

## Demo

🪦 **Live site:** https://bug-graveyard.vercel.app

![The Bug Graveyard homepage: language and cause-of-death filters above rows of tombstones under a full moon, including two glowing green zombie stones and one knocked-over, empty grave](https://raw.githubusercontent.com/jashanpreet-k/bug-graveyard/main/docs/post/homepage.png)

The graveyard shows three kinds of stone:

- **Resting:** fixed, and it stayed fixed.
- **Disturbed:** knocked over, with a crossed-out R.I.P. and an empty hole. The bug rose again.
- **Zombie:** cracked, glowing green, "Risen" and "still walking".

You can filter the graves by language or cause of death. Click any stone to open its grave page: a death certificate (cause of death, severity, hours to kill, killed by) and its **past lives**. The timezone bug is on its third life, and each life starts on a real daylight-saving switch (30 March 2025, 26 October 2025 and 29 March 2026), because of course it does.

![The grave page of "Timezone bug in scheduler (Zombie #2)": a large glowing zombie tombstone, its death certificate, and a Past lives row showing the two earlier graves in its chain](https://raw.githubusercontent.com/jashanpreet-k/bug-graveyard/main/docs/post/grave-zombie-2.png)

The **Most Haunted** leaderboard ranks the deadliest bugs (by the hours it took to kill them), the languages with the most zombies, the most common causes of death and the most resurrected chain.

![The Most Haunted leaderboard: the most resurrected chain, the deadliest bugs, the most haunted languages and the most common causes of death](https://raw.githubusercontent.com/jashanpreet-k/bug-graveyard/main/docs/post/leaderboard.png)

### Inside the Studio

This is where most of the Sanity work lives.

**1. A bug's life, as custom document actions.** A bug moves through `💀 suspected dead → 🩹 fix merged → 🪦 buried`. Three custom document actions drive it, and they sit right after Publish in the document's "…" menu:

- **🩹 Mark fix merged** sets the status and stamps today's date (in UTC) as the fix date.
- **🪦 Declare buried** stays disabled until the fix has held for **7 days**. Until then its label is a countdown like *"Can bury in 4 days"*.
- **🧟 Report resurrection** asks *"Are you sure? This bug will rise from its grave."*, then creates a new, already published zombie linked to the old grave, and opens it so you can write its epitaph.

![The Studio's "…" menu on a bug whose fix merged 3 days ago: "Mark fix merged" and "Can bury in 4 days" are disabled, "Report resurrection" is available, followed by Duplicate and Delete](https://raw.githubusercontent.com/jashanpreet-k/bug-graveyard/main/docs/post/studio-lifecycle-actions.png)

*A (temporary) bug whose fix merged 3 days ago: it can't be buried yet, but it can still come back.*

**2. A live Tombstone view.** Every bug opens with two tabs, "Editor" and "🪦 Tombstone". The Tombstone tab renders the *same* React component the website uses. In split pane the stone updates on every keystroke, with an epitaph counter (140 characters max).

**3. A graveyard sidebar:** 🪦 All graves, 🧟 Zombies, 💀 Suspected dead, 🩹 Fix merged and ⚰️ Buried, then Languages and Causes of death.

## Code

💻 **Repository:** https://github.com/jashanpreet-k/bug-graveyard

Where to look:

- `sanity/actions/lifecycle.tsx`: the three document actions
- `sanity/schemaTypes/bug.ts`: the bug schema
- `sanity/lib/queries.ts`: every GROQ query, typed with Sanity TypeGen
- `sanity/components/TombstoneView.tsx` and `components/Tombstone.tsx`: the Studio view and the stone it shares with the site
- `NOTES.md`: the phase-by-phase build log this post is based on

## My Build Process

I built Bug Graveyard with **Claude Code** (in VS Code), one phase at a time: setup, schema, homepage, grave page, first deploy, lifecycle actions, the Studio view, the leaderboard and importer, content, and a polish pass. For each phase I wrote the brief, tested the result in the browser, and decided what to keep or change. Claude Code wrote most of the code, ran the builds, tests and deploys, and added an entry to a build log (`NOTES.md`) at the end of every phase.

**Stack:** Next.js 16 (App Router, TypeScript, Tailwind CSS v4), Sanity Studio v5 embedded at `/studio`, `next-sanity`, deployed on Vercel.

### The prompts that worked

Short phase briefs with explicit rules and a test step. Here's part of the Phase 5 brief, for the lifecycle actions:

> 2\. "🪦 Declare buried": enabled only when status = fix-merged AND at least 7 days have passed since fixMergedAt. When disabled, the label/title says how many days are left (e.g. "Can bury in 4 days"). Sets status = buried and buriedAt = today, then publishes.
>
> Rules:
> - Use dates in UTC like the rest of the app.
> - Handle drafts correctly (act on the published doc, don't leave stray drafts).
> - Make the 7-day rule a single constant so I can mention it in the write-up.
>
> Test it end to end with temporary test bugs (delete them after) …

Claude Code tested that phase against a production build, with headless Chrome clicking the real Studio buttons: 34 checks across five temporary bugs, which were all deleted afterwards. It also went beyond the brief in a couple of places, and I kept those changes. My brief said each action should "then publish". Instead, the actions write straight to the published document in one change guarded by its revision, and they're disabled while the bug has unpublished edits, because that draft would later overwrite the new status. And "Mark fix merged" also works on a zombie, so a zombie can start a lifecycle of its own.

### The one that didn't

Before the polish pass, I asked Claude Code to look through the other projects on my Mac for bugs I'd really fixed, so that a few graves could be real. It found no bug-fix commits to use. So I dropped that and kept the classic bugs.

### Where it got stuck, and how we course-corrected

Most of these only showed up in a production build or on the live site, not in `npm run dev`.

- **Publishing didn't reach the site.** In a production build, publishing from the Studio didn't update the site, and an open tab stayed one change behind. There were two causes. The Studio route had no `<SanityLive />` to clear the cache, and in production next-sanity revalidates with the `'max'` cache profile, which serves the stale page one more time. The fix: `<SanityLive />` in the Studio layout too, plus a custom action that calls `updateTag`, which expires the cache immediately. `npm run dev` hid both problems.
- **The first Vercel deploy failed** with `No Output Directory named "dist" found`. The Vercel project had been created with the "Other" framework preset. A `vercel.json` that sets `"framework": "nextjs"` fixed it.
- **Scripts silently skipped drafts.** With this API version, a query that doesn't name a perspective gets `published`, so a cleanup script would never have found `drafts.*` documents. Scripts that need drafts now ask for `raw`.
- **"Report resurrection" flickered disabled.** Its "has this grave already risen?" check restarted every time the document changed, and it blocked the button while it ran. Now the button is only disabled once a zombie is known to exist, and it checks again when you confirm.
- **The site's CSS leaked into the Studio.** The root 404 page imported the site's global CSS, and a root not-found page's styles load on every route, so Tailwind ended up inside `/studio`. A scoped CSS module fixed it.
- **The build prerendered deleted bugs.** `generateStaticParams` read the slug list from Next's local fetch cache, which still held old test bugs. It now fetches the slugs with `cache: 'no-store'`.

Two traps we avoided on purpose:

- **The timezone bug could have had a timezone bug.** Sanity `date` fields are plain strings like `"2026-03-29"`, with no timezone. Formatting them in the visitor's timezone would make every bug die a day early for anyone west of Greenwich, including on the timezone bug's own tombstone. So every date is formatted in UTC.
- **A dot in a document ID makes it private.** Sanity treats a dotted ID as a private path (that's how `drafts.` works), so a public dataset won't serve `language.typescript` without a token. The seed used dashed IDs like `language-typescript` from the start. A quick test while writing this post confirmed it: a published document with a dotted ID didn't appear in a public query.

### Reaching past the Studio: Workflows

I also asked Claude Code to find out, in a 3-hour time box, whether Sanity Workflows could run this lifecycle. It can model it. On a separate local branch, the lifecycle is two workflow definitions (one for a bug and one for a zombie), and "Declare buried" is gated by a GROQ requirement instead of a timer:

```groq
dateTime($now) >= dateTime($fields.fixMergedAt) + 604800 // 7 days, in seconds
```

`npx sanity-workflows deploy --check` passes for both definitions, and 4 tests pass against the real engine running in memory with a controlled clock. Burial is refused until exactly 7 days have passed.

I didn't merge it. Workflows is in early access (0.35), its Studio plugin needs Studio 6 while this project runs Studio 5, and effects need a runtime I'd have to run myself. A proper integration also means deciding whether the workflow or the bug's own `status` field is the source of truth, which Claude Code estimated at 1.5 to 2 days. The live site still runs on the document actions.

## Sanity Project Details

- **Project ID:** `rzjmw6lg`
- **Dataset:** `production` (public). Try it: [every bug, as JSON](https://rzjmw6lg.api.sanity.io/v2026-09-28/data/query/production?query=*%5B_type%20%3D%3D%20%22bug%22%5D%20%7C%20order%28bornAt%20asc%29%20%7Bname%2C%20status%2C%20epitaph%7D)

There are three document types: `bug`, `language` and `causeOfDeath`.

### The schema: zombies are documents, not checkboxes

The central decision: **a zombie is a whole new `bug` document that points to its previous life.** It isn't a status flag on the old one.

```ts
// sanity/schemaTypes/bug.ts (simplified)
defineField({
  name: 'status',
  type: 'string',
  options: {list: ['suspected-dead', 'fix-merged', 'buried', 'zombie']},
}),
defineField({
  name: 'previousLife',
  type: 'reference',
  to: [{type: 'bug'}],
  hidden: ({document}) => document?.status !== 'zombie',
}),
defineField({name: 'timesResurrected', type: 'number', readOnly: true}),
```

Why:

- **Every death keeps its own history.** A zombie gets fixed and buried again, so it needs its own dates and its own epitaph.
- **Zombies of zombies work for free.** A chain is just references pointing backwards.
- **"Disturbed" isn't stored anywhere.** GROQ works it out by asking whether any bug points at this one:

```groq
*[_type == "bug"]{
  ...,
  "disturbed": count(*[_type == "bug" && previousLife._ref == ^._id]) > 0
}
```

- **Languages and causes of death are references**, so filters and the leaderboard count them reliably. The whole leaderboard is **one GROQ query**.
- **The fix date, the burial date and the resurrection counter are read-only in the Studio.** There, only the lifecycle actions set them, so they record what actually happened rather than what someone typed. (`readOnly` only applies to the Studio: the importer script sets historical dates from a file.)

### How document actions work

Every button at the bottom of a Sanity document (Publish, Delete…) is a *document action*, and you can add your own. An action is a small React component: Sanity passes it the document's current state and it returns a button (label, disabled, tooltip, onHandle, optional confirm dialog). You register actions in `sanity.config.ts`. Because an action is a component, it re-renders whenever the document changes, which is how "Can bury in 4 days" stays up to date without any extra code. Actions run in the browser as the signed-in editor, with their permissions, so there's no API token in the code.

### Live everywhere

`sanityFetch` plus `<SanityLive />` push Studio edits to open tabs in about 3 seconds. A signed Sanity **webhook** refreshes the cached site when nobody has it open (about 6 seconds).

## Agent Session

The Claude Code session behind this build, with secrets redacted:

## What I learned

- **Document actions go a long way.** They're just React components that re-render with the document, so a live countdown like "Can bury in 4 days" needs no refresh logic. And they run as the signed-in editor, so there's no token in the code.
- **Test against a production build from day one.** `npm run dev` hid both live-update bugs. I'd also connect Vercel to GitHub at the start: I never added the login connection, so every deploy was a manual `vercel deploy --prod`.
- **Workflows can model this lifecycle,** and the in-memory test engine makes a rule like "7 days" easy to test by moving the clock. But a real integration needs Studio 6 and a runtime, so for now it stays an experiment.
- **Directing an agent works best in small phases,** each with a clear brief, a test and a build-log entry. That log is also what this post was fact-checked against.

Thanks for reading. May your bugs rest in peace. 🪦
You

do all this by youself

Agent

You've approved doing the pre-publish steps yourself, so I'll do them: upload and embed the agent session, and add a cover. I'll still stop for the final "publish", since you set that word as the only go-ahead for making the post public. First I'm checking whether DEV's API can upload agent sessions, and what the embed looks like in other posts.

Agent
Agent

GET /api/agent_sessions exists and returns an empty list for your account, so there's probably an upload endpoint too. Next I'm reading Forem's open-source controller to find its parameters.

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

That's only a little noise to strip: 29 pasted-content wrappers (the prompts inside are kept), 7 IDE file notes, 1 task notification, 6 meta records and the compaction summary.

Agent
Agent
Agent
Agent
719 of 719 messages