docs(fork): clear the pending release note shipped in v0.1.6

[NoahHendrickson]

The prompt-stash data-loss warning queued in .fork/notes/RELEASE-NOTES-PENDING.md is now in the v0.1.6 release notes, so the pending entry comes out per that file's own instruction.

🤖 Generated with Claude Code

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[cursor]

Thermo-nuclear code quality review

No major structural issues found.

This PR only clears a single pending release-note entry from .fork/notes/RELEASE-NOTES-PENDING.md and leaves (none pending). That matches the file's own instruction after the prompt-stash warning shipped in the v0.1.6 release notes. No code, abstractions, branching, or layer boundaries are involved — nothing in the thermo-nuclear rubric applies.

  

_{Sent by Cursor Automation: Thermo-nuclear PR review}

[NoahHendrickson]

Review: the change is correct, but it retires a warning that is still live

Verdict on the diff: correct — merge it. I verified the claim rather than taking it on trust:

• The v0.1.6 notes do carry the prompt-stash warning, and the release was built from 530b90dd — the merge commit of sync: absorb upstream v0.0.30 (27 commits) #33, which is this PR's base. The obligation the file describes ("fold into the next fork release's notes, then delete from here") is genuinely discharged.
• The shipped wording is more precise than the queued note, and it's accurate. Queued said "before this release"; shipped says "v0.1.5 or earlier". Checked against the tree: git cat-file -p 2138ff7e:apps/web/src/promptStashStore.ts (v0.1.5's build commit) has PROMPT_STASH_STORAGE_KEY = "t3code:prompt-stash:v1", while the v2 key plus the unconditional removeItem(LEGACY_…) arrive in f2d2fb2f, which reaches the fork through sync: absorb upstream v0.0.30 (27 commits) #33 in v0.1.6. The version boundary is exactly right.

So the bookkeeping is honest. My findings are all about what the deletion leaves behind.

1. The hazard is not release-scoped, but the warning now is

This is the one I would act on before merging.

The purge in promptStashStore.ts is not a v0.1.6 event. It is module-init, unconditional, on every launch of any build containing f2d2fb2f:

baseStashStorage.removeItem(LEGACY_PROMPT_STASH_STORAGE_KEY);

A user sitting on v0.1.5 today who skips v0.1.6 — it's a prerelease, and make_latest is false for it — and installs v0.1.7 loses their stashed prompts on first launch just the same. v0.1.7's notes will say nothing about it, because the warning was a one-off hand edit to the v0.1.6 body and the note that would have reminded anyone is deleted by this PR.

The file's instruction assumes obligations expire after one release. This one doesn't: it expires when the last install at or below v0.1.5 is gone. Retiring it after a single prerelease drops the warning for precisely the population it exists for.

Concrete fix, with an in-repo precedent: put the line in the workflow template where the other durable upgrade warning already lives. fork-release.yml:183-186 carries the v0.1.1 ~/.t3/userdata warning on every release body and points at a note file for detail. One stanza there, deleted when you decide ≤ v0.1.5 is unsupported, covers every future release instead of one.

2. The queue has no reader

RELEASE-NOTES-PENDING.md is referenced by nothing in the repo. Grepping all *.md, *.yml, *.yaml, and *.ts, the only hit is the file itself. .fork/AGENTS.md — the document that defines the fork workflow — never mentions it. fork-release.yml doesn't read it either: the body is a static template plus generate_release_notes: true, so the warning had to be typed into the published release by hand (the release's updated_at is ~64s after published_at, consistent with a post-publish edit).

This queue worked exactly once, because the session that cut v0.1.6 happened to remember its own note from an hour earlier. Nothing would have caught the miss, and nothing will catch the next one. A file whose entire value is "someone reads this at release time" needs either a line in .fork/AGENTS.md's release section or a step in fork-release.yml that fails the tag when the file is non-empty.

3. The rationale is deleted rather than relocated

What's being removed isn't only a to-do. It is the only in-repo record of a user-visible data-loss event: which release, which storage key, the quota rationale, and the PR that caused it. After this merges, grep -ri stash .fork/ turns up nothing about it — only unrelated stashImageCompression hits.

That knowledge now lives solely in a GitHub release body: mutable, unversioned, and not greppable from a checkout. The fork already has the right pattern — FORK-DATA-ISOLATION-HANDOFF.md is exactly this kind of durable record for the v0.1.1 incident, and the release body links to it. The prompt-stash event deserves the same treatment, even if it's two lines in FORK-CUSTOMIZATION-DECISIONS.md. Move the entry there rather than dropping it.

4. (none pending) is an unmanaged sentinel (nit)

The header says "fold … then delete from here" and says nothing about an empty marker. Nothing instructs the next agent to remove (none pending) when appending an entry, so the natural next state is a file reading (none pending) directly above a pending entry — a file that lies.

Either drop the line (a blank section under that header is already unambiguous), or make it self-clearing: (none pending — delete this line when you add an entry).

---

Bottom line: the diff does what it says, and the claim behind it holds up under checking. But #1 is a real gap in user-facing safety — the warning is being retired while the condition it warns about is still live for anyone on ≤ v0.1.5. I'd land the workflow-template line first, then this.

---

Generated by Claude Code

[NoahHendrickson]

Landed the review's finding 1 in fa14af1: the prompt-stash upgrade warning now rides every release body in fork-release.yml, next to the durable v0.1.1 userdata warning, with a comment saying when it can come out (once installs at or below v0.1.5 no longer matter). That closes the gap where a v0.1.5 → v0.1.7 jump would purge stashes with no warning anywhere.

Findings 2–4 (the pending-notes queue having no reader, relocating the incident rationale, the (none pending) sentinel) are noted but not taken here — they're process improvements beyond this PR's one concern.

🤖 Generated with Claude Code