What we shipped this week — Windows desktop, Google Calendar two-way sync, and ten After Dark help articles

Two platform-expansion items and a deep batch of in-app help. None of the three is a headline feature, but together they close a long-standing gap in coverage. This is the build-in-public log entry.

1. ConKarma for Windows — native Microsoft Store app

The Windows app landed this week. Native to Windows 10 (build 19045+) and Windows 11, distributed exclusively through the Microsoft Store as a signed MSIX package — we do not distribute a side-loadable .exe or .msi outside the Store, and if you find one, it is not from us. The build is feature-parity with iOS and Android. It is optimized for the larger screen and keyboard with calendar week view, expanded journals, side-by-side check-ins, drag-and-drop attachments, full keyboard navigation, and Windows Hello as the biometric unlock factor.

Sign in with Microsoft is the new Windows-native path, alongside Sign in with Apple and Sign in with Google — all three resolve to the same ConKarma account, so the cell, the streaks, and the content move with you across iOS, Android, and Windows.

Three things the Windows build deliberately does not do, worth naming: no background service, no system-tray auto-launch at login (opt-in via Settings → General → Launch at sign-in, off by default), and no integration with the Windows AI sidebar or Copilot. The no-AI-mediation commitment from Promise #3 holds on Windows too.

The full install / permissions / auto-update / uninstall / data-export / troubleshooting article is at /help/windows. The Microsoft Store listing copy (EN) is pinned at content/store/microsoft-store-listing.md in the Minerva repo for transparency.

2. Google Calendar — two-way sync (alongside Apple + Outlook)

ConKarma's cell-shared calendar can now two-way-sync with Google Calendar in addition to Apple Calendar and Outlook. Per-cell-member opt-in, adult-only (gated by COPPA verification for cells with under-13 members), revocable in one tap from either side.

The scope posture is the load-bearing part. We request exactly two Google OAuth scopes and no more: calendar.calendarlist.readonly to enumerate your calendars so you can pick which one to sync, and calendar.events to read and write events on the single calendar you pick. We do not request calendar.readonly (full read across all calendars), calendar.acls, calendar.settings.readonly, contacts, gmail, drive, or any other Workspace scope. The OAuth consent dialog spells out what we asked for; if you see anything beyond those two scopes, it is not from ConKarma — cancel and report it to security@conkarma.app.

What we read: title, start / end / timezone, location (only if the cell member opts in to location sync), description (with Google Meet URLs stripped before they enter the cell view), recurrence rule, attendee list (rendered as avatars only — never emailed or notified), reminder offsets. We skip any event flagged "private" on Google's side entirely.

What we write: only events the cell authored, with a "Created in ConKarma" footer line so external collaborators know the origin. Events created outside ConKarma stay read-only on the ConKarma side — we don't modify calendars we didn't author.

Revocation works from either direction in one tap. Inside ConKarma: Settings → Integrations → Google Calendar → Disconnect. From Google's side: myaccount.google.com → Security → Third-party apps with account access → ConKarma → Remove access. Either path deletes our stored OAuth tokens and revokes the grant cleanly.

The deep-dive article is at /help/google-calendar-sync; the feature page is at /features/calendar; the sub-processor entry is updated at /legal/subprocessors; the privacy policy §6 carries the full integration disclosure.

3. After Dark — ten in-app help articles

Ten articles covering the After Dark surfaces couples have been asking about: Activity Catalogs, Touchplay Dice, Pleasure Discovery, Body Mapping, Sensory Headphones, Massage Pathways, Anticipation Builder, Long-Distance Mode, Reconnection, and Sensory Deprivation.

The canonical render path for these is inside the After Dark companion app — they are in-app contextual help, not marketing. They exist as Minerva pages so the i18n strings live in one place and so the in-app webview has a fallback URL to load. The pages carry noindex, nofollow, nocache robots metadata, are not in the public /help index, are not in the sitemap, and are not in helpRelated — mirroring the non-discoverability posture of the existing /help/ember-alcohol-pairings article.

Every article reflects the same posture commitments that govern After Dark itself: Mutual-Deck-gated reveal (an item surfaces only when both partners independently pre-flagged it; one-sided choices stay private), the safeword always overrides instantly with no countdown and no negotiation, aftercare is built into the surface and not optional for the heavier patterns, and the Ember zone isolation invariant from /promises holds — these surfaces never leak into the main app or to non-Ember cell members.

What this week didn't do

The Windows shipment didn't bring a desktop-specific feature set that diverges from the mobile build — feature parity was the point, not Windows-exclusive surfaces. The Google Calendar integration didn't widen its scope set to make sync "more useful" by reading other calendars on your account — we deliberately ask for the narrowest scopes the two-way sync semantics require, and that's it. The After Dark help articles did not get added to the public help index, the sitemap, or the marketing surface — they are in-app contextual help, and adding them to public discovery would be the wrong shape for the zone.

And then, later the same day — the zone split + Promise #16

The Serene + Ember zone split landed a few hours after the shipment above. After Dark now lives at /ember/after-dark; the ten help articles moved from /help/after-dark/* to /ember/help/* under a single allowlist-driven dynamic route; the old paths return permanent 308 redirects. A new /<locale>/ember/* route tree is gated by a self-attestation DOB form and a 90-day cookie — conkarma.ember_age_gate.v1. Middleware bounces any deep link without the cookie to the /ember interstitial. No KYC. No ID upload. No third-party age-assurance vendor.

The architectural seam, said out loud: if Apple, Microsoft, or jurisdictional law ever escalates and self-attestation stops being sufficient, the code is built so we can swap to a privacy-preserving age-assurance vendor (one that returns an over-18 boolean without revealing your DOB to us) and we'll tell you in /changelog when that happens. We will never swap to KYC, ID upload, or any vendor that collects more than the binary signal we need.

That commitment is now Promise #16 on /promises — "We will never ask for your ID. We ask you to confirm you're an adult." — and gets a mirror section on /trust under "Agewall — self-attestation, no ID". Codified in ADR-114; the agewall implementation is MINERVA-302. Analytics posture aligned with Hestia in HESTIA-678 — both web and Flutter use the ember_* event-name prefix; Minerva's lib/analytics.ts treats /ember/* as a token-bearing zone so the path itself never reaches GA un-scrubbed.

What this promise is not: it is not a commitment to never change the agewall. The architecture preserves the option to upgrade the mechanism (self-attestation → privacy-preserving vendor) if external pressure makes that necessary. The promise is about what we will never collect or store from you in the process.

Where to read more

Engineering details on /build-in-public. The broader posture commitments on /promises and /trust. For questions, /support or support@conkarma.app.

Quiet week of shipping. Three platform commitments landed and the After Dark zone gets the in-app coverage couples have been asking for.