0.1.13 — 2026-06-30

Added
- The published website is now fully per-locale and discoverable.

Changed

• The published website now localises each per-locale page's filename, not just its
  folder: every non-English page is emitted under its own-language filename.
• Reframed the phishing intro so the paypal.com/paypa1.com look-alike is presented
  as one example, alongside the subtler case of a link routed through a tracker or
  redirector that hides the target URL. Reworded the product claim from "shows you the
  real destination of links" to "shows you the URL each link points to" — the extension
  shows the URL a link points to as written (the full URL, not just the host, and not
  the final page behind a redirect) — and broadened "webmail" to "mail" so it covers
  the Thunderbird/Outlook/Gmail forms too.
• Opera now points to the Chrome Web Store. The landing page's Opera pill links to the
  Chrome Web Store, the Install entry names Opera up front (the Chrome build runs in
  Opera), and the manual lists Opera as a supported browser with the Chrome-build
  install detail in its install steps; a dedicated Opera listing stays marked coming
  soon.

0.1.12 — 2026-06-26

Added
- Live store-listing links for the four published targets. The website landing
page's Install section and the user manual (docs/MANUAL.md) now link straight
to the Chrome Web Store, Microsoft Edge Add-ons, Firefox Add-ons (AMO) and
Thunderbird Add-ons (ATN) listings, mirrored across all ten translated locale
catalogues (site/i18n/<code>.json) and manuals (docs/<code>/MANUAL.md). The
Opera, Gmail and Outlook listings stay marked "coming soon" until they go live.
The published URLs are also recorded per store in docs/store-submission.md and
in the README's Publishing section.
- The landing page's "Supported browsers, mail client and email add-ons" pills are
now clickable for the published targets, each linking to its store listing
(Chrome, Edge, Firefox, Thunderbird); the still-pending pills (Opera, Gmail,
Outlook) stay plain. The label keeps its data-i18n annotation on the anchor, so
the runtime language switcher still localises it in place.

Changed
- The revealed-URL chip (.reveal-urls-url) now carries a fixed white
background (background: #ffffff) baked into the injected stylesheet and is
rendered fully opaque (opacity: 1), so the actual link shown always sits on
a solid white background regardless of the host page's colours. The chip's
default stylesheet weight is font-weight: normal, so an honest link's
revealed URL is not bold unless a urlFontWeight override is configured; a
text-vs-href mismatch adds bold emphasis on top of that default. The runtime
contrast backdrop (applyContrastBackdrop) now samples the chip's OWN
effective background, so it still adds a white backdrop when a host page
overrides the chip's white with a darker, more specific rule.

Fixed
- The ten translated privacy policies (docs/<code>/PRIVACY.md) were stale: they
predated the multi-form rewrite and were missing the entire per-form Permissions
structure — the Browser extension, Outlook add-in and Gmail add-on
sub-sections — and with it the two Gmail OAuth scope identifiers
(gmail.addons.current.message.readonly and gmail.addons.execute). All ten have
been regenerated from the current English docs/PRIVACY.md (machine-translated,
pending human review), restoring the missing sections and scope URLs.
- The ten translated user manuals (docs/<code>/MANUAL.md) were stale the same way,
each missing the The Outlook and Gmail add-ons and Languages sections (16
headings vs the English manual's 18). All ten have been regenerated from the current
English docs/MANUAL.md (machine-translated, pending human review), with their
table-of-contents and in-page anchors verified to resolve against the translated
heading slugs.

[0.1.11] — 2026-06-17

Added
- A source-code archive (web-ext-artifacts/reveal-urls-<version>-source.zip) for
the Firefox (AMO) and Thunderbird (ATN) stores, which require the original sources
whenever an add-on ships esbuild-bundled code. make package now emits it
alongside the per-target zips, and a new make source target builds it on its own
(make source REF=<tag> back-fills a past release, e.g. v0.1.10). The archive
carries reviewer build instructions in docs/mozilla-reviewer-build.md. Generation
is a host script (tooling/source-archive.sh) since the build image carries no git;
it skips gracefully (leaving the per-target zips) when host git or zip is
absent. A REF=<tag> back-fill archives a tag verbatim when that release ships its
own reviewer doc, and folds in the current instructions only for releases that
predate it — printing a warning in that case, since the authoritative toolchain is
whatever the archive's own Dockerfile / pnpm-lock.yaml pin (the doc says as
much) rather than an unverifiable "build process is unchanged" assumption. The
release workflow asserts the source archive exists before uploading, so a
silently-skipped archive cannot pass unnoticed. Covered by make test smoke tests
(tooling/test/source-archive.test.mjs, including the back-fill warning path) and
@source-archive Gherkin scenarios (features/source-archive.feature), both
skipped where the host tools are absent.

Changed
- The default colour of the revealed URL on honest (non-mismatch) links is now a
neutral very dark grey (#1a1a1a) instead of green, in both the browser
extension/Thunderbird add-on (matchColour) and the Gmail add-on card. A green
honest link could be read as a signal that the link had been checked or was
safe, which Reveal URLs does not claim; a neutral colour avoids that false
reassurance while the mismatch colour stays red. Users who saved a custom match
colour keep their choice; the new default applies where nothing was stored. (The
bundled screenshots still show the previous green and should be re-captured.)
- The Outlook add-in manifests (manifest.json and manifest.xml) now stamp a
1.0.x version, decoupled from the 0.x browser extensions, because AppSource
rejects an add-in manifest version below 1.0. The version stamper pins the
Outlook target's MAJOR.MINOR base (TARGET_VERSION_BASE) while keeping the
build number shared, so every shipped manifest still moves in lockstep.

Fixed
- The Outlook add-in XML manifest now passes Microsoft AppSource package
validation. Its VersionOverrides declared VersionOverridesV1_0, but the
ribbon and mobile command surfaces it carries are V1_1-only; that schema
failure made the validator unable to identify the add-in type, surfacing as
the misleading "manifest product ID could not be parsed", "package type not
identified" and "wrong package" errors.

[0.1.10] — 2026-06-16

Added

• Native email add-ons for Microsoft Outlook (Office.js task pane and
  command surface) and Gmail (Google Apps Script card service), so the
  link-destination reveal now works inside the desktop and web mail clients,
  not only in the browser extension. Each add-on ships its own manifest, icons,
  localisation, per-user/roaming settings storage, build pipeline and test
  suite.
• A shared findings module in packages/core, consumed by both new add-ons,
  that derives the displayable link findings (including mismatch highlighting)
  from parsed anchors, keeping the reveal logic identical across surfaces.
• Make targets and a containerised clasp workflow for creating, building and
  deploying the Gmail Apps Script project, including minimal-scope login and a
  bind-mounted token.
• Gherkin scenarios and step definitions covering the Gmail card and Outlook
  task pane, plus an add-on panel test harness and a CardService double.

Changed

• The Gmail add-on resolves link destinations through a bundled URL
  polyfill, brands its card with the project logo and colours the revealed link
  destinations; its OAuth request covers both the gmail.addons.execute and
  gmail.message.readonly scopes.
• Screenshots no longer mask sensitive data with solid black boxes; the store
  and documentation assets were regenerated accordingly.

Fixed

• Addressed review findings across the Gmail and Outlook add-ons, the website
  and the documentation (manifest AppDomains, privacy dates, icon scope,
  remote-code declarations and permission naming).