MEMBERS-DIRECTORY-001C — Release and verify the opt-in officer photo directory

[daliu]

Parent: #504. Depends on #505 and #506 merged source.

Officer impact: Makes the reviewed My Account photo/discoverability controls and separate officer name-search gallery available through the no-terminal website path, with a documented stop/undo/escalation procedure.

Officer documentation: Finalize OFFICER_START_HERE.md, docs/officers/README.md, docs/officers/EVENTS_SHOP_MEMBERS.md, docs/officers/ACCESS_CONTINUITY.md, docs/officers/SYSTEM_MAPS.md and text alternative, docs/officers/GLOSSARY.md, and the public Privacy notice with approved owner wording/effective date.

Deployment evidence: Closure requires exact Firebase Rules/Functions/index readback, dependent website revision, Netlify/runmprc.com revision verification, synthetic opt-in/search/opt-out/photo-removal proof, rollback/safe-roll-forward rehearsal, and backup-officer walkthrough. Green source checks alone are insufficient.

Atomic outcome

Extend the fixed protected release gate to deploy and read back exactly the directory Rules/indexes/Functions before publishing the dependent website, then prove the feature in isolated staging and the approved production target using generated synthetic non-face images and made-up accounts only.

Preconditions

• MEMBERS-DIRECTORY-001A — Add private profile thumbnail and opt-in preference #505 and MEMBERS-DIRECTORY-001B — Add bounded officer name search and photo gallery #506 are merged and independently approved.
• DATA-001B — Inventory personal data and approve a minimization/retention matrix #110 records the approved narrow data categories and unresolved backup limitations: processed thumbnail only, discoverability preference, minimal directory projection, minimal audit; no original or biometric template.
• The owner approves exact Privacy notice wording/effective date, officer audience, optional-finder purpose, active-data removal behavior, backup/cache limitation, and contact path.
• CI-001C — Configure protected short-lived Firebase deployment identity #133 or an equivalent protected short-lived deployment identity and named approvers are configured; no downloadable service-account key.
• Isolated staging does not target production Auth/Firestore/Functions.

Acceptance criteria

• Workflow accepts only one fixed release plan and exact current main commit/checks; wrong branch/commit/project/scope/authority/artifact fails before deploy.
• Exact Firestore Rules, indexes, and named directory/profile Functions deploy and are read back before any website publication. Skipped, partial, or mismatched backend publishes nothing.
• Synthetic staging proves default hidden, upload without opt-in, opt-in search, bounded result, opt-out immediate absence, separate photo removal, exact retry, stale command, access denial, and no raw/photo/query log leakage.
• Rollback or safe roll-forward handles backend-before-frontend and frontend-before-backend incompatibility without widening Rules or editing records manually.
• The approved website is published through the controlled host path and exact revision is verified on runmprc.com.
• One synthetic production smoke repeats only non-destructive default/opt-in/search/opt-out/removal checks; no real member/admin record or photo is used.
• Public Privacy and officer docs match verified behavior, explicitly say no face recognition, and distinguish optional finder from official roster/account administration.
• A backup officer with no terminal completes purpose, prerequisites, steps, expected result, stop conditions, success proof, undo, and escalation walkthrough.
• Issue/PR closure reports separately: source changed, tests passed, merged, release approved, Rules/indexes deployed, Functions deployed, website published, runmprc.com verified, privacy notice verified, production data touched (none beyond synthetic), and live behavior verified.

Stop conditions

Stop on missing policy wording/owner, real data, broad provider authority, unisolated staging, backend mismatch, skipped deployment, long-lived/public photo URL, any biometric feature, raw query/name/photo in evidence, or a request to repair production records manually.

Claim protocol

Do not claim until #505/#506 are merged and owner/deployment preconditions are satisfied. Then assign and comment CLAIMED by at ; branch before editing release/provider files.

[daliu]

RELEASE CONTRACT CLARIFICATION — readback must cover all six exact runtime exports: getMyMemberDirectoryProfile, setMyMemberDirectoryVisibility, setMyMemberDirectoryPhoto, removeMyMemberDirectoryPhoto, searchMemberDirectory, and syncMemberDirectoryEntryOnMemberWrite. For the Firestore trigger, verify the deployed idempotent retry/failure policy as well as its name and revision.

Before publication, prove an idempotent, dry-runnable projection repair/backfill path or explicitly prove there can be no pre-existing preference records in the approved target. The repair must re-read current member/preference/photo state, hide/delete malformed or opted-out entries, use the deployed schema/normalization version, expose no roster/query/photo data, and be owned for later schema or normalization upgrades. A console edit is not an acceptable repair.