Community yield feed: stop exposing contributor emails and require a share preview

[paccloud]

What to build

Today every saved calculation — including the user's purchase cost per pound, which is commercially sensitive — is served unauthenticated to all visitors via the public "Recent Calculations (Community)" feed, with no opt-in and no disclosure at save time.

Decision needed first: is the community feed an intentional product feature? If yes, which fields are acceptable to publish (species/conversion/yield are probably fine; cost probably not), and is sharing opt-in per save or per account?

Then implement: an is_public flag on calculations (defaulting existing rows to private), a disclosure/toggle in the save flow, and a public endpoint that only returns opted-in rows with the approved fields.

Context: AUDIT_REPORT.md §3.4 and task 1.4 (branch claude/repo-audit-improvement-ozhlau); Open Question #2.

Acceptance criteria

• Product decision recorded (feed scope, opt-in granularity, visible fields)
• Existing calculations are private by default after migration
• The public endpoint returns only opted-in rows and never returns non-approved fields
• The save flow tells the user what will be shared before they share it

Blocked by

None - can start immediately (decision first, then implementation)

[paccloud]

This was generated by AI during triage.

Re-triage: half resolved — reopened as ready-for-agent for the remaining half

The saved-calculations feed is fixed. On main (d6ee642):

• Calcs are private by default. Migration 003_private_calcs.sql adds is_private DEFAULT TRUE and backfills existing rows (feat(#85): private-by-default calcs with idempotent clientId sync #98).
• Publishing is an explicit, owner-checked PATCH …/publish behind PreviewPublishModal, which lists exactly what becomes public, including cost (feat(#91): require explicit preview before publishing saved calculations #105). Unpublish is available.
• The public calcs query returns only published rows and no user identifiers.

The same class of problem reappeared in the community yield pool (#62):

• The unauthenticated /api/community-data endpoint (JSON and CSV) attributes each shared row to COALESCE(display_name, username).
• For Firebase users, username is their verified email address (usernameFromFirebaseUser). A user who shares a yield row without filling in a contributor profile publishes their email.
• The endpoint ignores the show_on_page consent flag, which the contributors page does honor.
• Sharing is a one-click icon with no preview, unlike the calc publish flow.

Title updated to match the remaining scope.

Agent Brief

Category: bug
Summary: The public community yield-data feed leaks contributors' usernames (often email addresses) and has no disclosure before sharing.

Current behavior:
The unauthenticated community-data endpoint returns every shared yield row, as JSON and as a CSV export, on both backends. Each row's contributor is the contributor profile's display name if one exists, and otherwise the account username. Firebase sign-in stores the verified email as the username, so users without a profile publish their email. The profile's show_on_page consent flag is ignored here. In the "My Data" UI, sharing is a single click with no confirmation.

Desired behavior:

• The community feed (JSON and CSV, both backends) never exposes users.username, email, internal user ids, or any other account identifier.
• Attribution appears only with explicit consent: use the display name and organization only when a contributor profile exists and show_on_page is true. Otherwise the contributor is anonymous (null or empty in JSON, blank in CSV; the UI already renders "Anonymous").
• Before a yield row is shared, the user sees a confirmation listing exactly which fields become public and how they'll be attributed, matching the saved-calc publish preview pattern. Cancel leaves the row unshared. Unsharing needs no confirmation.
• Sharing stays opt-in: rows default to not shared, and upload/import never turns sharing on.
• Local and production behave the same. Ideally the query and row shaping move into the shared handler core next to the other public endpoints.

Key interfaces:

• The community-data handlers (the serverless function, plus the Express /api/community-data and /api/export-community-data routes)
• usernameFromFirebaseUser (context only; don't change it)
• The contributors table (display_name, organization, show_on_page) and listContributors in the DB adapters
• The shared public-endpoint handlers and the DbAdapter interface, for a new listCommunityData-style method
• PreviewPublishModal and the requestPublish/confirmPublish flow, as the pattern for a share preview
• The share toggle in the data-management component

Acceptance criteria:

• A shared row whose owner has no contributor profile returns an anonymous contributor in JSON and CSV, never the username or email
• A shared row whose owner's profile has show_on_page = false returns an anonymous contributor and no organization
• A shared row whose owner's profile has show_on_page = true returns that display name and organization
• No community endpoint response contains username, email, user_id, or firebase_uid
• Unshared rows never appear in either JSON or CSV
• "Share with community" opens a confirmation listing the public fields and the attribution shown. Only confirming calls the share API, and cancelling makes no request
• Express and serverless return identical row shapes, and unit tests cover all three attribution cases
• The existing test suite and lint pass

Out of scope:

• The saved-calculations feed and its publish preview (already fixed)
• How Firebase auth derives usernames for other purposes
• Redesigning the contributors page or profile editor
• Backfilling or unsharing existing shared rows in the production database

---

Generated by Claude Code