DEV Community: JASHANPREET KAUR

Nikal: A local AI agent that remembers your comfort—and tells you to go outside

JASHANPREET KAUR — Sat, 10 Oct 2026 19:23:46 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

In Gwalior, “go outside” needs a time attached.

A forecast retrieved on 11 October at 3:17 PM IST shows why. At 4 PM it gave 32.6°C and a forecast US AQI of 108. At 5 PM it gave 31.5°C and an AQI of 120. The afternoon cooled as the air got worse.

With limits of 32°C and AQI 100, neither hour passed. Nikal's card for that run said: “Nothing suitable left today. Tomorrow 7:00 AM IST (12 Oct) looks best.” That is a forecast-based suggestion, not a confirmed outing.

What I Built

Nikal means “go out” in Hindi. It is a small TypeScript CLI that checks Gwalior's hourly heat, air quality, rain, UV and daylight against comfort limits I have saved. A local Qwen 2.5 7B model, running through Ollama, then picks one hour and one mapped walking place from what passed, and an optional SerpApi search looks for outdoor events. It prints one card and exits; if nothing passes today it checks tomorrow, and if neither day qualifies it says so without relaxing the limits.

Demo

Recorded on 11 October 2026 at 3:43 PM IST with VHS. Inference waits were shortened; outputs come from actual CLI runs. Frames are hidden during model and network waits; the output is unedited. Watch the same recording as a video on YouTube.

Persistent memory: 5 PM to 7 AM

Synthetic forecast and places, real local Qwen inference. Each command below runs in a separate CLI process against the same isolated demo profile. The cards label the fixture OFFLINE FIXTURE · synthetic data.

Command	Recorded result
`nikal --fixture` with defaults	Qwen selects 5 PM, the hour with the lowest forecast AQI.
`nikal chat "I dislike heat above 30°C and prefer mornings."`	Persists `maxTemp: 32 → 30` and `period: "any" → "morning"`.
`nikal prefs show`	A new process retrieves 30°C + morning from Mastra working memory.
`nikal --fixture` again	Same synthetic facts, new process: Qwen now selects 7 AM.

The forecast did not change between the first command and the last. Only what Nikal remembered did.

An actual terminal frame from the recording. The fixture facts are synthetic; the model inference, tool call and SQLite persistence are real.

The separate live segment

The recording ends with one live run from approximate Gwalior city-centre coordinates, with live Open-Meteo conditions and live Overpass places. It recommends 12 October, 7 AM IST: 25°C and forecast US AQI 93.

This segment ran without a SerpApi key. It shows no search results. The keyed evidence further down comes from a different, earlier run.

Outdoor trial

I have not completed an outdoor trial yet.

Code

GitHub: jashanpreet-k/Nikal, MIT-licensed.

The latest npm run check, on 11 October at 6:50 PM IST, passed type-checking, the build and 122 tests. The tests use mocked or synthetic model and API responses. The real runs are kept apart in the verification report, the curated evidence excerpt and the recording source scripts/demo.tape.

Built on 10–11 October 2026. Solo: @jashanpreet_kaur_917e774f, with AI coding assistance; no human teammates.

Try it

You need Node 22.13 or newer. The four commands below need nothing else: no Ollama, no API key, and no network once the install has finished.

git clone https://github.com/jashanpreet-k/Nikal.git
cd Nikal
npm ci && npm run build && npm link
nikal --fixture --no-model

That prints a card from an invented forecast with the model switched off. For the real thing, install Ollama, run ollama pull qwen2.5:7b, and then:

Type this	What it does
`nikal doctor`	Checks that the local model answers.
`nikal --fixture`	The invented forecast again, with local Qwen choosing.
`nikal`	The live card: Gwalior's forecast and mapped places.
`nikal chat "I dislike heat above 30°C and prefer mornings."`	Saves preferences from plain words.
`nikal prefs set --radius 1.5`	Only suggests places within 1.5 km.
`nikal prefs show`	Shows what it remembers. `nikal prefs reset` restores the defaults.
`nikal --help`	Lists every command and limit.

Tested on macOS with Node 24; other systems are untested. Preferences are stored on your own machine, in ~/.nikal.

How I Built It

What Mastra does here

I wanted a small local model to make the choice without being trusted with any fact.

Tools. Weather, places and events are each a createTool with Zod input and output schemas, so a malformed API response is rejected before it reaches the card.
Parallel workflow with a join. fetchConditions → [findPlaces ‖ findEvents] → joinRetrieval → agentDecides → formatCard. Retrieval always runs in code. Places and events fail independently: in recorded takes where every map server failed, the card still gave a time.
Local agent. Qwen sees only the hours and places that passed my limits and returns IDs and a reason code. Nikal validates them, allows one repair, then labels a deterministic fallback. Numbers and links on the card come from retrieved data.
Persistent memory. Preferences live in resource-scoped Mastra working memory on LibSQL, a local SQLite file. The first workflow step reads them before anything is fetched, so a saved limit changes which hours reach the model.
Staged preference writes. The chat tool only stages a validated patch. Nikal commits it after generation succeeds, then prints the persisted old and new values, not the model's reply.

Studio capture of a synthetic fixture run with real local inference: six workflow steps, including the parallel retrieval branches and their join. agentDecides took 2.52 seconds. Open the full Studio screenshot.

What broke

Overpass. Five consecutive recording takes had all three public map mirrors fail. The primary server was measured responding in 5.7 to 8.4 seconds against an 8-second timeout, so the timeout became 15 seconds before the kept take. The failures also exposed a card bug: warnings shared a 350-character cap, and one card ended with “event search skippe”. Each warning now gets its own line.

SerpApi. The google_events engine no longer accepts new requests, so Nikal uses SerpApi's Google Search engine. My first parser read only Google's optional events box and ignored organic results. The corrected one reads both, and treats every result as a lead until its source page corroborates a dated event.

Two improvements made after the recording

On a rollover to tomorrow, the card now adds one line saying why today's remaining hourly slots failed. From a synthetic test: “No remaining daylight hourly slot passes today: forecast AQI at 5 PM is 110, above your limit of 100.” It is derived from that run's own forecast hours and saved limits.

In an interactive terminal, Nikal also shows a short progress note while it works and prints the answer line in bold. The card's text is unchanged.

Both are covered by automated tests on synthetic readings and the offline fixture, with no new live or real-model run. The recording above predates both and shows neither.

Keyed SerpApi evidence, separate from the GIF

An earlier keyed workflow returned three unconfirmed leads, zero corroborated events, and no model-selected lead. Its search response was fetched on 11 October at 12:25 AM IST for outdoor events walks runs street markets in Gwalior this week.

A later offline inspection of that stored response, with no new search, found no events box and these leads: a Facebook topic page, a run organiser's archive and an Instagram reel. The reel's snippet contained dates, but a snippet is not a dated, matching event on a source page, so the card said “No verified event found.”

Limitations

Forecast AQI is modeled, and forecasts change between runs. The limits are comfort filters, not medical guarantees.
Choices are hourly slots in daylight, at least 30 minutes before sunset.
Distances are straight-line. A mapped place does not establish access, opening hours or safety.
An event counts only with matching, dated Event data on its source page, and “this week” ends on Sunday night. No recorded event has been corroborated.
Qwen 2.5 7B is the only model verified here.

Why Does Open Innovation Matter?

Open weights make the local part possible: Qwen 2.5 7B runs on my laptop, so the prompt that holds my preferences stays there. Published weights are not open-source software; Mastra, the AI SDK, Ollama and Nikal are.

Open data makes the card checkable. The park on the card is an OpenStreetMap entry anyone can open, and Nikal's selection validation is open to review.

Model inference and preference memory stay on the laptop. Retrieval is external: Open-Meteo and Overpass receive coordinates, SerpApi receives a city-level query, and source sites receive page requests. Paid model/API charges were ₹0 within free-tier limits, excluding hardware, electricity and network costs.

Prize Categories

Best Use of Mastra — $100 USD (primary). Tools, a parallel workflow with a join, a local agent and persistent working memory form the core of Nikal. The recorded synthetic-facts demonstration shows a chat-saved preference changing the recommendation from 5 PM to 7 AM across separate processes.

Best Use of SerpApi — $100 USD (secondary). Google Search supplies source-linked leads for Nikal's separate corroboration step. The earlier keyed workflow returned three unconfirmed leads, zero corroborated events and no model-selected lead. The unkeyed GIF supplies no SerpApi evidence.

Credits: Mastra, AI SDK, Ollama, Qwen, Open-Meteo and CAMS, © OpenStreetMap contributors and Overpass, SerpApi, and VHS.

Same Kind of Bug Isn't the Same Bug: Where AI Models Get Fooled

JASHANPREET KAUR — Tue, 06 Oct 2026 16:01:08 +0000

This is a submission for the Kaggle Benchmarking Challenge

TL;DR

One confident wrong comment cut accuracy from 145/153 to 121/153 across 9 models. An irrelevant comment of similar length barely mattered.

The strongest models didn't move; gpt-5.4-nano fell from 11/17 to 2/17.

Models confuse "same kind of mistake" with "same bug": 100.0% right when it really was the same code, 65.4% when it wasn't.

In a controlled test across 9 models, adding a confident wrong diagnosis reduced accuracy from 145/153 to 121/153 (15.7 percentage points). The effect was uneven: gpt-6.1-sol, claude-opus-5-5 and gemma-4-31b didn't drop at all, while gpt-5.4-nano fell from 11/17 to 2/17. The follow-up used 9 of the original 14 models; Sonnet 4.5 was unavailable, and Qwen hadn't finished at the results cutoff. Each comparison used the same report, with only the comment changed.

I gave AI models (14 in my own runs, 17 on the official Kaggle leaderboard) a list of fixed bugs and one new bug report, and asked: is this an old bug coming back, or a new one? Most handle it well until the new bug is the same kind of mistake, made again in different code. In my runs, models missed 18 of 42 attempts on those cases, almost always by naming the old bug with the same kind of mistake. One model wrote that the bug was "now reoccurring in the night audit due to the scheduler change": it saw the code was different and still called it the same bug.

Across 672 attempts (14 models × 48 cases), models got 592 right. Of the 80 misses, 55 were false zombies: a new bug called a regression. Only 17 went the other way. The other 8 were 7 wrong bug ids and 1 unreadable reply. In these runs, the errors mostly went one way: the models labeled new defects as old regressions.

What I Benchmarked

Why I built it

For the DEV Sanity Challenge I built Bug Graveyard, an app where fixed bugs get "buried" and a Zombie Detector warns you when one rises again. The detector is a simple formula: 25 points for the same cause, 15 for the same language, 25 for the same component, and up to 35 for shared keywords. At 60 or more, it's a zombie.

It worked in my demo, but I kept wondering whether an AI model would do better. ZombieBench is my attempt to answer that with numbers.

How ZombieBench works

Every case gives the model a history of fixed bugs (name, cause, language, component, symptoms and fix summary) and one new bug report. The model must answer in JSON: {"verdict": "regression" or "new", "bug_id": ..., "reason": ...}. A case passes only if both the verdict and the bug id are right.

There are four case types:

Type	What it is	Right answer
A	Clear regression: the same bug, described in similar words	the old bug's id
B	Reworded regression: the same bug in a user's own words	the old bug's id
C	Keyword decoy: sounds like an old bug, but the cause is different	new
D	A new bug (in the harder tiers, the same kind of mistake in different code)	new

And three tiers:

Easy: 12 cases with 5–8 fixed bugs each.
Hard: 24 cases with 12–15 fixed bugs. Every right answer has 2–3 siblings (same component or same cause), so the model must pick the exact id. Reports are messy, with log lines, side issues and wrong guesses.
Expert: 12 cases with 25–30 fixed bugs and similar-sounding names. Some have twin candidates that only a fix-summary detail separates, two issues in one report, or a planted wrong diagnosis: a developer or support comment that confidently names the wrong bug.

The tiers came from testing. My first 12 cases were too easy (gemini-3.8-flash got 12/12), so I added the hard tier. After gpt-5.5 got 36/36 on easy plus hard, I added the expert tier.

Example (zb-41, expert B). Two of its 27 fixed bugs:

#3325 Average buy price wrong after a stock split: the quantity wasn't multiplied, so holdings showed a fifth of the shares. Fixed in CorporateActions.apply_split().
#3374 Average buy price wrong after a bonus issue: holdings showed twice the shares at the old average price, so the app showed a large loss. Fixed in CorporateActions.apply_bonus().

The new report:

Last month I got free Infosys shares, one for every one I already had. Since then the app says I'm down ₹42,000, which is about what I put in. It's as if the app thinks I paid for the free ones too. Support note on this ticket: 'The split bug, #3325, is back; splits and these go through the same code.'

Free shares, one for one, is a bonus issue, and the symptom matches #3374. The right answer is regression #3374; the support note is a deliberately planted incorrect diagnosis.

How I made it fair

Invented data. Every project, bug and report is made up. Nothing is copied from GitHub or an existing dataset.
Graded by code, not an LLM judge. The answer must match exactly, and a reply that isn't the JSON I asked for counts as wrong. A call that fails (rate limits, or an empty reply from the model proxy) is retried with backoff and then reported as an error, not scored.
Leak checks. My validator fails if a cue phrase like "again", "still" or "used to" (or a missing component) appears only in regressions or only in new bugs. Otherwise a model could score just by spotting "again".
Blind audits. A fresh AI agent that never saw the answer key answered every case. On the first 36 it agreed on 34. Its disagreements showed that a report blaming a new feature for repeating an old mistake reads as a new bug, so I reworded 6 cases (no answers changed), and a second blind audit agreed on all 6. On the expert tier it agreed on 12 of 12; I fixed its one doubt and re-audited that case. The original audit counts are historical build-log claims; their raw answers were not archived. Follow-up audit prompts, answers and agreement checks are archived in the repository.
Baselines. Always answering "new" scores 24/48, so that's the floor to beat. My Bug Graveyard formula scores 15/48, below the always-new baseline.

Models Tested

I picked a spread on purpose: frontier models, plus the smaller and open-weight models that are cheap enough to run on every incoming ticket, because those are the ones a team would actually use for triage.

I ran 16 models, from frontier down to small and open-weight ones, on the same 48 cases, once each. Two didn't finish: xai/grok-4.6 returned "404 – model not found" on every call, and I stopped deepseek-r1-0528 after 3 slow cases. The 14 that finished had no API errors.

My runs (per tier, with every miss saved)

Model	Easy (12)	Hard (24)	Expert (12)	Expert D (3)	Total (48)
gpt-6.1-sol	12	24	12	3	48
claude-opus-5-5	12	24	12	3	48
gemini-3.1-pro-preview	12	24	12	3	48
gpt-5.5	12	24	12	3	48
gemini-3.8-flash	12	24	12	3	48
gemma-4-31b	12	23	12	3	47
gemini-2.5-flash	12	22	8	1	42
claude-sonnet-4-5	12	22	7	0	41
gpt-5.4-mini	12	21	8	2	41
gemini-3.1-flash-lite-preview	12	21	8	0	41
gpt-oss-20b	12	19	9	1	40
claude-haiku-4-5	12	21	6	0	39
qwen3-235b-a22b-instruct	11	17	7	0	35
gpt-5.4-nano	9	13	4	2	26
Always answering "new"	6	12	6	3	24
Bug Graveyard formula	7	5	3	3	15

Official Kaggle leaderboard

This is the saved leaderboard snapshot from publication: Kaggle's own run, one run per model, scored as accuracy over answered cases.

Model	Kaggle score
GPT-6.1 Sol	1.00
GPT-5.5	1.00
Claude Opus 5.5	1.00
Gemini 3.1 Pro Preview	1.00
Gemini 3.7 Flash	1.00
Gemini 3.5 Flash	1.00
Gemma 4 31B	1.00
GLM-5	0.98
Claude Opus 4.5	0.97
GPT-5.4 mini	0.88
Claude Sonnet 4.5	0.88
gpt-oss-20b	0.88
Gemini 3.1 Flash-Lite Preview	0.85
Claude Haiku 4.5	0.81
Qwen 3 235B A22B Instruct	0.73
Gemini 2.5 Flash	0.73
GPT-5.4 nano	0.55

gpt-oss-120b and Gemini 3.8 Flash were still running on Kaggle when I published, so they aren't in this archived table.

Note: the original 48-case findings and quotes come from my own notebook runs, which saved every miss; Kaggle's official leaderboard run is separate. The controlled follow-up below was run through Kaggle's CLI and saved every response. On a 48-case scale, the scores differed by about 7 cases between runs (Gemini 2.5 Flash: 42/48 in my run, 0.73 or about 35/48 on Kaggle), so small gaps between models aren't meaningful.

Gemini 3.7 Flash and Gemini 3.8 Flash are different models; 3.8 Flash's official run hadn't finished.

Every miss from my runs. The dark column on the right is expert D: new bugs that repeat an old kind of mistake in different code.

Findings

1. "Same mistake, different code" is the hardest category

Expert D cases are new bugs that repeat an old bug's kind of mistake in code its fix never touched, and the report holds the clue. In zb-46, a hotel's new night-audit scheduler starts at 00:00 UTC, so early walk-ins land on the previous day, while the occupancy report (where old timezone bug #3129 was fixed) shows them correctly.

Models missed expert D cases 18 times out of 42 (43%). The next hardest categories were at 21%. In 16 of the 18 misses, the model named the old bug with the same kind of mistake. From qwen3-235b:

"...which is the same underlying timezone cause as in bug #3129, now reoccurring in the night audit due to the scheduler change."

It noticed the different code and still called it the same bug.

Nine more same-mistake cases

I added 9 different-code cases and 9 matched same-code regressions using the same histories. Different-code accuracy was 53/81, or 65.4% (Wilson 95%: 54.6–74.9%). Same-code accuracy was 81/81, or 100.0% (Wilson 95%: 95.5–100.0%). Models called 28/81 different-code cases regressions: a false-zombie rate of 34.6% (Wilson 95%: 25.1–45.4%). Both members were correct in 53/81 matched model–case pairs.

The matching guards against rewarding a model that always says “new.” These cases use explicit source traces and a repeated scaffold; they extend coverage, but their difficulty is not calibrated to the original expert tier.

2. Five models picked the bug a wrong support comment named

In zb-41 (the example above), 5 models selected the bug ID named in the support note: gpt-5.4-nano, gpt-5.4-mini, gemini-2.5-flash, gpt-oss-20b and qwen3-235b. From gpt-5.4-mini:

"This matches the same corporate-action quantity/price adjustment defect as #3325, and the support note confirms splits and bonus issues share the same code path."

The expert tier has 5 planted wrong diagnoses. gpt-5.4-nano followed all 5, and no other model followed any of them except zb-41's. In zb-44 a developer writes "definitely #3318 again", while the alert log in the same report shows the alerts firing on time. From gpt-5.4-nano:

"The developer comment and matching symptom indicate the same queue/batch processing issue from #3318 has reappeared on iOS."

The follow-up: same report, different comment

Each of 9 models saw the same 17 reports in separate chats under five conditions: no comment (L0), an irrelevant confident meeting note (P), a hedged wrong diagnosis (L1), a confident wrong diagnosis (L2), and a developer claiming to have fixed that bug personally (L3). Only the terminal comment line changed; the correct answer did not. These are first-run results.

Both rate columns include descriptive Wilson 95% intervals.

Comment	Correct: count; rate [95% CI]	Wrong target: count; rate [95% CI]
L0	145/153; 94.8% [90.0–97.3]	6/153; 3.9% [1.8–8.3]
P	143/153; 93.5% [88.4–96.4]	6/153; 3.9% [1.8–8.3]
L1	138/153; 90.2% [84.5–94.0]	6/153; 3.9% [1.8–8.3]
L2	121/153; 79.1% [72.0–84.8]	18/153; 11.8% [7.6–17.8]
L3	122/153; 79.7% [72.7–85.3]	27/153; 17.6% [12.4–24.5]

On the paired L0/L2 comparison, 24 answers changed from correct to wrong and 0 changed from wrong to correct. The observed accuracy drop was 15.7 percentage points. The placebo accuracy change was -1.3 points; wrong-target selection changed by 13.7 points from L1 to L3.

Among the original planted-diagnosis cases, 12/45 model–case pairs were wrong at L2 and correct at L0. At L0 and P, “wrong target selected” means the ID named in the other conditions: there is no diagnostic comment to follow.

The effect was uneven: claude-opus-5-5, gemma-4-31b, gpt-6.1-sol had no observed L0/L2 accuracy drop. The largest drop was for gpt-5.4-nano, from 11/17 to 2/17.

One illustrative L3 answer from google/gemini-3.1-flash-lite-preview on zf1-zb-22-L3. The correct answer was regression #2522; the comment named #2511:

The report shows a value magnitude error consistent with unit conversion issues, and the developer confirmed the fix for #2511 is failing.

This comparison measures the effect of the whole inserted comment in this synthetic task. The L1-to-L3 comparison changes confidence and claimed authority together, so it cannot separate their effects. The placebo controls for one kind of extra text, not every semantic difference.

3. Right rejection, wrong answer

In zb-37, a developer blames #3108 (booking-page rounding), but the evidence points to the checkout invoice: #3174. Six models correctly rejected #3108 and then answered "new", and three of them named #3174 in their own reason. From Claude Sonnet 4.5, which answered "new":

"This is a rounding issue in checkout invoices (component: invoices) matching bug #3174, not a regression of #3108 which was about booking confirmation page totals in the booking-engine component."

It found the right bug and still didn't pick it. Part of this is my fault; see the limits below.

4. A 31B open model kept up with the frontier

gemma-4-31b scored 47/48 in my run and 1.00 on Kaggle's official run. Its only miss in my run was zb-26, where a results page shows 88 marks out of 98 as 88%:

"The report describes percentages being rounded down (88/98 displayed as 88%), which is identical to the defect in bug #2311."

But 88/98 is 89.8%, so rounding down would show 89%. The real bug is a wrong denominator.

5. The original top tier is solved, so the rest is where it matters

Perfect scores in my runs (48/48): gpt-6.1-sol, claude-opus-5-5, gemini-3.1-pro-preview, gpt-5.5 and gemini-3.8-flash. On Kaggle's official run (1.00): GPT-6.1 Sol, GPT-5.5, Claude Opus 5.5, Gemini 3.1 Pro Preview, Gemini 3.7 Flash, Gemini 3.5 Flash and Gemma 4 31B. ZombieBench can't rank these. Below them, my runs go from 47 down to 26 and Kaggle's from 0.98 (GLM-5) to 0.55 (GPT-5.4 nano), and in my runs the misses cluster in the same places: same mistake in different code, planted diagnoses and keyword decoys. If you'd triage bug reports with a smaller model, those are the failure modes to check.

What I'd do if I used AI for bug triage

Don't let a "regression" verdict close a ticket on its own: most misses were false zombies, so check which code path the old fix touched.
Strip or flag comments that name a bug: in zb-41, five models selected #3325, the ID named in the support note. That original observation alone was correlational; the follow-up above compares standardized comments with clean versions of the same reports.
Use a frontier model, or check the small one: the top models got every original case right, and the cheaper ones are where these mistakes showed up. These single runs on synthetic cases don't establish real-world reliability.

Honest limits

Follow-up limits: the added cases and comments are synthetic. All 9 included models have one full follow-up run; 4 have a second Experiment 1 run. Across valid comparable responses, 318/340 answers were identical (93.5%; Wilson 95% 90.4–95.7%), and 22 changed. Repeat agreement is not proof of general reliability. Pooled Wilson intervals treat observations as binomial trials and do not model dependence from shared cases or models. The headline uses first runs only. Only one easy/hard type-C case was answered correctly by every model, so I used the two least-missed type-C cases as well. Each case's clean version was re-run in the same experiment, so the comparison is still within-run. Original planted comments were moved to the same terminal position; zb-39 now explicitly names its diagnosis’s ID.
Run correction: the CLI initially bound nano explicitly, so one run scheduled under Gemini actually called nano. Saved SDK metadata identified the error. The platform’s extra initialization model is excluded from the headline comparison. That independent nano run supplies its repeat comparison; its extra expansion answers are excluded. The corrected task uses Kaggle’s selected-model placeholder, and actual model IDs are checked before pooling.
Availability: Sonnet 4.5 was absent from Kaggle’s follow-up model catalog and was not replaced.
Incomplete runs excluded from pooled comparisons: qwen/qwen3-235b-a22b-instruct-2507. Partial outputs remain in the repository.

Follow-up model	Full first runs	Full Experiment 1 repeats	Changed / valid comparable answers
claude-haiku-4-5	1	1	1/85
claude-opus-5-5	1	0	Not repeated
gemini-2.5-flash	1	0	Not repeated
gemini-3.1-flash-lite-preview	1	1	2/85
gemma-4-31b	1	0	Not repeated
gpt-5.4-mini	1	0	Not repeated
gpt-5.4-nano	1	1	9/85
gpt-6.1-sol	1	0	Not repeated
gpt-oss-20b	1	1	10/85

It's small: 48 cases, and the expert tier has only 3 per type, so one case is a third of an expert type.
Scores vary between runs. Gemini 2.5 Flash scored 42/48 in my notebook run and 0.73 (about 35/48) on Kaggle's official run, and gpt-5.4-nano scored 24/36 and then 22/36 on the same 36 cases in two of my runs. Small gaps between models aren't meaningful.
zb-37 has misfiled metadata. Its report is filed under booking-engine and TypeScript, while the answer lives in invoices and Python. I meant it as realistic, but it pushes models toward "new", as gemini-2.5-flash said: "it is reported in a different language (TypeScript vs Python) and component (booking-engine vs invoices), indicating it's a new defect".
AI help. I wrote the cases and built ZombieBench with help from Claude Code, reviewed every case myself, and checked every number against the results files. Blind AI audits checked the answer key, but the cases still come from one person's idea of fair.

What I'd measure next

Next I would test less templated reports from independent authors and repeat the comparisons across more sampling settings.

An agentic version: give the model git log, git blame and grep over a small sandbox repo with a tool budget, and check whether investigating reduces false zombies.
Procedural renaming of components, ids and comment authors at runtime, so models can't lean on memorized keywords.

My Benchmark

Kaggle task (official leaderboard): https://www.kaggle.com/benchmarks/tasks/jashanpreetkaur24/zombiebench
Controlled follow-up task: https://www.kaggle.com/benchmarks/tasks/jashanpreetkaur24/zombiebench-followup
GitHub (code, all 48 cases, and every model's misses with its reason): https://github.com/jashanpreet-k/zombiebench

Model names in "My runs" are shortened. The original full Kaggle model ids and both original leaderboards are in the repo's results/ folder. Follow-up raw responses, model identities, intervals and per-model stability are in followup/.

Bug Graveyard: where fixed bugs are buried, and regressions rise as zombies

JASHANPREET KAUR — Tue, 29 Sep 2026 09:06:15 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

🪦 TL;DR for judges

The story: every fixed bug is buried as structured content: what it looked like, where it lived, what killed it and how it was fixed. The graveyard remembers, so it can catch what comes back. When a new bug arrives, the Zombie Detector compares it with the graves and flags a possible resurrection using four signals you can check yourself, not an "AI similarity %". A person confirms it. Jump to the detector.

Working app: the live site needs no login, and the 30-second judge path below shows the detector working live.

Schema: a zombie is a whole new bug that points to its previous life. "Disturbed" and "👻 Haunted" graves are worked out in GROQ, never stored, and AI suggestions and public reports sit in their own fields until a person approves them. See Sanity Project Details.

Write-up (quality and honesty): My Build Process has the prompts that worked, the one that didn't, every place it got stuck and what's not live. The Claude Code session is embedded below.

Beyond the Studio (bonus): in the Studio, custom document actions, a custom Tombstone view and sidebar · the Morgue, an App SDK app · two Sanity Functions (a daily gravedigger and the coroner) · Agent Actions (Prompt) · a Workflows experiment on a branch (not live).

Why I built this (in my own words)

Honestly, this project didn't start as a project. It started with me looking for a way to make my first $40 from code.

I'm a 7th semester student in India, and I spent a few days going through bounty sites. Every bounty that looked doable was already taken, closed, or had 15+ people fighting over it. Somewhere in that search I found this challenge, and Path 2 said "something strange", which felt like permission to stop being sensible.

The idea came from all those closed issues I was reading. Bugs get fixed, everyone moves on, and a few months later the same bug is back with a new ticket number. Nobody remembers it was here before. So I thought: what if fixed bugs actually got buried, and when one came back, it came back as a zombie?

I want to be upfront about how it was built. I didn't write most of this code by hand. I worked with Claude Code, phase by phase. My job was deciding what to build, testing everything, catching what was broken, and saying no a lot. I started late on Sep 28 and some of the testing happened at 2 AM, clicking "Report resurrection" over and over to see if the button would flicker again.

I don't have years of my own bug history, so the graves are classic bugs every developer has met: floating point money, timezones, merge conflicts in production. I'd rather be honest about that than pretend they're mine.

After reading other entries, I realised a cute graveyard wasn't enough. That's when the Zombie Detector happened. The moment it flagged a new report about a nightly job as a possible return of the timezone bug, and showed me exactly why (same cause, same component, shared words), was the moment this stopped feeling like a joke project to me.

The biggest thing I learned: Sanity is not just a place to store content. Custom actions, a Tombstone preview inside the Studio, scheduled Functions, an app in the Dashboard. It felt more like building a small tool than filling a CMS.

Judge path in 30 seconds

Open the timezone bug's third life and follow its Timeline: born, fix merged, buried, rose again, twice.
Go to Report a dead bug, press 👻 Try an example, then Report it dead.
In about 10 seconds, your report shows "⚠️ Possible resurrection of Cron job that ran twice at DST", with each signal ✓/✗, the match score and the old fix.
Back on the graveyard, that grave is now 👻 Haunted for an hour, until the example is dismissed automatically.

Examples stay out of the public list and can't be approved, so trying it changes nothing for the next judge. The coroner's AI budget is 15 reports a day; once it's used, "Try an example" still shows the detector's signals and score (they need no AI), just with "Reason unavailable, daily AI budget used" instead of the one-sentence reason.

The Studio needs a Sanity login, so the video shows it; /report lets you try the detector without one.

A 90-second tour of the site, the Studio's lifecycle actions and Tombstone view, the AI coroner and the Morgue. I recorded it before building the Zombie Detector; the GIF below shows that part. The Studio scenes use temporary test bugs, 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."

It started as one joke taken literally: a regression is a bug that came back from the dead, so here it comes back as a zombie. Where the joke ended up is the part I like most. The graveyard remembers, so it can catch what comes back. Every grave is structured content in Sanity: the symptoms, the component, the language, the cause of death and the fix. So when someone reports a "new" bug, the graveyard can ask the question teams usually ask too late: haven't we buried this one before?

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

Demo

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

The graveyard has four 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".
👻 Haunted: pale and faintly glowing. A new report looks like this bug coming back, and nobody has decided yet. More on that below.

You can filter by language or cause of death. Each stone opens a grave page with a death certificate (cause of death, severity, hours to kill, killed by, component, symptoms and the fix), a timeline of every life the bug has had, 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 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.

Inside the Studio: a bug's life

The Studio is where a person runs the graveyard. It needs a login, so these are screenshots.

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 7-day rule lives in one small file that the Studio, the Morgue and the gravedigger Function all import, so they can't disagree:

// sanity/lib/lifecycle.ts
/** How long a fix must hold, in days, before its bug can be declared buried. */
export const BURIAL_WAIT_DAYS = 7

export function daysUntilBurial(fixMergedAt: string, today = todayUTC()) {
  return Math.max(0, BURIAL_WAIT_DAYS - daysBetween(fixMergedAt, today))
}
// The Studio action turns it into its label: "🪦 Can bury in 4 days"

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

A custom Tombstone view. Every bug opens with two tabs, "Editor" and "🪦 Tombstone". The Tombstone tab is a custom Studio view (a React component added with the Structure Builder) that renders the same component the website uses. In split pane the stone updates on every keystroke, with an epitaph counter (140 characters max).

The form on the left, the Tombstone view on the right. (A throwaway test bug, deleted afterwards.)

A graveyard sidebar: 🪦 All graves, 🗳️ Public reports, 👻 Possible resurrections, 🧟 Zombies, 💀 Suspected dead, 🩹 Fix merged and ⚰️ Buried, then Languages and Causes of death.

Reaching past the Studio

The Studio is where a person decides. Everything else reaches past it: an app in the Sanity Dashboard, two functions in Sanity's cloud and an experiment on a branch. All of it goes through the same Content Lake and follows the same rules.

The Morgue is a small App SDK app in the Sanity Dashboard. It shows every bug that isn't resting yet in live columns (suspected dead, walking, waiting and ready to bury), with a 👻 Possible resurrections band on top when there are any. Each card has the Studio's lifecycle buttons with the same rules, because both import sanity/lib/lifecycle.ts. The columns are useDocuments lists with GROQ filters, the cards read their fields with useDocumentProjection, and the buttons use useApplyDocumentActions, so cards move as the documents change, with no refresh.

The Morgue running locally in the Sanity Dashboard, with temporary test bugs that were deleted afterwards.

It's deployed to my organization's Dashboard, which only members of the organization can open, so for judges the GIF and the code are what's visible. One surprise while building it: the Sanity CLI looks for a Studio config in every parent folder before it looks for an app config, so inside this repo sanity build built the site's Studio instead. The app's npm scripts now run the CLI from a mirror folder outside the repo.

The gravedigger is a scheduled Sanity Function, deployed with a Blueprint. Every day at 00:15 UTC it buries every bug whose fix has held for 7 days, using the same rulebook, and it skips bugs with unpublished Studio changes. (Once a day is also the most often a scheduled function can run on the Free plan.)

The coroner is a document function. When a bug is created as suspected dead with no epitaph, it asks an Agent Action (Prompt) for a short epitaph in the style of the existing graves, plus a cause of death chosen from the real ones. It writes them only into separate coroner… fields, marked "awaiting approval", and a ✅ Accept coroner's report action copies them into the real fields when a person clicks Accept. The AI never touches the real epitaph and never publishes anything on its own.

A coroner's report waiting for approval. The bugs in the list are temporary test bugs that were deleted afterwards.

Workflows is the one part that isn't live. I gave Claude Code a 3-hour time box to find out whether Sanity Workflows could run this lifecycle, and it can model it. On the explore/workflows branch, the lifecycle is two workflow definitions, and "Declare buried" is gated by a GROQ requirement, dateTime($now) >= dateTime($fields.fixMergedAt) + 604800 (7 days, in seconds). npx sanity-workflows deploy --check passes, and 4 tests pass against the real engine running in memory with a controlled clock. 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 host myself. The live site runs on the document actions.

The coroner was the last piece of machinery. It was also where the graveyard started to remember.

The Zombie Detector

Regressions rarely announce themselves. They come back as a "new" bug with a new title, reported by someone who wasn't there the first time, while the old fix sits forgotten in a closed ticket. The graveyard already knows every bug it has buried, so I asked for a detector that answers one question, "Is this actually an old bug coming back?", and set it one rule: explainable, not fake AI.

When a new suspected-dead bug arrives, from the Studio or the public report page, the coroner drafts its epitaph as before. Then it compares the bug with every grave that could still rise (fix merged or buried, and not risen yet), using four signals anyone can check:

✓/✗ same cause of death: the bug's own, or the one the coroner just suggested, and it says so;
✓/✗ same language;
✓/✗ same component (scheduler, checkout, auth…);
shared keywords from the names and symptoms, listed word by word.

They add up to a score that's plain arithmetic:

// sanity/lib/detector.ts
//   match score = 25 × same cause of death
//               + 15 × same language
//               + 25 × same component
//               + 35 × min(shared keywords, 4) / 4      (rounded)
export const MATCH_THRESHOLD = 60
export const WEIGHTS = {cause: 25, language: 15, component: 25, keywords: 35} as const

No model decides the match. Only when the best score reaches 60 does the coroner make a second Agent Action call, for one plain-English sentence explaining it: no numbers, no new facts, and the reporter's words treated as a description, never as instructions. Everything is stored on the new bug: resurrectionCandidate (a reference to the grave), matchScore, matchSignals and matchReason. The site calls it a "match score from 4 signals", never an AI similarity, and nothing is linked automatically.

The live site with the deployed coroner. The result took about 10 seconds to arrive (sped up here), and the report was deleted afterwards.

The same result as a still: each signal, the points it earned, the score, the reason and the previous fix. A report that matches nothing says "No known ghosts, a brand new bug." and shows the closest score.

👻 Haunted. While a possible resurrection waits for a person, its grave turns pale and ghostly on the site, with "👻 Haunted" above the name, a notice on its grave page and a "Haunted" step at the end of its timeline. It isn't stored anywhere: like "disturbed", GROQ works it out from the pending candidates (see the schema), so it disappears the moment someone decides.

A person decides. Two document actions appear on the new bug:

🧟 Confirm resurrection turns it into the grave's next zombie, with the same rules as Report resurrection. It becomes "Cron job that ran twice at DST (Zombie #1)", points to its previous life and counts timesResurrected up by one, and a grave can only rise once.
✖ Dismiss: it's a new bug clears the candidate and keeps the signals as a record.

The signals also show as a ✓/✗ checklist in the bug's Coroner's report tab, in the 👻 Possible resurrections list in the sidebar, and in the Morgue.

Confirming a possible resurrection in the Studio. The bugs in the list are temporary test bugs from the end-to-end test, deleted afterwards.

I tested it on the real dataset with temporary bugs, all deleted afterwards:

a clear match scored 100 and was confirmed into a Zombie #1;
a second one scored 75 and was dismissed;
a weak one scored 40 and wasn't flagged (and made no second Agent Action call);
once the grave had risen, the same report wasn't matched to it again.

Try it: report a dead bug

The report page lets anyone add a bug. Within seconds the coroner drafts its epitaph, the detector checks the graves, and the result appears under the form. The bug then waits under "Awaiting the coroner's approval" until I accept it in the Studio; only then does it join the graveyard. 👻 Try an example fills in a scheduler bug that ran twice after a daylight-saving switch, so you reliably see a detection. Examples skip that list, haunt their grave for an hour and are then deleted, and the Studio refuses to confirm them.

Every report costs an AI credit (two when it looks like a resurrection), so the form is guarded like any public form that costs money:

a honeypot field that bots fill in and people never see;
3 reports per visitor and 15 in total a day get the coroner (examples included), counted in private documents (a dot in the ID keeps them out of the public API), with the visitor's IP stored only as a keyed hash. After that, real reports get a friendly "come back tomorrow", and examples get the detector alone;
length limits, no links, and a profanity filter on both the reports and the AI's drafts before they're shown.

That's at most 2 × 15 × 31 = 930 credits a month, under the 1,000 free AI credits.

Code

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

Where to look:

sanity/lib/detector.ts: the Zombie Detector's signals and match score (plain code, no AI)
functions/ and sanity.blueprint.ts: the coroner and gravedigger Sanity Functions
sanity/actions/: the document actions (lifecycle, coroner, public reports, confirm and dismiss)
sanity/lib/lifecycle.ts: the rulebook the Studio, the Morgue and the gravedigger share
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
apps/morgue/: the Morgue, an App SDK app
app/(site)/report/: the report page and its server action (all the checks above)
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, polish, the Morgue, Functions and the coroner, the report page, and finally the Zombie Detector. 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.

The Zombie Detector's brief set the rule the whole feature follows:

GOAL: answer "Is this actually an old bug coming back?" with an EXPLAINABLE detector, not fake AI. The graveyard's history in the Content Lake is what catches regressions.

… Only if the top score passes a threshold, use an Agent Action to write a one-sentence plain-English reason. … Never link automatically. Never claim "AI similarity %"; label it "match score from N signals".

Here Claude Code pushed back on one detail. I'd asked it to compare against "buried/disturbed graves", but a disturbed grave has already risen, and a grave only rises once, so "Confirm resurrection" would have had to refuse those matches. It compares only graves that can still rise, and a disturbed grave's story continues at its zombie. I kept that too.

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 Haunted state didn't show up in local tests. The coroner wrote its match while no browser tab was open, so the local production build's cache never heard about it. In production, Sanity's webhook refreshes the site; the test now sends the local site the same signed webhook (encodeSignatureHeader from @sanity/webhook).
The last Functions deploy "failed" after it had worked. npx sanity blueprints deploy ended with OPERATION_UNCONFIRMED after losing its connection, but blueprints info showed the operation COMPLETED in 1 minute 5 seconds.

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, and the report form's rate-limit counters use dotted IDs on purpose, so they stay private.

Sanity Project Details

Project ID: rzjmw6lg
Dataset: production (public). Try it: every bug, as JSON

There are three document types: bug, language and causeOfDeath. Here's how everything reaches them:

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.

// 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. That's also what the timeline walks through.
Zombies of zombies work for free. A chain is just references pointing backwards.
"Disturbed" and "Haunted" aren't stored anywhere. GROQ works them out by asking who points at this grave:

*[_type == "bug"]{
  ...,
  "disturbed": count(*[_type == "bug" && previousLife._ref == ^._id]) > 0,
  "haunted": count(*[_type == "bug" && matchStatus == "candidate"
                     && resurrectionCandidate._ref == ^._id]) > 0
}

The detector only added optional fields: component, symptoms, fixSummary and fixUrl on every bug, plus the match fields on new ones. No existing document had to change shape.
Languages and causes of death are references, so filters, the leaderboard and the detector compare them reliably. The whole leaderboard is one GROQ query.
The fix date, the burial date, the resurrection counter and the detector's results are read-only in the Studio. There, only the actions and functions 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), or null to stay hidden. That's why "Confirm resurrection" only appears on a bug the detector flagged. 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.

You register them in sanity.config.ts. Mine go right after Publish, only on bugs, and Sanity's own actions stay:

// sanity.config.ts
document: {
  actions: (prev, {schemaType}) => {
    if (schemaType !== 'bug') return prev
    const afterPublish = prev.findIndex((action) => action.action === 'publish') + 1
    return [
      ...prev.slice(0, afterPublish),
      ConfirmResurrectionAction,
      DismissResurrectionAction,
      AcceptCoronerReportAction,
      ApprovePublicReportAction,
      ...lifecycleActions,
      ...prev.slice(afterPublish),
    ]
  },
},

Live everywhere

sanityFetch plus <SanityLive /> push Studio edits and function writes to open tabs in about 3 seconds. A signed Sanity webhook refreshes the cached site when nobody has it open (about 6 seconds). That's how a grave turns haunted on its own a few seconds after a report.

Agent Session

This is the Claude Code session behind this build, with secrets redacted. The embed shows the Phase 5 slice, where the lifecycle document actions were built and tested. The full session has every phase.

Building Bug Graveyard (Next.js + Sanity) with Claude Code claude-opus-5-5

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.):

"🩹 Mark fix merged": enabled only when status = suspected-dead. Sets status = fix-merged and fixMergedAt = today, then publishes.
"🪦 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.
"🧟 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

▸ Bash f=$(grep -l "interface DocumentActionProps" node_modules/sanity/lib/*.d.ts no...

Input

$ f=$(grep -l "interface DocumentActionProps" node_modules/sanity/lib/*.d.ts node_modules/sanity/lib/_chunks-dts/*.d.ts 2>/dev/null | head -1); echo "defs in: $f"; for n in "interface DocumentActionProps" "interface DocumentActionDescription" "interface DocumentActionConfirmDialogProps" "interface DocumentActionDialogDialogProps" "type DocumentActionDialogProps" "interface DocumentActionComponent" "type DocumentActionsResolver" "interface DocumentActionsContext"; do echo "=================== $n"; awk -v pat="$n" 'index($0, pat) {p=1} p {print; if (/^}/ || (/;$/ && pat ~ /^type/)) {exit}}' "$f" | grep -v "^\s*\*\|/\*\*" | head -30; done

Output

defs in: node_modules/sanity/lib/_chunks-dts/ActiveWorkspaceMatcherContext.d.ts
=================== interface DocumentActionProps
interface DocumentActionProps extends EditStateFor {
  revision?: string;
  onComplete: () => void;
  initialValueResolved: boolean;
}
=================== interface DocumentActionDescription
interface DocumentActionDescription extends GroupableActionDescription<DocumentActionGroup> {
  dialog?: DocumentActionDialogProps | false | null;
}
=================== interface DocumentActionConfirmDialogProps
interface DocumentActionConfirmDialogProps {
  type: 'confirm';
  tone?: ButtonTone;
  message: ReactNode;
  onConfirm: () => void;
  onCancel: () => void;
  cancelButtonIcon?: ComponentType | ReactNode;
  cancelButtonText?: string;
  confirmButtonIcon?: ComponentType | ReactNode;
  confirmButtonText?: string;
}
=================== interface DocumentActionDialogDialogProps
=================== type DocumentActionDialogProps
type DocumentActionDialogProps = DocumentActionConfirmDialogProps | DocumentActionPopoverDialogProps | DocumentActionModalDialogProps | DocumentActionCustomDialogComponentProps;
=================== interface DocumentActionComponent
interface DocumentActionComponent extends ActionComponent<DocumentActionProps, DocumentActionDescription> {
  action?: keyof DocumentActionKeys;
  displayName?: string;
}
=================== type DocumentActionsResolver
type DocumentActionsResolver = ComposableOption<DocumentActionComponent[], DocumentActionsContext>;
=================== interface DocumentActionsContext
interface DocumentActionsContext extends ConfigContext$1 {
  documentId?: string;
  schemaType: string;
  releaseId: string | undefined;
  versionType: DocumentActionsVersionType;
}

Agent

▸ Bash f=node_modules/sanity/lib/_chunks-dts/ActiveWorkspaceMatcherContext.d.ts; for...

Input

$ f=node_modules/sanity/lib/_chunks-dts/ActiveWorkspaceMatcherContext.d.ts; for n in "interface EditStateFor" "interface GroupableActionDescription" "interface DocumentActionModalDialogProps" "type DocumentActionsVersionType" "interface ActionComponent<"; do echo "=================== $n"; awk -v pat="$n" 'index($0, pat) {p=1} p {print; if (/^}/ || (/;$/ && pat ~ /^type/)) {exit}}' "$f" | grep -v "^\s*\*\|/\*\*\|^\s*\*/" | head -26; done; echo "=== exports of interest"; for n in useClient useDocumentStore useDocumentOperation useCurrentUser getPublishedId getDraftId isDraftId useToast; do printf "%-22s %s\n" $n "$(grep -c "\b$n\b" node_modules/sanity/lib/index.d.ts)"; done; grep -o "navigateIntent[^;]*;" node_modules/sanity/lib/_chunks-dts/*.d.ts node_modules/sanity/lib/router.d.ts 2>/dev/null | head -2

Output

=================== interface EditStateFor
interface EditStateFor {
  id: string;
  type: string;
  transactionSyncLock: TransactionSyncLockState | null;
  draft: SanityDocument | null;
  published: SanityDocument | null;
  version: SanityDocument | null;
  liveEdit: boolean;
  liveEditSchemaType: boolean;
  ready: boolean;
  release: string | undefined;
}
=================== interface GroupableActionDescription
interface GroupableActionDescription<GroupType = unknown> extends BaseActionDescription {
  group?: GroupType[];
}
=================== interface DocumentActionModalDialogProps
interface DocumentActionModalDialogProps {
  type?: 'dialog';
  content: ReactNode;
  footer?: DialogProps['footer'];
  header?: ReactNode;
  onClose: () => void;
  showCloseButton?: boolean;
  width?: 'small' | 'medium' | 'large' | 'full';
}
=================== type DocumentActionsVersionType
type DocumentActionsVersionType = 'published' | 'draft' | 'revision' | 'version' | 'scheduled-draft';
=================== interface ActionComponent<
interface ActionComponent<ActionProps, ActionDescription> {
  (props: ActionProps): ActionDescription | null;
}
=== exports of interest
useClient              2
useDocumentStore       2
useDocumentOperation   2
useCurrentUser         2
getPublishedId         2
getDraftId             2
isDraftId              2
useToast               0
node_modules/sanity/lib/_chunks-dts/types3.d.ts:navigateIntent: (intentName: string, params?: IntentParameters, options?: NavigateBaseOptions) => void;

Agent

▸ Bash f=node_modules/sanity/lib/_chunks-dts/ActiveWorkspaceMatcherContext.d.ts; awk...

Input

$ f=node_modules/sanity/lib/_chunks-dts/ActiveWorkspaceMatcherContext.d.ts; awk 'index($0, "interface BaseActionDescription") {p=1} p {print; if (/^}/) exit}' $(grep -l "interface BaseActionDescription" node_modules/sanity/lib/_chunks-dts/*.d.ts | head -1) | grep -v "^\s*\*\|/\*\*\|^\s*\*/"; echo "=== listenQuery"; grep -h -o "listenQuery: ([^;]*;" node_modules/sanity/lib/_chunks-dts/*.d.ts | head -2; grep -h -B2 -A8 "interface ListenQueryOptions" node_modules/sanity/lib/_chunks-dts/*.d.ts | grep -v "^\s*\*\|/\*\*\|^\s*\*/" | head -14

Output

interface BaseActionDescription {
  disabled?: boolean;
  icon?: ReactNode | ComponentType;
  label: string;
  onHandle?: () => void;
  title?: ReactNode;
  tone?: ButtonTone;
  shortcut?: string | null;
  dialog?: unknown;
}
=== listenQuery
interface ListenQueryOptions {
  tag?: string;
  apiVersion?: string;
  perspective?: ClientPerspective;
  throttleTime?: number;
  transitions?: ('update' | 'appear' | 'disappear')[];
}
declare function listenQuery(client: SanityClient, query: string | {

Agent

▸ Bash grep -h -A6 "declare function listenQuery" node_modules/sanity/lib/_chunks-dt...

Input

$ grep -h -A6 "declare function listenQuery" node_modules/sanity/lib/_chunks-dts/*.d.ts | head -10; grep -c "listenQuery" node_modules/sanity/lib/index.d.ts; grep -oE "[A-Za-z_$0-9]+ as listenQuery\b" node_modules/sanity/lib/index.d.ts | head -2; grep -h -B3 -A12 "interface DocumentStore {" node_modules/sanity/lib/_chunks-dts/*.d.ts | grep -iE "listenQuery|interface DocumentStore" | head

Output

declare function listenQuery(client: SanityClient, query: string | {
  fetch: string;
  listen: string;
}, params?: ListenQueryParams, options?: ListenQueryOptions): Observable<any>;
/**
 * @hidden
 * @beta */
2
ugrep: error: error at position 21
(?m)[A-Za-z_/bin/zsh-9]+ as listenQuery\b
                     \___invalid character class range


interface DocumentStore {
  listenQuery: (query: string | {

Agent

▸ Bash grep -rhoE "__studio_auth_token[^\"'\`]{0,40}" node_modules/sanity/lib/ 2>/de...

Input

$ grep -rhoE "__studio_auth_token[^\"'\`]{0,40}" node_modules/sanity/lib/ 2>/dev/null | sort -u | head -5; f=$(grep -rl "__studio_auth_token" node_modules/sanity/lib/_chunks-es/*.js 2>/dev/null | head -1); echo "file: $f"; grep -oE ".{200}__studio_auth_token.{300}" "$f" | head -2

Output

__studio_auth_token_
file: 
ugrep: warning: : No such file or directory

Agent

▸ Bash f=$(grep -rl "__studio_auth_token_" node_modules/sanity/lib/ 2>/dev/null | he...

Input

$ f=$(grep -rl "__studio_auth_token_" node_modules/sanity/lib/ 2>/dev/null | head -3); echo "$f"; for x in $f; do grep -oE ".{0,250}__studio_auth_token_.{0,250}" "$x" | head -3; done | cut -c1-600

Output

node_modules/sanity/lib/index.js
node_modules/sanity/lib/index.js.map
ugrep: warning: node_modules/sanity/lib/index.js
node_modules/sanity/lib/index.js.map: No such file or directory

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

▸ Bash grep -oE ".{0,200}__studio_auth_token_.{0,300}" node_modules/sanity/lib/index...

Input

$ grep -oE ".{0,200}__studio_auth_token_.{0,300}" node_modules/sanity/lib/index.js | head -3 | cut -c1-520

Output

ugrep: error: error at position 98
_(?:[^\n\x80-\xbf][\x80-\xbf]*){0,300}
         exceeds complexity limits___/

Agent

▸ Bash node -e ' const s = require("fs").readFileSync("node_modules/sanity/lib/index...

Input

$ node -e '
const s = require("fs").readFileSync("node_modules/sanity/lib/index.js", "utf8")
let i = -1, n = 0
while ((i = s.indexOf("__studio_auth_token_", i + 1)) !== -1 && n++ < 3) console.log("---\n" + s.slice(Math.max(0, i - 260), i + 320))
'

Output

---
025-02-19"
}, DEFAULT_STUDIO_CLIENT_HEADERS = {
  "x-sanity-app": `studio@${SANITY_VERSION}`
}, versionedClient = (client, apiVersion) => apiVersion ? client.withConfig({
  apiVersion
}) : client, AUTH_API_VERSION = "v2026-05-04", AUTH_TOKEN_STORAGE_PREFIX = "__studio_auth_token_", COOKIE_AUTH_STATE_PREFIX = "__studio_auth_cookie_state_", UNAUTHENTICATED = {
  authenticated: !1
}, AUTHENTICATED = {
  authenticated: !0
}, AUTH_CLIENT_OPTIONS = {
  apiVersion: AUTH_API_VERSION,
  useCdn: !1,
  perspective: "raw",
  requestTagPrefix: "sanity.studio",
  allowReconfigure: !1,

Agent

▸ Bash node -e ' const s = require("fs").readFileSync("node_modules/sanity/lib/index...

Input

$ node -e '
const s = require("fs").readFileSync("node_modules/sanity/lib/index.js", "utf8")
for (const needle of ["AUTH_TOKEN_STORAGE_PREFIX}", "AUTH_TOKEN_STORAGE_PREFIX +", "getToken(projectId", "function getStorageKey", "localStorage.getItem("]) {
  let i = -1, n = 0
  while ((i = s.indexOf(needle, i + 1)) !== -1 && n++ < 2) console.log("--- [" + needle + "]\n" + s.slice(Math.max(0, i - 200), i + 260))
}
' | head -60

Output

--- [AUTH_TOKEN_STORAGE_PREFIX}]
,
  useCdn: !1,
  perspective: "raw",
  requestTagPrefix: "sanity.studio",
  allowReconfigure: !1,
  headers: DEFAULT_STUDIO_CLIENT_HEADERS
};
function getAuthTokenStorageKey(projectId) {
  return `${AUTH_TOKEN_STORAGE_PREFIX}${projectId}`;
}
function getCookieAuthStateKey(projectId) {
  return `${COOKIE_AUTH_STATE_PREFIX}${projectId}`;
}
function createLocalStorageStorage(key) {
  function load() {
    try {
      const value = localStorage.getItem(key);

--- [localStorage.getItem(]
-"), localStorage.removeItem(key), !0);
  } catch {
    return !1;
  }
})(), LOCAL_STORAGE_PREFIX = "sanity-locale";
function getPreferredLocale(projectId, sourceId) {
  return supportsLocalStorage ? localStorage.getItem(getItemKey$1(projectId, sourceId)) ?? void 0 : void 0;
}
function storePreferredLocale(projectId, sourceId, locale) {
  supportsLocalStorage && localStorage.setItem(getItemKey$1(projectId, sourceId), locale);
}
function getItemKey$1(projec
--- [localStorage.getItem(]
ctId}`;
}
function getCookieAuthStateKey(projectId) {
  return `${COOKIE_AUTH_STATE_PREFIX}${projectId}`;
}
function createLocalStorageStorage(key) {
  function load() {
    try {
      const value = localStorage.getItem(key);
      return value === null ? void 0 : JSON.parse(value);
    } catch (err) {
      console.error(`Failed to parse localstorage value: ${err.message}`);
      return;
    }
  }
  function store(value) {
    try {
      value === void

Agent

▸ Bash node -e ' const s = require("fs").readFileSync("node_modules/sanity/lib/index...

Input

$ node -e '
const s = require("fs").readFileSync("node_modules/sanity/lib/index.js", "utf8")
for (const needle of ["getAuthTokenStorageKey(", "loginMethod"]) {
  let i = s.indexOf("function getAuthTokenStorageKey") + 50, n = 0
  i = -1
  while ((i = s.indexOf(needle, i + 1)) !== -1 && n++ < 4) console.log("--- [" + needle + "]\n" + s.slice(Math.max(0, i - 150), i + 250).replace(/\n\s+/g, " "))
}
' | head -40

Output

--- [getAuthTokenStorageKey(]
  useCdn: !1, perspective: "raw", requestTagPrefix: "sanity.studio", allowReconfigure: !1, headers: DEFAULT_STUDIO_CLIENT_HEADERS
};
function getAuthTokenStorageKey(projectId) { return `${AUTH_TOKEN_STORAGE_PREFIX}${projectId}`;
}
function getCookieAuthStateKey(projectId) { return `${COOKIE_AUTH_STATE_PREFIX}${projectId}`;
}
function createLocalStorageStorage(key) { function load() {
--- [getAuthTokenStorageKey(]
", getSessionId: getSessionId2, consumeHashToken: consumeHashToken2, ...providerOptions
}) { const tokenStorage = createBroadcastStorage( getAuthTokenStorageKey(projectId), // sets the initial value (currentTokenValue) => { const hashToken = consumeHashToken2(); return hashToken ? { token: hashToken, authenticated: !0 } : currentTokenValue; 
--- [getAuthTokenStorageKey(]
: "\u2022" }) ] }, link.title);
}
function getStoredToken(projectId) { if (supportsLocalStorage) try { const raw = localStorage.getItem(getAuthTokenStorageKey(projectId)); return raw ? JSON.parse(raw)?.token : void 0; } catch { return; }
}
function resolveApiHost(apiHost) { if (apiHost) return apiHost; if (isStaging) return "https://api.sanity.work";
}
async f
--- [getAuthTokenStorageKey(]
.token ? { token, ignoreBrowserTokenWarning: !0 } : { withCredentials: !0 } }, client = factory(clientConfig), tokenKey = getAuthTokenStorageKey(input.projectId), cookieKey = getCookieAuthStateKey(input.projectId), observable$ = using(() => { const cookieState = token ? null : createBroadcastState(cookieKey); return { cookieState, unsubscribe: () => 
--- [loginMethod]
filter((official) => customProviders.some((provider) => provider.url !== official.url)).concat(customProviders);
}
function createHrefForProvider({ loginMethod = "dual", projectId, url, redirectPath
}) { const params = new URLSearchParams(); return params.set("origin", `${window.location.origin}${redirectPath}`), params.set("projectId", projectId), loginMethod === "token" ? params.set(
--- [loginMethod]
 const params = new URLSearchParams(); return params.set("origin", `${window.location.origin}${redirectPath}`), params.set("projectId", projectId), loginMethod === "token" ? params.set("withSid", "true") : params.set("type", loginMethod), `${url}?${params}`;
}
function createLoginComponent({ client$, loginMethod, redirectOnSingle, wasLogout, isHandlingCallback, ...providerOptions
}) 
--- [loginMethod]
w.location.origin}${redirectPath}`), params.set("projectId", projectId), loginMethod === "token" ? params.set("withSid", "true") : params.set("type", loginMethod), `${url}?${params}`;
}
function createLoginComponent({ client$, loginMethod, redirectOnSingle, wasLogout, isHandlingCallback, ...providerOptions
}) { function LoginComponent(t0) { const $ = c(28), { projectId, 
--- [loginMethod]
hod === "token" ? params.set("withSid", "true") : params.set("type", loginMethod), `${url}?${params}`;
}
function createLoginComponent({ client$, loginMethod, redirectOnSingle, wasLogout, isHandlingCallback, ...providerOptions

Agent

▸ Write /Users/jashanpreetkaur/Desktop/bug-graveyard/sanity/lib/lifecycle.ts

Input

/Users/jashanpreetkaur/Desktop/bug-graveyard/sanity/lib/lifecycle.ts

Output

File created successfully at: /Users/jashanpreetkaur/Desktop/bug-graveyard/sanity/lib/lifecycle.ts (file state is current in your context — no need to Read it back)

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

▸ Bash node --input-type=module -e ' import {BURIAL_WAIT_DAYS, daysUntilBurial, zomb...

Input

$ node --input-type=module -e '
import {BURIAL_WAIT_DAYS, daysUntilBurial, zombieName, slugify, todayUTC, daysBetween} from "./sanity/lib/lifecycle.ts"
const eq = (label, got, want) => console.log(`${JSON.stringify(got) === JSON.stringify(want) ? "ok  " : "FAIL"} ${label}: ${JSON.stringify(got)}`)
eq("BURIAL_WAIT_DAYS", BURIAL_WAIT_DAYS, 7)
eq("fixed today -> 7 days left", daysUntilBurial("2026-09-29", "2026-09-29"), 7)
eq("fixed 3 days ago -> 4 left", daysUntilBurial("2026-09-26", "2026-09-29"), 4)
eq("fixed 7 days ago -> 0 left", daysUntilBurial("2026-09-22", "2026-09-29"), 0)
eq("fixed 30 days ago -> 0 left", daysUntilBurial("2026-08-30", "2026-09-29"), 0)
eq("across a month end", daysBetween("2026-02-27", "2026-03-02"), 3)
eq("01:30 IST on the 29th is still the 28th in UTC", todayUTC(new Date("2026-09-29T01:30:00+05:30")), "2026-09-28")
eq("first zombie", zombieName("Timezone bug in scheduler", 1), "Timezone bug in scheduler (Zombie #1)")
eq("zombie of a zombie keeps the original name", zombieName("Timezone bug in scheduler (Zombie #1)", 2), "Timezone bug in scheduler (Zombie #2)")
eq("slug", slugify("Timezone bug in scheduler (Zombie #2)"), "timezone-bug-in-scheduler-zombie-2")
eq("slug with accents and symbols", slugify("  Crème brûlée: C++ bug!! "), "creme-brulee-c-bug")
' 2>&1 | grep -v ExperimentalWarning

Output

(node:24361) [MODULE_TYPELESS_PACKAGE_JSON] Warning: Module type of file:///Users/jashanpreetkaur/Desktop/bug-graveyard/sanity/lib/lifecycle.ts is not specified and it doesn't parse as CommonJS.
Reparsing as ES module because module syntax was detected. This incurs a performance overhead.
To eliminate this warning, add "type": "module" to /Users/jashanpreetkaur/Desktop/bug-graveyard/package.json.
(Use `node --trace-warnings ...` to show where the warning was created)
ok   BURIAL_WAIT_DAYS: 7
ok   fixed today -> 7 days left: 7
ok   fixed 3 days ago -> 4 left: 4
ok   fixed 7 days ago -> 0 left: 0
ok   fixed 30 days ago -> 0 left: 0
ok   across a month end: 3
ok   01:30 IST on the 29th is still the 28th in UTC: "2026-09-28"
ok   first zombie: "Timezone bug in scheduler (Zombie #1)"
ok   zombie of a zombie keeps the original name: "Timezone bug in scheduler (Zombie #2)"
ok   slug: "timezone-bug-in-scheduler-zombie-2"
ok   slug with accents and symbols: "creme-brulee-c-bug"

Agent

▸ Write /Users/jashanpreetkaur/Desktop/bug-graveyard/sanity/actions/lifecycle.tsx

Input

/Users/jashanpreetkaur/Desktop/bug-graveyard/sanity/actions/lifecycle.tsx

Output

File created successfully at: /Users/jashanpreetkaur/Desktop/bug-graveyard/sanity/actions/lifecycle.tsx (file state is current in your context — no need to Read it back)

Agent

▸ Read /Users/jashanpreetkaur/Desktop/bug-graveyard/sanity.config.ts

Input

/Users/jashanpreetkaur/Desktop/bug-graveyard/sanity.config.ts

Output

1   'use client'
2   
3   /**
4    * This configuration is used to for the Sanity Studio that’s mounted on the `/app/studio/[[...tool]]/page.tsx` route
5    */
6   
7   import {visionTool} from '@sanity/vision'
8   import {defineConfig} from 'sanity'
9   import {structureTool} from 'sanity/structure'
10  
11  // Go to https://www.sanity.io/docs/api-versioning to learn how API versioning works
12  import {apiVersion, dataset, projectId} from './sanity/env'
13  import {schema} from './sanity/schemaTypes'
14  import {structure} from './sanity/structure'
15  
16  export default defineConfig({
17    basePath: '/studio',
18    projectId,
19    dataset,
20    // Add and edit the content schema in the './sanity/schemaTypes' folder
21    schema,
22    plugins: [
23      structureTool({structure}),
24      // Vision is for querying with GROQ from inside the Studio
25      // https://www.sanity.io/docs/the-vision-plugin
26      visionTool({defaultApiVersion: apiVersion}),
27    ],
28  })
29

Agent

▸ Edit /Users/jashanpreetkaur/Desktop/bug-graveyard/sanity.config.ts

Input

/Users/jashanpreetkaur/Desktop/bug-graveyard/sanity.config.ts

Output

The file /Users/jashanpreetkaur/Desktop/bug-graveyard/sanity.config.ts has been updated successfully. (file state is current in your context — no need to Read it back)

Agent

▸ Bash npx tsc --noEmit 2>&1 | head -20 && echo "tsc exit: ${pipestatus[1]}"; npm ru...

Input

$ npx tsc --noEmit 2>&1 | head -20 && echo "tsc exit: ${pipestatus[1]}"; npm run lint --silent 2>&1 | tail -20; echo "lint exit: ${pipestatus[1]}"

Output

tsc exit: 0
lint exit: 0

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

Input

$ npx sanity schemas validate 2>&1 | grep -E "Errors|Warnings|✖|rror" | head -5; npm run typegen 2>&1 | grep -E "✔ Success|queries and|rror|✖" ; git diff --stat sanity/types.ts sanity/extract.json; npm run build 2>&1 | grep -E "Compiled|TypeScript|rror|/studio"

Output

✖ Errors:   0 errors
⚠ Warnings: 0 warnings
✔ Successfully generated types to /Users/jashanpreetkaur/Desktop/bug-graveyard/sanity/types.ts in 382ms
  └─ 4 queries and 17 schema types
✓ Compiled successfully in 944ms
  Running TypeScript ...
  Finished TypeScript in 1112ms ...
└ ○ /studio/[[...tool]]

Agent

▸ Bash SP=/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab...

Input

$ SP=/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad
node --input-type=module -e '
import {writeFileSync} from "node:fs"
const day = (n) => new Date(Date.now() - n * 864e5).toISOString().slice(0, 10)
const ref = (_ref) => ({_type: "reference", _ref})
const bug = (key, extra) => ({
  _id: `test-bug-life-${key}`, _type: "bug", name: `Lifecycle test: ${key}`,
  slug: {_type: "slug", current: `test-bug-life-${key}`},
  language: ref("language-typescript"), causeOfDeath: ref("causeOfDeath-off-by-one"),
  severity: "low", bornAt: day(30), timesResurrected: 0, epitaph: `Temporary: ${key}.`, ...extra,
})
const docs = [
  bug("suspected", {status: "suspected-dead"}),
  bug("waiting", {status: "fix-merged", fixMergedAt: day(3)}),
  bug("ready", {status: "fix-merged", fixMergedAt: day(8)}),
  bug("buried", {status: "buried", fixMergedAt: day(20), buriedAt: day(12)}),
  bug("drafted", {status: "suspected-dead"}),
  {...bug("drafted", {status: "suspected-dead"}), _id: "drafts.test-bug-life-drafted", epitaph: "An unpublished edit."},
]
writeFileSync(process.argv[1], JSON.stringify(docs, null, 2))
' "$SP/life-docs.json"
npx sanity documents create "$SP/life-docs.json" --replace 2>&1 | grep -v "npm warn" | tail -8

Output

Upserted:
  - drafts.test-bug-life-drafted
  - test-bug-life-suspected
  - test-bug-life-waiting
  - test-bug-life-ready
  - test-bug-life-buried
  - test-bug-life-drafted

Agent

▸ Write /private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e...

Input

/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad/studio-cdp.mjs

Output

File created successfully at: /private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad/studio-cdp.mjs (file state is current in your context — no need to Read it back)

Agent

▸ Bash SP=/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab...

Input

$ SP=/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad
cat > "$SP/explore.mjs" <<'EOF'
import {openStudio, wait} from './studio-cdp.mjs'
const [, , port, base, sp] = process.argv
const s = await openStudio(port, base, 'rzjmw6lg')
await s.navigate('/studio/intent/edit/id=test-bug-life-suspected;type=bug')
await s.until('document form', `!!document.querySelector('[data-testid="action-menu-button"]')`, 60000)
await wait(2500)
console.log('url:', await s.url())
console.log('footer buttons:', JSON.stringify(await s.evaluate(`[...document.querySelectorAll('[data-testid="pane-footer"] button, [data-testid^="action-"]')].map(b => ({testid: b.dataset.testid, text: b.innerText.trim().slice(0,40), disabled: b.disabled || b.getAttribute('aria-disabled') === 'true' || b.hasAttribute('data-disabled')}))`), null, 1))
await s.evaluate(`document.querySelector('[data-testid="action-menu-button"]').click()`)
await wait(800)
console.log('menu items:', JSON.stringify(await s.evaluate(`[...document.querySelectorAll('[role="menuitem"]')].map(b => ({testid: b.dataset.testid, text: b.innerText.trim().slice(0,50), disabled: b.disabled || b.getAttribute('aria-disabled') === 'true' || b.hasAttribute('data-disabled')}))`), null, 1))
await s.shot(`${sp}/explore-menu.png`)
console.log('errors:', s.logs.slice(0, 5))
s.close()
EOF
npx next start -p 3333 > "$SP/next-3333.log" 2>&1 & SERVER=$!
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --headless=new --disable-gpu --hide-scrollbars --no-first-run --remote-debugging-port=9341 --user-data-dir="$SP/chrome-p5" about:blank >/dev/null 2>&1 & CHROME=$!
curl -s -o /dev/null --retry 30 --retry-connrefused --retry-delay 1 http://localhost:3333/ && curl -s -o /dev/null --retry 30 --retry-connrefused --retry-delay 1 http://127.0.0.1:9341/json/version
(cd "$SP" && node explore.mjs 9341 http://localhost:3333 "$SP")
kill $CHROME $SERVER 2>/dev/null; wait $CHROME $SERVER 2>/dev/null; pkill -f "scratchpad/chrome-p5"

Output

Exit code 1
url: /studio/structure/bug;test-bug-life-suspected
footer buttons: [
 {
  "testid": "action-intent-button",
  "text": "",
  "disabled": true
 },
 {
  "text": "",
  "disabled": true
 },
 {
  "text": "",
  "disabled": true
 },
 {
  "testid": "action-publish",
  "text": "Publish",
  "disabled": true
 },
 {
  "testid": "action-menu-button",
  "text": "",
  "disabled": true
 }
]
menu items: [
 {
  "testid": "action-🩹Mark fix merged",
  "text": "🩹 Mark fix merged",
  "disabled": false
 },
 {
  "testid": "action-🪦Declare buried",
  "text": "🪦 Declare buried",
  "disabled": true
 },
 {
  "testid": "action-🧟Report resurrection",
  "text": "🧟 Report resurrection",
  "disabled": true
 },
 {
  "testid": "action-Duplicate",
  "text": "Duplicate",
  "disabled": false
 },
 {
  "testid": "action-Delete",
  "text": "Delete\nCtrl\nOption\nD",
  "disabled": false
 }
]
errors: []

Agent

▸ Read /private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e...

Input

/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad/explore-menu.png

Output

Agent

▸ Write /private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e...

Input

/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad/lifecycle-e2e.mjs

Output

File created successfully at: /private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad/lifecycle-e2e.mjs (file state is current in your context — no need to Read it back)

Agent

▸ Bash SP=/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab...

Input

$ SP=/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad
npx next start -p 3333 > "$SP/next-3333.log" 2>&1 & SERVER=$!
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --headless=new --disable-gpu --hide-scrollbars --no-first-run --remote-debugging-port=9342 --user-data-dir="$SP/chrome-p5b" about:blank >/dev/null 2>&1 & CHROME=$!
curl -s -o /dev/null --retry 30 --retry-connrefused --retry-delay 1 http://localhost:3333/ && curl -s -o /dev/null --retry 30 --retry-connrefused --retry-delay 1 http://127.0.0.1:9342/json/version
(cd "$SP" && node lifecycle-e2e.mjs 9342 http://localhost:3333) 2>&1 | tee "$SP/e2e.log"
kill $CHROME $SERVER 2>/dev/null; wait $CHROME $SERVER 2>/dev/null; pkill -f "scratchpad/chrome-p5b"; true

Output

1) Suspected dead → Mark fix merged
  ok   only "Mark fix merged" is enabled (✓ 🩹 Mark fix merged | ✗ 🪦 Declare buried | ✗ 🧟 Report resurrection)
  ok   published: status fix-merged, fixMergedAt today (UTC) (1.4s)
  ok   no draft left behind
  FAIL now waiting 7 days to bury, resurrection allowed (✗ 🩹 Mark fix merged | ✗ 🪦 Can bury in 7 days | ✗ 🧟 Report resurrection)
  ok   grave page shows the fix date (0.7s)
2) Fixed 3 days ago
  ok   "Can bury in 4 days", disabled (✗ 🩹 Mark fix merged | ✗ 🪦 Can bury in 4 days | ✓ 🧟 Report resurrection)
3) Fixed 8 days ago → Declare buried
  ok   "Declare buried" is enabled (✗ 🩹 Mark fix merged | ✓ 🪦 Declare buried | ✓ 🧟 Report resurrection)
  ok   published: status buried, buriedAt today (UTC) (1.3s)
  ok   no draft left behind
  ok   grave page shows the burial date (0.7s)
4) Cancelling a resurrection changes nothing
file:///private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad/studio-cdp.mjs:46
    throw new Error(`timed out waiting for: ${label}`)
          ^

Error: timed out waiting for: confirm dialog
    at Object.until (file:///private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad/studio-cdp.mjs:46:11)
    at async file:///private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad/lifecycle-e2e.mjs:111:1

Node.js v24.14.0

Agent

▸ Bash SP=/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab...

Input

$ SP=/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad
cat > "$SP/debug-risen.mjs" <<'EOF'
import {openStudio, wait} from './studio-cdp.mjs'
const [, , port, base] = process.argv
const s = await openStudio(port, base, 'rzjmw6lg')
async function state(label) {
  await s.evaluate(`document.querySelector('[data-testid="action-menu-button"]').click()`)
  await s.until('menu', `document.querySelectorAll('[role="menuitem"]').length > 0`)
  const rect = await s.evaluate(`(() => { const b = [...document.querySelectorAll('[role="menuitem"]')].find(b => b.innerText.includes('resurrection')); const r = b.getBoundingClientRect(); return {x: r.x + r.width / 2, y: r.y + r.height / 2, disabled: b.getAttribute('aria-disabled') ?? String(b.disabled) } })()`)
  await s.send('Input.dispatchMouseEvent', {type: 'mouseMoved', x: rect.x, y: rect.y})
  await wait(900)
  const tip = await s.evaluate(`[...document.querySelectorAll('[data-ui="Popover"], [role="tooltip"], [data-testid*="tooltip"]')].map(e => e.innerText.trim()).filter(Boolean).join(' || ')`)
  console.log(`${label}: disabled=${rect.disabled} tooltip="${tip}"`)
  await s.evaluate(`document.dispatchEvent(new KeyboardEvent('keydown', {key: 'Escape', bubbles: true}))`)
  await wait(300)
}
// "ready" was buried in place during the last run; open it fresh now
await s.navigate('/studio/intent/edit/id=test-bug-life-ready;type=bug')
await s.until('doc', `location.pathname.endsWith('test-bug-life-ready') && !!document.querySelector('[data-testid="action-menu-button"]')`, 60000)
await wait(2000)
await state('fresh load of a buried bug')
for (const t of [3, 8]) { await wait(t * 1000); await state(`after ${t}s more`) }
s.close()
EOF
npx next start -p 3333 > "$SP/next-3333.log" 2>&1 & SERVER=$!
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --headless=new --disable-gpu --hide-scrollbars --no-first-run --remote-debugging-port=9343 --user-data-dir="$SP/chrome-p5c" about:blank >/dev/null 2>&1 & CHROME=$!
curl -s -o /dev/null --retry 30 --retry-connrefused --retry-delay 1 http://localhost:3333/ && curl -s -o /dev/null --retry 30 --retry-connrefused --retry-delay 1 http://127.0.0.1:9343/json/version
(cd "$SP" && node debug-risen.mjs 9343 http://localhost:3333)
kill $CHROME $SERVER 2>/dev/null; wait $CHROME $SERVER 2>/dev/null; pkill -f "scratchpad/chrome-p5c"; true

Output

fresh load of a buried bug: disabled=false tooltip="What's new
Content Agent is generally available"
after 3s more: disabled=false tooltip="What's new
Content Agent is generally available"
after 8s more: disabled=false tooltip="What's new
Content Agent is generally available"

Agent

▸ Bash python3 - <<'EOF' import pathlib p = pathlib.Path('sanity/actions/lifecycle.t...

Input

$ python3 - <<'EOF'
import pathlib
p = pathlib.Path('sanity/actions/lifecycle.tsx')
s = p.read_text()
reps = [
("""  const risen = useRisenZombie(bug?._id)

  function resurrect() {
    setConfirming(false)
    run(async () => {
      if (!bug) return
      const number""",
"""  const risen = useRisenZombie(bug?._id)

  function resurrect() {
    setConfirming(false)
    run(async () => {
      if (!bug) return
      // Checked again here: the live check can lag, or a zombie may just have risen elsewhere.
      const already = await client.fetch<string | null>(RISEN_QUERY, {id: bug._id}, {perspective: 'raw'})
      if (already) throw new Error(`It already rose as “${already}”. Report the next resurrection on that grave.`)
      const number"""),
("""    disabled: busy || Boolean(blocked) || !dead || risen !== null,""",
 """    disabled: busy || Boolean(blocked) || !dead || Boolean(risen),"""),
("""        : risen
          ? `It already rose as “${risen}”. Report the next resurrection on that grave.`
          : risen === undefined
            ? 'Checking whether it has already risen…'
            : 'Creates a zombie of this bug and opens it'),""",
 """        : risen
          ? `It already rose as “${risen}”. Report the next resurrection on that grave.`
          : 'Creates a zombie of this bug and opens it'),"""),
("""// The name of the zombie that already rose from this grave: null if none has,
// undefined while still checking. A grave only rises once; its zombie carries on
// the chain, so the next resurrection is reported on the zombie's grave.
function useRisenZombie(publishedId: string | undefined) {
  const documentStore = useDocumentStore()
  const [risen, setRisen] = useState<string | null | undefined>(undefined)

  useEffect(() => {
    if (!publishedId) return
    const subscription = documentStore
      .listenQuery(
        '*[_type == "bug" && previousLife._ref == $id][0].name',
        {id: publishedId},
        {perspective: 'published'},
      )""",
"""// A grave only rises once: its zombie carries on the chain, so the next
// resurrection is reported on the zombie's grave.
const RISEN_QUERY = '*[_type == "bug" && previousLife._ref == $id][0].name'

// The name of the zombie that already rose from this grave, kept up to date;
// null if none has (or while the first check is still running).
function useRisenZombie(publishedId: string | undefined) {
  const documentStore = useDocumentStore()
  const [risen, setRisen] = useState<string | null>(null)

  useEffect(() => {
    if (!publishedId) return
    const subscription = documentStore
      .listenQuery(RISEN_QUERY, {id: publishedId}, {perspective: 'published'})"""),
]
for a, b in reps:
    assert a in s, a[:80]
    s = s.replace(a, b)
p.write_text(s)
print("patched")
EOF
npx tsc --noEmit && echo "tsc ok"; npm run lint --silent && echo "lint ok"

Output

patched
tsc ok
lint ok

Agent

▸ Bash SP=/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab...

Input

$ SP=/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad
python3 - "$SP/lifecycle-e2e.mjs" <<'EOF'
import sys, pathlib
p = pathlib.Path(sys.argv[1]); s = p.read_text()
a = """await open('test-bug-life-buried')
items = await menu()
check('the old grave cannot rise twice', items.find((i) => i.text.includes('resurrection'))?.disabled === true, describe(items))"""
b = """await open('test-bug-life-buried')
await pollUntil('the old grave cannot rise twice', async () => {
  const items = await menu()
  return items.find((i) => i.text.includes('resurrection'))?.disabled === true || describe(items)
}, 15000)"""
assert a in s
p.write_text(s.replace(a, b))
EOF
echo "zombies of test bugs before reset: $(npx sanity documents query --api-version 2026-09-28 'count(*[_type == "bug" && previousLife._ref in ["test-bug-life-suspected","test-bug-life-waiting","test-bug-life-ready","test-bug-life-buried","test-bug-life-drafted"]])' 2>&1 | grep -v 'npm warn' | tail -1)"
npx sanity documents create "$SP/life-docs.json" --replace 2>&1 | grep -v "npm warn" | head -1
npm run build 2>&1 | grep -E "Compiled|rror"
npx next start -p 3333 > "$SP/next-3333.log" 2>&1 & SERVER=$!
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --headless=new --disable-gpu --hide-scrollbars --no-first-run --remote-debugging-port=9344 --user-data-dir="$SP/chrome-p5d" about:blank >/dev/null 2>&1 & CHROME=$!
curl -s -o /dev/null --retry 30 --retry-connrefused --retry-delay 1 http://localhost:3333/ && curl -s -o /dev/null --retry 30 --retry-connrefused --retry-delay 1 http://127.0.0.1:9344/json/version
(cd "$SP" && node lifecycle-e2e.mjs 9344 http://localhost:3333) 2>&1 | tee "$SP/e2e.log"
kill $CHROME $SERVER 2>/dev/null; wait $CHROME $SERVER 2>/dev/null; pkill -f "scratchpad/chrome-p5d"; true

Output

zombies of test bugs before reset:  ›   test-bug-life-buried","test-bug-life-drafted"]])
Upserted:
✓ Compiled successfully in 799ms
1) Suspected dead → Mark fix merged
  ok   only "Mark fix merged" is enabled (✓ 🩹 Mark fix merged | ✗ 🪦 Declare buried | ✗ 🧟 Report resurrection)
  ok   published: status fix-merged, fixMergedAt today (UTC) (1.3s)
  ok   no draft left behind
  ok   now waiting 7 days to bury, resurrection allowed (✗ 🩹 Mark fix merged | ✗ 🪦 Can bury in 7 days | ✓ 🧟 Report resurrection)
  ok   grave page shows the fix date (0.9s)
2) Fixed 3 days ago
  ok   "Can bury in 4 days", disabled (✗ 🩹 Mark fix merged | ✗ 🪦 Can bury in 4 days | ✓ 🧟 Report resurrection)
3) Fixed 8 days ago → Declare buried
  ok   "Declare buried" is enabled (✗ 🩹 Mark fix merged | ✓ 🪦 Declare buried | ✓ 🧟 Report resurrection)
  ok   published: status buried, buriedAt today (UTC) (1.5s)
  ok   no draft left behind
  ok   grave page shows the burial date (0.7s)
4) Cancelling a resurrection changes nothing
  ok   confirm dialog shows the message
  ok   clicked Cancel
  ok   no zombie was created
5) Unpublished edits block the actions
  ok   all three disabled (✗ 🩹 Mark fix merged | ✗ 🪦 Declare buried | ✗ 🧟 Report resurrection)
6) Buried → Report resurrection → Zombie #1
file:///private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad/studio-cdp.mjs:46
    throw new Error(`timed out waiting for: ${label}`)
          ^

Error: timed out waiting for: document test-bug-life-buried
    at Object.until (file:///private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad/studio-cdp.mjs:46:11)
    at async open (file:///private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad/lifecycle-e2e.mjs:53:3)
    at async file:///private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad/lifecycle-e2e.mjs:127:1

Node.js v24.14.0

Agent

▸ Bash SP=/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab...

Input

$ SP=/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad
python3 - "$SP/lifecycle-e2e.mjs" <<'EOF'
import sys, pathlib
p = pathlib.Path(sys.argv[1]); s = p.read_text()
a = "await graveTab.evaluate('window.__noReload = true')\nawait open('test-bug-life-buried')"
b = "await graveTab.evaluate('window.__noReload = true')\nawait studio.send('Page.bringToFront') // background tabs are throttled\nawait open('test-bug-life-buried')"
assert a in s
p.write_text(s.replace(a, b))
EOF
npx sanity documents create "$SP/life-docs.json" --replace 2>&1 | grep -v "npm warn" | head -1
npx next start -p 3333 > "$SP/next-3333.log" 2>&1 & SERVER=$!
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --headless=new --disable-gpu --hide-scrollbars --no-first-run --remote-debugging-port=9345 --user-data-dir="$SP/chrome-p5e" about:blank >/dev/null 2>&1 & CHROME=$!
curl -s -o /dev/null --retry 30 --retry-connrefused --retry-delay 1 http://localhost:3333/ && curl -s -o /dev/null --retry 30 --retry-connrefused --retry-delay 1 http://127.0.0.1:9345/json/version
(cd "$SP" && node lifecycle-e2e.mjs 9345 http://localhost:3333) 2>&1 | tee "$SP/e2e.log"
kill $CHROME $SERVER 2>/dev/null; wait $CHROME $SERVER 2>/dev/null; pkill -f "scratchpad/chrome-p5e"; true

Output

Upserted:
1) Suspected dead → Mark fix merged
  ok   only "Mark fix merged" is enabled (✓ 🩹 Mark fix merged | ✗ 🪦 Declare buried | ✗ 🧟 Report resurrection)
  ok   published: status fix-merged, fixMergedAt today (UTC) (1.4s)
  ok   no draft left behind
  ok   now waiting 7 days to bury, resurrection allowed (✗ 🩹 Mark fix merged | ✗ 🪦 Can bury in 7 days | ✓ 🧟 Report resurrection)
  ok   grave page shows the fix date (1.2s)
2) Fixed 3 days ago
  ok   "Can bury in 4 days", disabled (✗ 🩹 Mark fix merged | ✗ 🪦 Can bury in 4 days | ✓ 🧟 Report resurrection)
3) Fixed 8 days ago → Declare buried
  ok   "Declare buried" is enabled (✗ 🩹 Mark fix merged | ✓ 🪦 Declare buried | ✓ 🧟 Report resurrection)
  ok   published: status buried, buriedAt today (UTC) (1.5s)
  ok   no draft left behind
  ok   grave page shows the burial date (1.1s)
4) Cancelling a resurrection changes nothing
  ok   confirm dialog shows the message
  ok   clicked Cancel
  ok   no zombie was created
5) Unpublished edits block the actions
  ok   all three disabled (✗ 🩹 Mark fix merged | ✗ 🪦 Declare buried | ✗ 🧟 Report resurrection)
6) Buried → Report resurrection → Zombie #1
  ok   clicked "Let it rise"
  ok   Studio opened the new zombie (c3812e41-4f19-495e-8011-60a6158d9802)
  ok   name "(Zombie #1)" (Lifecycle test: buried (Zombie #1))
  ok   status zombie, born today, timesResurrected 1 ({"s":"zombie","b":"2026-09-28","t":1})
  ok   previousLife → the buried bug
  ok   same language and cause, no epitaph yet
  ok   unique slug (lifecycle-test-buried-zombie-1)
  ok   zombie is published, with no draft
  ok   open grave tab shows "Risen from this grave" without reloading (1.4s)
  ok   homepage lists the zombie (0.2s)
  ok   the old grave cannot rise twice (0.3s)
7) Zombie #1 → Mark fix merged → Report resurrection → Zombie #2
  ok   a walking zombie can have its fix merged (✓ 🩹 Mark fix merged | ✗ 🪦 Declare buried | ✗ 🧟 Report resurrection)
  ok   zombie #1 is fix-merged today (1.8s)
  ok   name "(Zombie #2)", not "(Zombie #1) (Zombie #2)" (Lifecycle test: buried (Zombie #2))
  ok   timesResurrected 2, previousLife → zombie #1
  ok   zombie #2 page shows both past lives, oldest first (0.5s)
8) No stray drafts anywhere
  ok   only the draft we made on purpose exists (["drafts.test-bug-life-drafted"])
  ok   no errors in the Studio
ZOMBIES=a6b031eb-78c1-4104-a5af-8565629d2597,c3812e41-4f19-495e-8011-60a6158d9802
all checks passed

Agent

▸ Bash npx sanity documents delete a6b031eb-78c1-4104-a5af-8565629d2597 2>&1 | grep ...

Input

$ npx sanity documents delete a6b031eb-78c1-4104-a5af-8565629d2597 2>&1 | grep -v "npm warn" | tail -1; npx sanity documents delete c3812e41-4f19-495e-8011-60a6158d9802 2>&1 | grep -v "npm warn" | tail -1; npx sanity documents delete test-bug-life-suspected test-bug-life-waiting test-bug-life-ready test-bug-life-buried test-bug-life-drafted drafts.test-bug-life-drafted 2>&1 | grep -v "npm warn" | tail -1
echo "left over: $(npx --yes sanity@latest documents query --api-version 2026-09-28 '*[_type == "bug" && (name match "Lifecycle test*" || string::startsWith(_id, "test-bug-life") || string::startsWith(_id, "drafts.test-bug-life"))]._id' 2>/dev/null | tr -d ' \n')"; echo "bugs now: $(npx --yes sanity@latest documents query --api-version 2026-09-28 '*[_type == "bug" && !(_id in path("drafts.**"))].name' 2>/dev/null | tr -d '\n' | sed 's/  */ /g')"

Output

Deleted 1 document
Deleted 1 document
Deleted 6 documents
left over: []
bugs now: [ "NullPointerException in checkout", "Timezone bug in scheduler", "Timezone bug in scheduler (Zombie #1)"]

Agent

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

Agent

▸ Bash npx tsc --noEmit && echo "tsc ok"; npm run lint --silent && echo "lint ok"; n...

Input

$ npx tsc --noEmit && echo "tsc ok"; npm run lint --silent && echo "lint ok"; npx sanity schemas validate 2>&1 | grep -E "Errors|Warnings"; npm run build 2>&1 | grep -E "Compiled|TypeScript|rror"; git status --short

Output

tsc ok
lint ok
✖ Errors:   0 errors
⚠ Warnings: 0 warnings
✓ Compiled successfully in 698ms
  Running TypeScript ...
  Finished TypeScript in 923ms ...
 M sanity.config.ts
?? sanity/actions/
?? sanity/lib/lifecycle.ts

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

▸ Bash git add sanity.config.ts sanity/actions sanity/lib/lifecycle.ts && git commit...

Input

$ git add sanity.config.ts sanity/actions sanity/lib/lifecycle.ts && git commit -q -F - <<'EOF'
Add lifecycle document actions to the Studio

Bugs get three actions after Publish: "Mark fix merged" (from suspected
dead or zombie, sets fixMergedAt), "Declare buried" (once the fix has
held for BURIAL_WAIT_DAYS = 7 days, sets buriedAt; otherwise shows
"Can bury in N days"), and "Report resurrection" (after a confirm
dialog, creates a published zombie with previousLife, timesResurrected
+ 1 and a unique slug, then opens it). Zombies go through the same
cycle, so zombies of zombies work.

The actions patch the published document directly, guarded by its
revision, so they never leave drafts, and they are disabled while
unpublished edits exist. A grave rises only once. Dates are UTC.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
EOF
git log --oneline | head -1
npx vercel@60 deploy --prod --yes 2>&1 | grep -E "Production:|Aliased|Error|error|READY|https://bug-graveyard" | grep -v "vercel curl\|vercel inspect" | head -6

Output

4352c77 Add lifecycle document actions to the Studio
  Production      https://bug-graveyard-ab38mxs28-jashanpreet-kaur.vercel.app
[2K[1A[2K[G  Production      https://bug-graveyard-ab38mxs28-jashanpreet-kaur.vercel.app
▲ Aliased         https://bug-graveyard.vercel.app
    "url": "https://bug-graveyard-ab38mxs28-jashanpreet-kaur.vercel.app",
    "readyState": "READY",

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

▸ Bash SP=/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab...

Input

$ SP=/private/tmp/claude-501/-Users-jashanpreetkaur-Desktop-bug-graveyard/0adab70e-beca-4347-ad08-acf0d3b85074/scratchpad
cat > "$SP/live-menus.mjs" <<'EOF'
// Read-only: opens real bugs in the live Studio and reads their lifecycle menus. Clicks nothing.
import {openStudio, wait} from './studio-cdp.mjs'
const [, , port, base] = process.argv
const s = await openStudio(port, base, 'rzjmw6lg')
let failures = 0
async function menu() {
  await s.evaluate(`document.querySelector('[data-testid="action-menu-button"]').click()`)
  await s.until('menu', `document.querySelectorAll('[role="menuitem"]').length > 0`)
  const items = await s.evaluate(`[...document.querySelectorAll('[role="menuitem"]')].filter(b => /fix merged|bur|resurrection/i.test(b.innerText)).map(b => (b.getAttribute('aria-disabled') === 'true' || b.disabled || b.hasAttribute('data-disabled') ? '✗ ' : '✓ ') + b.innerText.trim()).join(' | ')`)
  await s.evaluate(`document.dispatchEvent(new KeyboardEvent('keydown', {key: 'Escape', bubbles: true}))`)
  await wait(300)
  return items
}
for (const [id, want] of [
  ['test-bug-timezone-scheduler-zombie-1', '✓ 🩹 Mark fix merged | ✗ 🪦 Declare buried | ✗ 🧟 Report resurrection'],
  ['test-bug-timezone-scheduler', '✗ 🩹 Mark fix merged | ✗ 🪦 Declare buried | ✗ 🧟 Report resurrection'],
  ['test-bug-nullpointer-checkout', '✗ 🩹 Mark fix merged | ✗ 🪦 Declare buried | ✓ 🧟 Report resurrection'],
]) {
  await s.navigate(`/studio/intent/edit/id=${id};type=bug`)
  await s.until(id, `location.pathname.endsWith(${JSON.stringify(id)}) && !!document.querySelector('[data-testid="action-menu-button"]')`, 60000)
  let got
  for (let i = 0; i < 10 && got !== want; i++) { await wait(1000); got = await menu() }
  if (got !== want) failures++
  console.log(`  ${got === want ? 'ok  ' : 'FAIL'} ${id}: ${got}`)
}
console.log('  studio errors:', s.logs.length ? s.logs.slice(0, 2) : 'none')
console.log(failures ? `${failures} FAILED` : 'live Studio has the actions')
s.close()
EOF
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --headless=new --disable-gpu --hide-scrollbars --no-first-run --remote-debugging-port=9346 --user-data-dir="$SP/chrome-live5" about:blank >/dev/null 2>&1 & CHROME=$!
curl -s -o /dev/null --retry 30 --retry-connrefused --retry-delay 1 http://127.0.0.1:9346/json/version
(cd "$SP" && node live-menus.mjs 9346 https://bug-graveyard.vercel.app)
kill $CHROME 2>/dev/null; wait $CHROME 2>/dev/null; pkill -f "scratchpad/chrome-live5"
for p in / /grave/timezone-bug-in-scheduler; do printf "  live %-34s %s\n" "$p" "$(curl -s -o /dev/null -w '%{http_code}' https://bug-graveyard.vercel.app$p)"; done

Output

ok   test-bug-timezone-scheduler-zombie-1: ✓ 🩹 Mark fix merged | ✗ 🪦 Declare buried | ✗ 🧟 Report resurrection
  ok   test-bug-timezone-scheduler: ✗ 🩹 Mark fix merged | ✗ 🪦 Declare buried | ✗ 🧟 Report resurrection
  ok   test-bug-nullpointer-checkout: ✗ 🩹 Mark fix merged | ✗ 🪦 Declare buried | ✓ 🧟 Report resurrection
  studio errors: none
live Studio has the actions
  live /                                  200
  live /grave/timezone-bug-in-scheduler   200

Agent

▸ Bash tail -2 NOTES.md && cat >> NOTES.md <<'EOF' --- ## Phase 5: Lifecycle docum...

Input

$ tail -2 NOTES.md && cat >> NOTES.md <<'EOF'

---

## Phase 5: Lifecycle document actions (2026-09-29)

### What I asked for

- Three custom Studio actions on bugs, registered through `document.actions` in
  `sanity.config.ts`, keeping Sanity's own Publish, Delete and so on:
  - **🩹 Mark fix merged**, enabled for suspected-dead bugs: status becomes fix-merged,
    `fixMergedAt` becomes today, and the change is published.
  - **🪦 Declare buried**, enabled once a fix has held for 7 days; otherwise the label
    says how long is left ("Can bury in 4 days"). Status becomes buried, `buriedAt`
    becomes today, and the change is published.
  - **🧟 Report resurrection**, for fix-merged or buried bugs. After a confirm dialog
    ("Are you sure? This bug will rise from its grave.") it creates a new zombie bug:
    `previousLife` points at this bug, `timesResurrected` goes up by one, the name
    becomes "<name> (Zombie #n)", with the same language and cause, a unique slug and
    today as `bornAt`. Then it opens the zombie so I can write its epitaph.
- UTC dates. Drafts handled properly: act on the published document and leave no
  stray drafts. Zombies go through the same lifecycle, so zombies of zombies work. The
  7-day rule in a single constant.
- Test it end to end with temporary bugs, check that the site updates live, run build,
  lint and type-check, add this entry, commit and deploy. Explain document actions for
  the write-up.

### What was built

- `sanity/actions/lifecycle.tsx`: the three actions
- `sanity/lib/lifecycle.ts`: `BURIAL_WAIT_DAYS = 7` and small helpers: `todayUTC`,
  `daysBetween`, `daysUntilBurial`, `zombieName`, `slugify`. It doesn't import
  `sanity`, so the site could use it too.
- `sanity.config.ts`: `document.actions` adds the three actions right after Publish,
  for bugs only

**Decisions that go beyond the brief:**
- **"Mark fix merged" also works on a walking zombie.** Without that, a zombie could
  never start its own lifecycle.
- **The actions write straight to the published document,** in one change guarded by
  its revision (`ifRevisionId`). There is no draft step, so nothing gets left behind.
  They are disabled while the bug has unpublished edits ("Publish or discard your
  changes first"), because that draft would later overwrite the new status.
- **The zombie is created already published,** so it appears on the site straight
  away, then opens in the Studio. Writing its epitaph is then an ordinary edit and
  publish.
- **A grave only rises once.** "Report resurrection" is disabled on a grave a zombie
  already came from ("It already rose as …"), and this is checked again at the moment
  of confirming. The next resurrection belongs on the zombie's own grave, which keeps
  every chain a single line.
- **The zombie copies the language and cause of death, but not the severity.** Its
  slug gets `-2`, `-3` and so on if the name is already taken.

**End-to-end test:** a production build, with headless Chrome clicking the real Studio
buttons. Five temporary bugs covered every situation, and **all 34 checks passed**:
- **Enabled/disabled states** in each status, including "🪦 Can bury in 7 days" right
  after a fix and "Can bury in 4 days" for a fix 3 days old.
- **Mark fix merged and Declare buried** wrote today's UTC date, and no drafts were
  left behind.
- **Cancel in the confirm dialog** created nothing.
- **Unpublished edits** disabled all three actions.
- **Resurrecting a buried bug** created "(Zombie #1)" with the correct fields and a
  unique slug, and opened it in the Studio.
- **A grave tab that was already open** showed "Risen from this grave" 1.4s later,
  without reloading.
- **The old grave could not rise twice.**
- **A zombie of a zombie** was named "(Zombie #2)", not "(Zombie #1) (Zombie #2)", and
  its page lists both past lives, oldest first.

Every temporary document was deleted afterwards. After the deploy, a read-only check of
the live Studio showed the right menu for each of the three real bugs.

### What went wrong and how we fixed it

- **"Report resurrection" stayed disabled right after another action.** My first
  version disabled it while it was still checking whether the grave had already
  risen. Sanity re-creates the action component whenever the document changes, so
  each change restarted that check, and the button was disabled for a second or two.
  The test clicked during that window, and the confirm dialog never opened. Fix: don't
  block while checking. The button is only disabled once a zombie is known to exist,
  and the final check happens when you confirm.
- **Test script problem, not an app bug:** headless Chrome slows down tabs in the
  background, so the Studio stalled after the test opened a second tab.
  `Page.bringToFront` fixed it.
- **Signing the headless Studio in:** the Studio keeps its token in `localStorage`
  under `__studio_auth_token_<projectId>`. The test put my CLI login token there
  before the page loaded, in a throwaway Chrome profile, and never printed it.
- **Still open: backfilling old bugs.** `fixMergedAt`, `buriedAt` and
  `timesResurrected` are read-only in the Studio, and the actions always use today. So
  a bug fixed months ago can't be given its real dates by hand; only a script or the
  API can do that.

### Sanity notes for the write-up

**How document actions work, in plain words:**
- The buttons at the bottom of a document in Sanity Studio (Publish, Duplicate, Delete,
  and so on) are all *document actions*, and you can add your own.
- **An action is a small React component.** Sanity renders it for the open document
  and gives it the document's current state: the published version, any unpublished
  draft, its ID and type. It returns a description of a button: a label, whether it's
  disabled, a tooltip, what happens on click, and optionally a dialog such as a
  confirm box.
- **It updates itself.** Because it's a component, Sanity re-renders it whenever the
  document changes. That's how "Can bury in 4 days" and the enabled/disabled states
  stay correct without any refresh logic.
- **It can use the Studio's hooks:** `useClient` to write data, `useRouter` to open
  another document, and `useDocumentStore().listenQuery` for a live GROQ subscription.
- **It runs as the signed-in person.** The action runs in the browser with that
  person's Sanity permissions, so there's no API token in the code.
- **You register actions in `sanity.config.ts`.** `document.actions` is a function
  that receives Sanity's default list plus some context (which type of document, and
  so on) and returns the list to show. The first one becomes the big button; the rest
  go in the "…" menu. Here the lifecycle actions go right after Publish, and only for
  bugs.

**Other things worth mentioning:**
- **Actions can own read-only fields.** Marking fields `readOnly` stops people editing
  them by hand while code can still set them. That turns the dates and the
  resurrection counter into a record of what actually happened.
- **Drafts are separate documents.** Editing creates a `drafts.<id>` copy, and
  publishing copies it over the real one. These actions skip that step and change the
  published document directly, with `ifRevisionId` (the write fails if someone else
  changed the bug first).
- **The built-in dialogs are declarative:** `dialog: {type: 'confirm', message,
  onConfirm, onCancel}`, and `navigateIntent('edit', {id, type})` opens a document.
- **The whole lifecycle runs on the same live pipeline as the site.** Clicking an
  action updates the homepage and grave pages within about a second, through the
  Studio's `<SanityLive />` and the webhook.
EOF
git add NOTES.md && git commit -q -m "Add the Phase 5 notes

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>" && GIT_TERMINAL_PROMPT=0 git push 2>&1 | tail -1; git log --oneline | head -2; git status --short | wc -l | xargs echo "uncommitted files:"

Output

- **Which Sanity CLI runs matters.** `npx sanity` is the project's CLI (v5), and
  `npx sanity@latest` is the newest (v8), which adds `api`, `organizations` and more.
   afae328..f638d72  main -> main
f638d72 Add the Phase 5 notes
4352c77 Add lifecycle document actions to the Studio
uncommitted files: 0

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.

What I learned

Explainable beats impressive. Four signals and a sum are easy to trust and easy to test: the same bug always gets the same score, and the AI only explains a match that has already passed.
Structured content is memory. The detector only works because every grave already had a cause, a language, a component and symptoms as fields, not as a paragraph of prose.
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 only added the connection near the end, so most early deploys were a manual vercel deploy --prod.
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.

What's next

Real fixes. Fill fixUrl from merged pull requests (a GitHub webhook into a Function), so "the previous fix" links straight to the diff. The 18 graves here are invented, so their fixUrl is empty on purpose.
Learn from dismissals. Every dismissed match keeps its signals, which is exactly the data needed to tune the weights and the threshold.
A fifth signal, clearly labelled. A semantic comparison of symptoms could join the four, still shown ✓/✗ with its points, never as a mystery percentage.

Thanks for reading. May your bugs rest in peace, and may the graveyard catch them when they don't. 🪦