product-wiki: answer the Safari question; verify the same pass's own citation fixes

Second half of the 2026-07-26 wiki-growth pass (dispatch #739), continuing on
the branch the first half had pushed without opening a PR.

Competitors — closed the one open question still answerable after the Chrome
Web Store 403 wall: "does the Safari picture differ?" It does not, and leans
further from structured extraction. Smart Calendars AI (the one event-capture
extension spanning Chrome and Safari) describes itself as text and image
recognition, never schema.org; Calendly's Safari extension is scheduling-only;
the App Store's event tools (EventShot, Screenshots to Calendar) are
screenshot-to-event apps, not extensions; and Apple's own date-to-Calendar path
is Data Detectors, documented for Mac document apps rather than Safari page
markup. So the per-site structured-extraction niche is open on Safari too.
Surfaced a follow-up on the screenshot/OCR input axis as a positioning
question, and recorded the 403 evidence caveat rather than overstating it.

Verified the first half's own replacement citations and corrected two that
pointed at the wrong place — a re-derivation this pass could do cheaply
because the Context asked for a staleness spot-check:
- The JSON-LD-over-DOM stance lives in the gcec pack RULES.md *architecture
  rules of the road*, not *Codebase gotchas* (only "supported host is not an
  event" is in Codebase gotchas). Fixed in Domain and Market.
- The ctz unanimity rule is not in RULES.md at all — its home is the contract
  header of extension/event-extractors/helpers/derive-timezone.js. Fixed in
  Domain and Users, quoting the contract's actual terms (two independent hints
  must agree; a trailing Z is not a hint) so the claim is checkable.

Market: qualified "machine-readable markup is increasingly common", true
page-wide but overstated for event pages — cited the ~41%/~26%/<1M-domains
figures here rather than leaving them only in Domain.

Users: reading the ctz contract yielded a user-side implication — refusing to
guess makes a *missing* timezone the expected complaint shape, not a wrong
one — added as an open question for real feedback.

Note for a human: product-wiki/product-requirements/README.md carries the same
dead dev/procedures/technicalGotchas.md citation, and this worker must not
write that folder — filed as a repo issue instead.

Every new claim is cited in its page's ## Sources; one dated ## Growth log
entry per touched page. World sweep: 0 blocking, 11 advisory (all pre-existing).

Refs #692
Refs #739

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: claude

product-wiki/Competitors/README.md

@@ -43,6 +43,27 @@ extension).
   right-click-selection or scheduling tools, not per-site structured extractors.
   No JSON-LD/microdata-aware competitor surfaced on Firefox/Edge either, so the
   structured-extraction niche is open cross-browser too, not just on Chrome.
+- **Safari, checked 2026-07-26, does not differ — and if anything leans further
+  from structured extraction.** Three layers, none of them a per-site markup
+  reader: (1) *browser extensions* — Smart Calendars AI is the one genuine
+  event-capture extension spanning Chrome and Safari, and its own description
+  puts it on **text and image recognition** plus select-text-on-a-page capture,
+  never schema.org/JSON-LD; Calendly ships a Safari extension through the Mac App
+  Store, but it is a scheduling-link tool, not an extractor. (2) *Standalone App
+  Store apps taking the image route* — EventShot (Image To Calendar) and
+  Screenshots to Calendar both turn a **screenshot** into an event (title, date,
+  time, location; the latter also claims recurring-event and
+  multiple-events-per-image detection). (3) *Apple's own OS-level path* is **Data
+  Detectors**, which recognises dates in text and offers to create a Calendar
+  event — but Apple documents it for Mac document apps (Mail, TextEdit, Preview),
+  not as a Safari webpage-markup feature. So the structured-extraction niche is
+  open on Safari too, and the Safari-native centre of gravity is OCR/text
+  detection — the opposite end of the ladder from JSON-LD.
+- **Screenshot/OCR capture is emerging as a distinct input axis.** Eventy already
+  advertised flyer/poster/screenshot input; the Safari scan turned up two more
+  image-first tools. This project has no answer to it by design — it reads the
+  page's markup, and a screenshot has none — but the two approaches fail on
+  opposite inputs, so this is a positioning question rather than a feature gap.
 
 ## Open questions (for the next growth pass)
 
@@ -56,10 +77,20 @@ extension).
   will just burn the next pass's budget.
 - Is there a competitor doing per-site *structured* extraction (JSON-LD/microdata
   aware) rather than generic AI-on-raw-text? Still none found — now checked across
-  Chrome, Firefox, and Edge (see the cross-browser note above). Worth periodic
-  re-checks, since that's closest to this project's approach.
-- Safari-native tools weren't reachable in this pass (no store scan) — a later
-  cycle should confirm whether the Safari picture differs from Chrome/Firefox.
+  Chrome, Firefox, Edge, **and Safari** (see the cross-browser and Safari notes
+  above). Worth periodic re-checks, since that's closest to this project's
+  approach.
+- ~~Safari-native tools weren't reachable in this pass (no store scan).~~
+  **Answered 2026-07-26** — see the Safari bullet under Positioning takeaways: the
+  picture does not differ, and skews to OCR/text detection. Evidence caveat: the
+  same 403 wall that blocked the install-count question also blocked direct
+  fetches of the App Store and vendor listings, so the Safari findings rest on
+  search-result summaries of those listings rather than the listings read end to
+  end. A pass with a working fetcher should confirm the two image-first apps.
+- Does the image/screenshot input axis (Eventy, EventShot, Screenshots to
+  Calendar) draw users this project would otherwise reach, or is it serving a
+  genuinely different moment — a photographed poster, not a page you're reading?
+  Surfaced 2026-07-26.
 
 ## Sources
 
@@ -72,6 +103,12 @@ extension).
 - [20 Best Google Calendar Extensions for Chrome (SavvyCal)](https://savvycal.com/articles/google-calendar-extension/)
 - [Create a Google Calendar Event — Firefox Browser Add-ons](https://addons.mozilla.org/en-US/firefox/addon/create-a-google-calendar-event/)
 - [Checker Plus for Google Calendar — Firefox Browser Add-ons](https://addons.mozilla.org/en-US/firefox/addon/checker-plus-for-calendar/)
+- [Calendly: Browser Extension — Mac App Store](https://apps.apple.com/us/app/calendly-browser-extension/id6746816242?mt=12) — the Safari extension is a scheduling-link tool, not an extractor
+- [How to install Calendly for Safari — Calendly Help](https://calendly.com/help/how-to-install-calendly-for-safari)
+- [EventShot — Image To Calendar (App Store)](https://apps.apple.com/us/app/-/id6747011235) — screenshot → event
+- [Screenshots to Calendar (App Store)](https://apps.apple.com/app/id6757425886) — screenshot → event, incl. recurring and multi-event images
+- [Detect dates, contacts, and more in documents on Mac — Apple Support](https://support.apple.com/guide/mac-help/detect-dates-contacts-documents-mac-mh35744/mac) — Data Detectors, Apple's OS-level date→Calendar path
+- [Safari Extensions — Apple Developer](https://developer.apple.com/safari/extensions/)
 
 ## Growth log
 
@@ -87,3 +124,14 @@ extension).
   chrome-stats.com both refuse the growth worker's fetcher (HTTP 403), so no
   traction numbers were obtainable this pass. Noted in the open question so the
   next run tries a different route. No competitor-landscape claims changed.
+- **2026-07-26 (same pass, second half)** — closed the "Safari still unchecked"
+  question, the one open question this page could still answer without the blocked
+  hosts. Safari has no per-site structured extractor either: Smart Calendars AI
+  (Chrome + Safari) is text/image recognition, Calendly's Safari extension is
+  scheduling-only, the App Store's event tools (EventShot, Screenshots to
+  Calendar) are screenshot-to-event apps rather than browser extensions, and
+  Apple's own date→Calendar path is Data Detectors, an OS text feature documented
+  for document apps rather than Safari page markup. Added the Safari and
+  screenshot/OCR bullets with six sources, recorded the same 403 evidence caveat,
+  and surfaced a follow-up on whether the image-input axis competes for the same
+  moment.

product-wiki/Domain/README.md

@@ -12,11 +12,13 @@ the knowledge that most directly drives extraction requirements.
 ## Machine-readable event formats (as of 2026-07-16)
 
 Ordered roughly by how useful they are to a rule-based extractor — highest-signal
-first. The project's stance (see the *Codebase gotchas* section of
-`.claudinite/local/packs/gcec/RULES.md` — the `dev/procedures/technicalGotchas.md`
-this page previously cited was superseded when that doc was folded into the gcec
-pack) is to **prefer machine-readable markup over brittle DOM scraping**, because
-it survives redesigns and single-page-app rendering.
+first. The project's stance (see the **architecture rules of the road** section of
+`.claudinite/local/packs/gcec/RULES.md`, where it reads "prefer extracting
+JSON-LD/`og:` (which apps still inject) over brittle DOM positions" — the
+`dev/procedures/technicalGotchas.md` this page previously cited was superseded
+when that doc was folded into the gcec pack) is to **prefer machine-readable
+markup over brittle DOM scraping**, because it survives redesigns and
+single-page-app rendering.
 
 - **schema.org `Event` as JSON-LD** — the highest-value target and the one Google
   actively rewards. Emitted as a standalone `<script type="application/ld+json">`
@@ -80,8 +82,15 @@ structural decision behind "one button per event":
 
 ## Timezone & recurrence semantics
 
-- **Timezone** is the trust-critical field: a wrong `ctz` is worse than none
-  (`derive-timezone.js`'s unanimity rule). The domain gives three shapes — an
+- **Timezone** is the trust-critical field: a wrong `ctz` is worse than none —
+  the unanimity rule, stated in the contract header of
+  `extension/event-extractors/helpers/derive-timezone.js` itself (not in the gcec
+  pack's RULES.md): a zone is returned **only when two independent page-declared
+  hints agree**, and `""` whenever anything disagrees. The four hint kinds that
+  file recognises are *stated* (an IANA zone in inline-script JSON), *offset* (the
+  event's own UTC offset — a trailing `Z` explicitly does **not** count, since
+  pages habitually serialize in UTC regardless of venue), *country*, and *locale*.
+  The domain gives three shapes — an
   **offset-bearing** instant (ISO-8601 `…+02:00`, or `.ics` `Z`/`TZID`), a
   **floating** time (no zone; "same wall-clock everywhere"), and **no time signal
   at all**. Only the first lets `ctz` be *derived* rather than guessed.
@@ -198,3 +207,12 @@ structural decision behind "one button per event":
   this page carried: `dev/procedures/technicalGotchas.md` no longer exists — its
   content moved into the gcec pack's `RULES.md` *Codebase gotchas* section — and
   `derive-timezone.js` lives at `extension/event-extractors/helpers/`.
+- **2026-07-26 (same pass, second half)** — verified the replacement citations
+  written earlier the same day and corrected two of them: the JSON-LD-over-DOM
+  stance lives in RULES.md's **architecture rules of the road**, not *Codebase
+  gotchas* (only the "supported host ≠ an event" rule is in *Codebase gotchas*),
+  and the `ctz` unanimity rule is **not in RULES.md at all** — its home is the
+  contract header of `extension/event-extractors/helpers/derive-timezone.js`.
+  Quoted that contract's actual terms (two independent hints must agree; a
+  trailing `Z` is not a hint) so the claim is checkable rather than a pointer to
+  the wrong section.

product-wiki/Market/README.md

@@ -53,12 +53,18 @@ recur across the market:
 
 - **Single-event pages** — a venue, a talk, a concert; one clear event, often with
   `schema.org`/JSON-LD event markup (the highest-signal, most future-proof
-  extraction target — see the JSON-LD note in the *Codebase gotchas* section of
-  `.claudinite/local/packs/gcec/RULES.md`; the `technicalGotchas.md` this line
-  previously cited was superseded when that doc was folded into the gcec pack).
+  extraction target — see the JSON-LD note in the **architecture rules of the
+  road** section of `.claudinite/local/packs/gcec/RULES.md`; the
+  `technicalGotchas.md` this line previously cited was superseded when that doc
+  was folded into the gcec pack).
   Machine-readable markup is increasingly common because search engines reward it
   (Google's "Events" rich results), which is a structural tailwind for any
-  extension that prefers JSON-LD/`og:` over brittle DOM scraping.
+  extension that prefers JSON-LD/`og:` over brittle DOM scraping — but "common" is
+  a *page-wide* fact, not an event-specific one, and this line overstated it until
+  2026-07-26: JSON-LD reaches ~41% of pages and Microdata ~26%, while
+  `schema.org/Event` specifically is on fewer than ~1M domains. The tailwind is
+  real; it does not mean most event pages are structured. See
+  [`../Domain/`](../Domain/README.md)'s format ranking.
 - **Listing/series pages** — a calendar-of-events page with several entries; the
   extension already special-cases "one button per event" for this shape (see
   `product-requirements/README.md` requirement 4).
@@ -98,6 +104,8 @@ recur across the market:
 - [Calendar Applications Market Research Report 2034 (Dataintelo)](https://dataintelo.com/report/calendar-applications-market)
 - [ics2gcal — import .ics into Google Calendar (GitHub)](https://github.com/fmeum/ics2gcal)
 - [ICS to GCal — Chrome Web Store](https://chromewebstore.google.com/detail/ics-to-gcal/ljobcbehhifehkmamikmchekbbljopao)
+- [Structured data — 2024 Web Almanac (HTTP Archive)](https://almanac.httparchive.org/en/2024/structured-data) — the ~41% JSON-LD / ~26% Microdata page-wide figures
+- [Announcing the Schema.org usage statistics dataset (blog.schema.org, 2026)](https://blog.schema.org/2026/06/04/announcing-the-schema-org-usage-statistics-dataset/) — `schema.org/Event` on fewer than ~1M domains
 
 ## Growth log
 
@@ -112,3 +120,8 @@ recur across the market:
   *Codebase gotchas* section), and cross-linked the JSON-LD-prevalence open
   question to the answer Domain already recorded on 2026-07-17, leaving only the
   per-target-host split open here.
+- **2026-07-26 (same pass, second half)** — pointed the RULES.md citation at the
+  right section (**architecture rules of the road**, not *Codebase gotchas*), and
+  qualified the "machine-readable markup is increasingly common" claim, which was
+  true page-wide but overstated for *event* pages specifically — cited the ~41% /
+  ~26% / <1M-domains figures here rather than leaving them only in Domain.

product-wiki/Users/README.md

@@ -49,13 +49,17 @@ never silently overwrite.
   fallback-coverage routine (`.claudinite/local/packs/gcec/tasks/fallback-extractor-improvements/`) is the
   engineering mechanism that narrows this over time; this wiki tracks it from the
   *user* side (which misses actually get reported/matter).
-- Timezone correctness on pages that don't declare one clearly — see
-  `extension/event-extractors/helpers/derive-timezone.js`'s unanimity rule, now
-  documented in the *Codebase gotchas* section of
-  `.claudinite/local/packs/gcec/RULES.md` (the `technicalGotchas.md` this line
-  previously cited was superseded when that doc was folded into the gcec pack);
-  a wrong `ctz` is a trust-breaking failure mode worth watching from the user's
-  perspective.
+- Timezone correctness on pages that don't declare one clearly — see the
+  unanimity rule in the contract header of
+  `extension/event-extractors/helpers/derive-timezone.js` (a zone is emitted only
+  when two independent page-declared hints agree, otherwise none). The
+  `technicalGotchas.md` this line cited until 2026-07-26 was superseded when that
+  doc was folded into the gcec pack; the rule did **not** move into that pack's
+  RULES.md, it lives in the source file's own header. A wrong `ctz` is a
+  trust-breaking failure mode worth watching from the user's perspective — and
+  because the contract refuses to guess, the *user-visible* failure is usually a
+  **missing** timezone rather than a wrong one, so the complaint shape to expect
+  in feedback is "it didn't set the timezone", not "it set the wrong time".
 - No support yet for calendars other than Google Calendar (see Market's open
   question on Outlook/ICS) — track whether this actually blocks real users or is
   a hypothetical gap.
@@ -69,6 +73,9 @@ never silently overwrite.
   which sites matter enough to users to warrant a dedicated extractor?
 - Does the lack of non-Google-Calendar support actually block real users? (Pairs
   with Market's `.ics`-export note.)
+- On timezone, which complaint shape actually shows up — "wrong time" or "no
+  timezone at all"? The refusal-to-guess contract predicts the latter dominates;
+  no real feedback yet either way (surfaced 2026-07-26).
 
 ## Sources
 
@@ -97,3 +104,9 @@ permission/privacy data backing the privacy-conscious persona:
   gcec pack's `RULES.md`, *Codebase gotchas*), and `derive-timezone.js` lives at
   `extension/event-extractors/helpers/`. No new user-side research this pass —
   the personas and pain points here still await real feedback signal.
+- **2026-07-26 (same pass, second half)** — corrected the replacement citation
+  written earlier the same day: the unanimity rule did not move into the gcec
+  pack's RULES.md, it lives in `derive-timezone.js`'s own contract header. Reading
+  that contract also yielded a user-side implication worth tracking — refusing to
+  guess makes a *missing* timezone the expected complaint shape rather than a
+  wrong one — added as an open question to check against real feedback.