fix(read): stop claiming a wrong password burns a read

[thoda-dev]

What this changes

Closes #21

The warning above Reveal no longer claims that a wrong password consumes a read, and the password
sentence now appears only on pastes that actually have one.

Why

reveal.post.ts has folded the unlock hash into the WHERE of the atomic UPDATE since af3b28e, so
a reader with the wrong password matches no row and the counter never moves. The handler's own
comment says it — "a mistyped password costs nothing" — but the string above the button still said
the opposite, which reads as a warning against retrying when retrying is exactly what the design
allows.

The alert was also rendered unconditionally, so a paste with no password still carried the password
clause. That is the common case, and it points the reader at a field that is not on screen.

What's in it

burnWarningDescription keeps the part that is always true. A new burnWarningPassword carries the
rest and is appended only when meta.passwordProtected:

Revealing consumes one read
Once revealed, this counts against the paste's read limit. (+ on protected pastes) A wrong
password costs nothing: the read is only spent once the password is right.

No server change — the behaviour was already right, only the wording was stale.

Known limit

Pastes created before af3b28e have a NULL unlock_hash, and the isNull branch in the reveal
query makes them match any reveal, so for those the old text remains accurate. They age out with
retention — 7 days anonymous, 30 authenticated by default, though an instance set to unlimited would
keep them.

Distinguishing them in the UI would mean exposing whether a paste carries an unlock hash, which
tells a reader the paste predates that release. That is metadata the /meta endpoint deliberately
does not return, and it buys accuracy for a set that empties itself, so this PR does not do it.

Checks

• pnpm lint, pnpm typecheck and pnpm test pass (86 tests)
• Schema change? None
• Touches crypto, authorization, or the paste read counter? It describes the read counter without
  touching it. Worth confirming the claim against reveal.post.ts rather than taking the string's
  word for it — that mismatch is the whole bug.

AI assistance

• An AI tool was used — Claude Code (Opus 5) found the mismatch against the handler and wrote the
  change; reviewed before merge.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

The new inline comment in p/[id].vue is slightly inaccurate vs server behavior for legacy/NULL unlock_hash cases and should be corrected to avoid misleading future maintainers.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Updates the Reveal warning copy in the read page so it no longer incorrectly claims that entering a wrong password consumes a read, and avoids showing any password-related clause when the paste is not password protected.

Changes:

• Split the warning text into a general “consumes one read” message and a password-specific clause.
• Append the password-specific clause only when meta.passwordProtected is true.
• Update EN/FR locale strings to match the new wording.

File summaries

File	Description
apps/app/i18n/locales/en.json	Adjusts the burn warning copy and adds a new password-specific warning key.
apps/app/i18n/locales/fr.json	Same as EN: updates burn warning copy and adds the new password-specific warning key.
apps/app/app/pages/p/[id].vue	Builds the burn warning description dynamically so the password clause only appears for password-protected pastes.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.