product-wiki growth (2026-07-26): recurrence question answered; superseded repo references corrected

[missingbulb]

Weekly product-wiki growth pass, dispatched by #739. Web mode (WebSearch/WebFetch available).

Human review gate — this task's outcome ceiling is open-pr; the worker must never merge its own PR. Web-researched claims entering a committed knowledge base need a human eyeball, so please sanity-check the citations below.

Questions researched

1. Domain — "Recurring/series pages: what's the right product behaviour?" (the run's main finding)

The question turned out to be two questions, and separating them changes where the cost sits:

• The sink was never the constraint. Google Calendar's render?action=TEMPLATE link — the exact URL this extension emits — takes an optional recur parameter whose value is an RFC-5545 recurrence rule verbatim: required: no, format: text (RFC-5545 specs), example: recur=RRULE:FREQ=DAILY. Fuller rules work in practice (recur=RRULE:FREQ=MONTHLY;INTERVAL=1;BYDAY=2MO;UNTIL=20250609T000000Z). So "hand the user a repeating event" is already expressible in what we emit — nothing about the render URL forces the current one-instance behaviour.
• The source side speaks a different vocabulary. schema.org does not express repeats as an RRULE string. A repeating event carries eventSchedule → a Schedule, whose minimum is repeatFrequency as an ISO-8601 duration (P1W, P1M, P1D — not FREQ=WEEKLY), alongside byDay/byMonth/byMonthDay (byDay as an array of https://schema.org/Monday-style URLs), scheduleTimezone (IANA), startDate/endDate, startTime/endTime, and exceptDate. Emitting recur= from page markup therefore needs a genuine translation step (P1W + byDay → FREQ=WEEKLY;BYDAY=…, exceptDate → EXDATE), not a pass-through.

Net: the recurrence open question is narrowed to a pure product-behaviour choice plus a bounded mapping cost, and a new open question is surfaced — do this extension's target sites emit eventSchedule at all? (the mapping is only worth paying for if the source signal exists; the fallback-coverage corpus can answer it).

2. Competitors — "Pull actual review/install counts" — attempted and blocked, not answered. Both chromewebstore.google.com listing pages and the third-party chrome-stats.com mirror return HTTP 403 to this worker's fetcher; web search surfaces star ratings but not install counts. Recorded as a negative result in the open question so the next pass tries a different route instead of re-burning budget on the same two hosts. No competitor-landscape claims were changed or invented.

Staleness spot-check (the dispatch Context's flagged product-wiki move)

The Context flagged that the product-wiki tree moved in the window. The move itself (commit d0ea13b, dev/routines/auto-fallback-coverage/ → .claudinite/local/packs/gcec/tasks/fallback-extractor-improvements/) had already been swept correctly in Market and Users — those references verify clean.

But the spot-check turned up a different, genuinely dead reference: four wiki citations point at dev/procedures/technicalGotchas.md, which no longer exists. Per .claudinite/local/packs/gcec/README.md, the pack "replaced the always-@-imported dev/procedures/{workflow,github,testing,technicalGotchas}.md docs" — the gotchas content now lives in the gcec pack's RULES.md, section Codebase gotchas (the JSON-LD-over-DOM stance, the "supported host is necessary but not sufficient" rule, and derive-timezone.js's locale/unanimity read are all there). Corrected in Domain, Market, and Users with a note of why (never a silent deletion). Also corrected derive-timezone.js's path to its real location, extension/event-extractors/helpers/derive-timezone.js.

⚠️ One reference this worker could not fix. The fifth technicalGotchas.md reference lives in product-wiki/product-requirements/README.md, which this task must never write. Flagging it here for a human to sweep — it is the same dead path, same fix.

What changed where

Page	Change
product-wiki/Domain/README.md	The recurrence finding (two new sub-bullets under Timezone & recurrence semantics); technicalGotchas.md → gcec RULES.md with a superseded note; derive-timezone.js path corrected; recurrence open question narrowed + one new open question added; 7 sources added
product-wiki/Market/README.md	technicalGotchas.md reference corrected with a superseded note; JSON-LD-prevalence open question cross-linked to the answer Domain recorded 2026-07-17, leaving only the per-target-host split open
product-wiki/Users/README.md	technicalGotchas.md + derive-timezone.js references corrected with a superseded note. No new user-side research — the personas here still await real feedback signal
product-wiki/Competitors/README.md	Negative result recorded on the install-count open question

One dated ## Growth log entry per touched page. No new wiki folders. product-wiki/product-requirements/ and product-wiki/sample-data/ untouched; nothing outside product-wiki/** touched.

Citations added (all in Domain/README.md's ## Sources)

• Google Calendar link parameters (recur, ctz, dates) — add-event-to-calendar-docs — the verbatim recur spec
• RFC 5545 §3.8.5.3 — Recurrence Rule (RRULE)
• How to Create "Add to Calendar" Links (TeamDynamix KB) — &recur=RRULE: example — independent corroboration of recur in a real link
• eventSchedule — Schema.org Property
• Schedule — Schema.org Type
• Additional Schedule type examples — schemaorg/schemaorg Discussion #2948 — the P1W + byDay + exceptDate JSON-LD examples

Sourcing note for the reviewer: schema.org/* and the TeamDynamix KB were reachable via web search but returned 403 to direct fetch from this environment, so their content was read from search results rather than fetched pages; the recur spec and the RFC-5545 link were read directly from the raw add-event-to-calendar-docs source. Worth a spot-check if any single claim matters.

Open questions left for the next run

• Domain — the per-target-host Event-JSON-LD-vs-fallback split (needs the fallback-coverage corpus); the narrowed recurrence product-behaviour choice; new: do target sites emit eventSchedule/Schedule at all?; the .ics-download-link-only question
• Competitors — install/review counts (needs a non-403 data route); Safari-native tools; periodic re-check for a structured-extraction rival
• Market — the AI-extraction-trend driver; the .ics-download-vs-render-URL friction tradeoff; the per-target-host JSON-LD split
• Users — all three remain open; this wiki still has no direct user-research signal

Verification

node .claudinite/shared/engine/checks/check_the_world.mjs → 0 blocking, 11 advisory (all pre-existing: file-placement on requirement cases, gha/scheduled-failure-escalation on the vendored scheduler).

Refs #692
Refs #739

🤖 Generated with Claude Code

https://claude.ai/code/session_01Vj8NauGmfzq2cnzK2o5Gfq

---

Generated by Claude Code

[missingbulb]

2026-07-26 — second half of the same pass added as 1ce76e4 (this PR's head now carries both commits).

A continuation of the same dispatch (#739) picked the branch up, extended it rather than opening a second PR, and did two things:

1. Answered the one open question still reachable behind the 403 wall — Competitors' "do Safari-native tools differ?" They do not, and they lean further from structured extraction. Three layers, none a per-site markup reader:

• Extensions — Smart Calendars AI is the one genuine event-capture extension spanning Chrome and Safari, and its own copy puts it on text and image recognition plus select-text capture, never schema.org/JSON-LD. Calendly ships a Safari extension via the Mac App Store, but it is a scheduling-link tool.
• App Store apps taking the image route — EventShot (Image To Calendar) and Screenshots to Calendar both turn a screenshot into an event.
• Apple's own path — Data Detectors, which recognises dates in text and offers a Calendar event, but which Apple documents for Mac document apps (Mail, TextEdit, Preview), not as a Safari page-markup feature.

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 (the two approaches fail on opposite inputs), and recorded the evidence caveat honestly: the same 403 wall blocked direct fetches of these listings, so this rests on search-result summaries, noted in the page rather than glossed.

2. Verified this PR's own replacement citations, and corrected two. The first commit repointed the dead dev/procedures/technicalGotchas.md references — right call, but two of the new targets are wrong, which is the same defect one move later:

• The JSON-LD-over-DOM stance is in the gcec pack RULES.md's architecture rules of the road ("prefer extracting JSON-LD/og: … over brittle DOM positions"), not Codebase gotchas. Only "a supported host is necessary but not sufficient" (Supported host with no parseable event still suggests a (dateless) event #133) is in Codebase gotchas. Fixed in Domain and Market.
• The ctz unanimity rule is not in RULES.md at all — grep -n unanim over that file returns nothing. Its home is the contract header of extension/event-extractors/helpers/derive-timezone.js. Fixed in Domain and Users, now quoting the contract's real terms (two independent page-declared hints must agree; a trailing Z is explicitly not a hint, since pages habitually serialize in UTC regardless of venue) so a reader can check it at source.

Also: qualified Market's "machine-readable markup is increasingly common" — true page-wide, overstated for event pages — and cited the ~41% JSON-LD / ~26% Microdata / Event-on-fewer-than-~1M-domains figures on that page instead of leaving them only in Domain. And Users gained one open question that fell out of reading the ctz contract: because it refuses to guess, the expected user complaint is "no timezone" rather than "wrong time" — worth checking against real feedback.

check_the_world.mjs re-run after these edits: 0 blocking, 11 advisory (all pre-existing). Still product-wiki/** only; product-requirements/ and sample-data/ untouched.

The product-requirements/README.md dead-citation flag in the PR body above still stands and still needs a human — it is now also filed as its own issue.

---

Generated by Claude Code

[missingbulb]

2026-07-26 — Note from a second, concurrent executor of the same dispatch (#739), stopping rather than stacking.

Why this comment exists

Two executor sessions ran dispatch #739 in the same window. My preflight search for an open claude/product-wiki-growth/* PR ran at ~04:10Z; this PR was created at 04:14:43Z — after my preflight, so the at-most-one-open-dispatch guard didn't catch it. By the time I went to push, claude/product-wiki-growth/2026-07-26 already existed.

Per the task's preflight rule ("do not stack a second round of unreviewed research on it"), I discarded my own edits unpushed and opened no PR. Nothing to reconcile. Flagging the race itself since a duplicate concurrent dispatch is worth a human's attention independent of this PR's content.

Independent corroboration (converged on the same finding)

Working from the same Context hint, I independently reproduced this PR's central staleness finding before discovering it existed. Confirms, not just agrees:

• dev/procedures/technicalGotchas.md is genuinely absent from main — and the gcec pack's own README.md documents why: the pack "replaced the always-@-imported dev/procedures/{workflow,github,testing,technicalGotchas}.md docs".
• derive-timezone.js really is at extension/event-extractors/helpers/derive-timezone.js.
• The product-requirements/README.md fifth reference is the same dead path, and correctly left for a human.
• Attributing "a supported host is necessary but not sufficient" to ## Codebase gotchas is right — it's at RULES.md ~L123–126 ("a real event requires actual data (JSON-LD or a parsed date), never a mere host match", after Boolean(site) surfaced phantom events, Supported host with no parseable event still suggests a (dateless) event #133). ✅

One verified correction worth folding in before merge

The ## Codebase gotchas section pointer is wrong in all three pages — the cited material is real, but it lives in a different section, so a reader following the pointer won't find it. Section boundaries in .claudinite/local/packs/gcec/RULES.md (grep -n '^## '): Codebase gotchas 87–138, Extractor pipeline 151–212, Architecture rules of the road 213–223.

Page	Says	Actually lives in
Domain L15	machine-readable-over-DOM stance → Codebase gotchas	## Extractor pipeline — the "Rendered output isn't deterministic" bullet, ~L176–178: "prefer extracting JSON-LD/og: (which apps still inject) over brittle DOM positions"
Market L55	"the JSON-LD note in the Codebase gotchas section"	same as above, ## Extractor pipeline
Users L52	unanimity rule "now documented in the Codebase gotchas section"	not in RULES.md in any section. The unanimity rule is in the source file's own header ("Every such value must agree", zone resolves to null rather than guessing). RULES.md's nearest related material is also in Extractor pipeline: derive-timezone.js's locale read (~L187) and the ctz corroborating-hints note (~L207–210) — a different rule from unanimity

Suggested fix: swap Codebase gotchas → Extractor pipeline in Domain and Market; in Users, cite the source file for the unanimity rule and drop the RULES.md section claim (or point at the locale read and name it as such). ## Architecture rules of the road is not the right target either — it holds only the new-host-is-one-self-contained-file rule.

For the record, my own unpushed draft had made the mirror-image mistake (attributing the same stance to Architecture rules of the road); pinning the section boundaries is what caught both.

On the Competitors 403

Independently reproduced: WebFetch was non-functional for this dispatch window — even https://example.com returned HTTP 403, so the block is the environment's egress, not Chrome-Web-Store-specific bot defence. Worth reflecting in that open question, since "the Store 403s our fetcher" and "our fetcher can't reach anything" imply different next moves. Recording the negative result rather than guessing numbers was the right call.

No labels touched on #739; tracker #692 deliberately left alone (this window's grew (PR #745) entry is already there — a second entry would double-log one dispatch).

---

Generated by Claude Code

[missingbulb]

2026-07-26 — a third growth pass has been added to this branch (commit d61e11f). This run started before #745 existed, found the branch already pushed, and rebased its work on top rather than opening a second PR — per the worker's "don't stack a second round of unreviewed research" rule. Nothing on the branch was force-pushed or overwritten; where this pass's citation fixes overlapped the earlier ones, the earlier (more accurate) version was kept — notably the finding that derive-timezone.js's unanimity rule lives in the source file's own contract header, not in the gcec pack's RULES.md.

What the third pass adds

It answers the long-standing Competitors open question — "is there a competitor doing per-site structured extraction (JSON-LD/microdata aware)?" — which previous passes could only record as "still none found".

The lane was occupied once, at microformat scale, and then vacated. The "Google Calendar" Chrome extension — a hackathon project "encouraged by the Chrome and Calendar teams at Google", since open-sourced and archived — detected events on the page you were reading via the hCalendar microformat and derivative microformats and offered a one-click add. It is now shut down: "This Chrome extension is no longer available to install, though the source code is available here to fork & modify." The author's shutdown note cites request load from Google teams outweighing his available time — not lack of demand; the extension had 5MM+ users at shutdown. The generic "Microformats" extension (hCalendar → iCalendar / add to Google Calendar) is likewise reported delisted, unmaintained since ~2014.

Structured-data awareness and calendar creation are disjoint categories today. JSON-LD-aware extensions are easy to find and effectively commoditised — JSON-LD Schema Extractor (Chrome and Firefox), LD+JSON Extractor, JSON-LD Checker, SEO Schema Visualizer — but every one is an SEO/developer inspection tool: extract, pretty-print, validate, or graph a page's structured data. None turns an Event block into a calendar entry. So the answer is sharper than absence: nobody has wired the commodity parsing side to the calendar side, and that junction is this project's lane.

Domain/README.md takes the same fact as tooling corroboration on its h-event bullet — the no-dedicated-microformats-reader conclusion now rests on abandoned tooling as well as sub-1% prevalence.

Open questions this raises (both recorded in the page)

• Why did the incumbent vacate, and does that predict our cost curve? Maintenance load at 5MM+ users, not demand. Was that load the per-site/microformat reader itself — a direct warning for this project's per-site extractor set — or its calendar-preview/OAuth surface, which this project deliberately lacks?
• Would a JSON-LD-era equivalent be re-tried by a platform player? The prior attempt predates JSON-LD's dominance (~41% of pages vs microformats' sub-1%). If the lane is empty mainly for historical reasons, platform re-entry is a live competitive risk.

Sourcing and caveat

chimbori/google-calendar-crx (archived; shutdown notice, the "encouraged by" line, the 5MM+ figure) and thanhpd/google-calendar-crx (documents the hCalendar/hResume detection) were read end to end. The JSON-LD-extension claims rest on search-surfaced store-listing descriptions — the same HTTP 403 wall this PR already documents for chromewebstore.google.com and chrome-stats.com also blocked addons.mozilla.org and microformats.org. That caveat is written into the wiki text itself, not just here.

node .claudinite/shared/engine/checks/check_the_world.mjs → 0 blocking, 11 advisory (all pre-existing). Diff vs main still touches only the four product-wiki/** pages; product-requirements/ untouched.

---

Generated by Claude Code