alumni_lookup

Changelog

All notable changes to the Alumni Lookup application are documented here.

The format follows Keep a Changelog.

---

[Unreleased]

[1.0.89] - 2026-08-14

Supersedes 1.0.88, which was tagged from a commit whose CI build failed and therefore never reached production. Same contents, plus the test fix. The superseded tag is left in place rather than moved: a force-updated tag is not guaranteed to re-trigger a deploy, which is the one thing this release needs to do.

Phase 28 in full — Google sign-in on the signup surface, one signup per email address, and an identity-only first step — plus Phase 21.9.

Two migrations, both manual (there is no release: phase in the Procfile):

heroku run rails db:migrate --app alumni-lookup
heroku run bin/rails champion_signups:recalculate_status CONFIRM=1 --app alumni-lookup

Production collision count verified 0 before release, which is what the 28.1 index requires. Google redirect URIs must be registered at /auth/signup_google/callback — not google_oauth2 — and GOOGLE_CLIENT_ID / GOOGLE_CLIENT_SECRET must be present, or the button silently does not render.

Changed — Phase 28.3: A shorter first step, and a status that means something

No migration. One rake task, to be run after this deploys: bin/rails champion_signups:recalculate_status CONFIRM=1 (dry-run without the flag). Spec: docs/planning/phases/phase-28/28.3-step-one-and-prefill.md.

• Signing up now asks four things: email, first name, last name, graduation year. ZIP, phone, text-message consent and “last name while at Belmont” moved to the “Where you are now” section. If you sign in with Google, graduation year is the only field you type.
• The email address is locked when it came from Google. It was verified seconds earlier, and retyping it is the one remaining way to type your way into a duplicate. Editing it in the page does nothing — the server uses the verified address regardless.
• “Completed” stops meaning “typed a ZIP code.” ZIP had been a step-1 field since roughly November 2025, and the status calculation returned Completed the moment one was present — so every signup was Completed on creation, five of them having done nothing else. Completed now requires a ZIP and evidence of getting past the first step.
• Nothing that genuinely completed was demoted. The v1 wizard ended at ZIP, so its finishers stay Completed; the rule was chosen specifically to leave them alone. Five rows change, all to “Started”, all of them holding a first-step ZIP and nothing else.
• Staff reporting is unchanged in shape. The status list, the completed filter, and the Alumni prospect logic all read the same values as before — only which rows land where has changed. Phase 25.5 had collapsed the Champion Signup filter from six options to two because every signup read as complete; that premise is now gone and the row is back in the backlog.
• “Add your location” on your profile goes to the form that has a ZIP field again, and your email address gets its own “Change” link beside it.
• Signed in with the wrong Google account? You can back out now. The prefilled signup form carries a “Not you@example.com? Start over” link, and the landing page names the account you’re partway through signing up as instead of quietly sending you back to the same locked form. Rare — most people who start with Google finish with it — but there was previously no way out at all.
• Text-message consent still clears itself when there is no phone number — that rule moved onto the record itself, so it now holds no matter which form, script or import writes it.

Added — Phase 28.2: Continue with Google

One migration (AddGoogleIdentityToChampionSignups) — google_uid and google_linked_at, both nullable, plus a unique partial index. Additive and reversible. Requires 28.1 deployed first. External step, blocking: an authorized redirect URI at https://<host>/auth/signup_google/callback for every signup host. Note the path — signup_google, not google_oauth2. Spec: docs/planning/phases/phase-28/28.2-google-sign-in.md.

• “Continue with Google” now appears on /sign-up and /sign-in. Both buttons post to one endpoint and run one resolver, so which door you came through decides nothing — the destination follows what we find. Click it on the signup page with a record already on file and you are signed in; click it on the sign-in page without one and you get the signup form.
• It works on the first try, with nothing connected in advance. A Google account whose verified address matches your signup links itself on first use. That covers roughly two-thirds of returning alumni on day one, which is why the button shipped before the Connected Accounts screen rather than after it.
• Signed up with a Belmont address, sign in with a personal one? That also works: if the address doesn’t match a signup directly, we check whether it appears on your alumni record and resolve through the BUID. Belmont runs Microsoft rather than Google Workspace, so for the belmont.edu population this is not an improvement to the match rate — it is the only path there is.
• Your stored email is never replaced by the one you signed in with. It may be what Advancement Services has, and CRM changes are not recallable once exported.
• Google never creates a signup. No match means the signup form, prefilled with your verified details, and nothing saved until you finish it. On an intake funnel, creating on a miss is a duplicate generator aimed at the one maintenance task staff already do by hand.
• An unverified address matches nothing. Google can return one under some configurations, and an unverified address that auto-links to an existing record is account takeover. Neither of the app’s two existing Google integrations checks this; a public funnel has to be stricter than the staff tools it was modelled on.
• Two Google accounts, one alumni record? Signing in with the second one works — it resolves through your alumni record the same way it would if nothing were connected yet. The existing connection stays put, and you’re told which account holds it and where to change that. Signing in and changing the connection are separate things: the first is earned by the credential, the second is a deliberate act that belongs on your profile.
• Connected accounts appears on your profile when something is linked, showing when it was connected and offering Disconnect. Unlinking is always safe here — the emailed link and the six-digit code are permanent, so Google can never be anyone’s only way in.
• Declining at Google returns you to the signup sign-in page. Both providers share one OmniAuth failure endpoint, which belonged to the Alumni Network; only this provider’s failures were captured, and the portal’s route exactly as before.
• Privacy policy updated and PRIVACY_POLICY_VERSION bumped to 2026-08-14. Two disclosures: a Google account can become connected without an explicit connect action, and identity may be resolved through an address you did not present. Rows stamped 2026-08-12 accepted neither.
• Events: signin_completed gains method: "google" (no new type — a Google sign-in is a sign-in), plus new google_linked and google_unlinked. to_champion_attributes carries google_uid, so a converted signup keeps its link.

Changed — Phase 28.1: One signup per email address

One migration (AddUniqueIndexOnChampionSignupEmail) — a partial unique index on LOWER(email) WHERE deleted_at IS NULL, built CONCURRENTLY. It refuses to run while any active address is held by two rows, and names them; it will not merge them for you. Resolve them in Signup Admin → duplicates on the current release first. Spec: docs/planning/phases/phase-28/28.1-email-uniqueness.md.

• An email address now belongs to exactly one active signup. The table never had this constraint, and find_active_by_email resolved collisions by taking the newest row. That is a fair guess under a mailed link, which only ever reaches one inbox; it is not a fair basis for signing somebody in on a verified credential, which is what 28.2 adds. The guess is retired rather than hardened.
• Signing up with an address that already has a signup now emails you a link back into it, instead of quietly creating a second record. The mail is the same one 27.2 already sent — what changed is that it used to arrive alongside a duplicate and now arrives instead of one. Your typing survives, and the notice appears on the page rather than a bare validation error.
• An incomplete submission still sends nothing. The nudge fires only when the address is the one thing wrong with the form.
• A removed signup releases its address. Staff soft-delete a record precisely so the person can start again, so the constraint covers active rows only.
• Staff tooling for email duplicates is gone, because the duplicates are. The “Same Email on Multiple Signups” banner, the amber row highlighting and badges, the email Merge buttons, and the email-keyed merge itself were all removed — an address cannot name two active rows for them to act on. Everything BUID-keyed is untouched and is now the only duplicate shape the app can produce, which two different addresses on one BUID still is.

Changed — Phase 21.9: Opportunity listings read as events

One migration (RemoveWhenNoteFromOpportunities) — drops the column 21.8 added one release earlier. It is a column drop, so old dynos calling it during the release window raise; the window is seconds and the column is one release old. Spec: docs/planning/phases/phase-21/21.9-opportunity-event-styling.md.

• The hub splits into Upcoming events and Ongoing opportunities. They answer different questions — am I free that day, versus do I want to — and one list implied a deadline the standing offers don’t have. Each heading only appears when the other group has something in it, so a hub with one kind of thing looks exactly as it did before.
• Dated opportunities get a blue date bar, matching the Alumni Network’s event list. It replaces a heart icon that was identical on every row and said nothing.
• The venue no longer competes with the street address. The first line of Where is the venue and shows in bold; anything after it is the address, shown smaller underneath, and it’s what produces a View Map link. A one-line location like “Various locations” is unchanged and gets no map link — so staff decide whether there’s a map by whether they type an address.
• The form, preview, and thank-you pages use icon rows — calendar and map pin, date above time and venue above address — instead of a label column.
• No date now simply means “Ongoing”. 21.8 shipped a “When — say it differently” box for staff to type that themselves; it’s gone. The only thing it ever had to say was “there is no date”, and leaving the dates blank already says it — so the form now reads Ongoing where the date would be, files itself under Ongoing opportunities, and stays open until switched off. One less field to fill in, and no way for a typed note to disagree with the dates that actually control when a form closes. (“Various dates through the fall” belongs in the intro copy, where there’s room to say which dates.)
• Time and place moved onto separate rows on hub cards, and the date is no longer repeated beside the date bar.

[1.0.88] - 2026-08-14 — never deployed

Tagged, then abandoned: the CI build for the tagged commit failed on a test that passes locally and fails in CI (Devise.omniauth_configs is fixed at Rails boot from GOOGLE_CLIENT_ID, which CI does not set — see .claude/skills/debug/SKILL.md). Nothing reached production under this version. Its contents ship as 1.0.89 with the test fix; the tag is left in place rather than moved, because a force-updated tag may not re-trigger a deploy.

No application code differs between the two.

[1.0.87] - 2026-08-14

Added — Phase 21.8: Opportunity event details

One migration (AddEventDetailsToOpportunities) — six nullable columns and an index. Every existing opportunity is undated, so the new expiry behavior deploys as a no-op. Heroku deploys via GitHub Actions run migrations automatically (deploy-production.yml); a direct git push heroku does not. Spec: docs/planning/phases/phase-21/21.8-opportunity-event-details.md.

One manual step after deploy — no automated backfill. The Almost Alumni Breakfast opportunity has its When / Where / The ask typed into the intro copy; staff move those lines into the new fields and delete them from the intro, or the page shows both. See docs/planning/qa/PHASE_21_LAUNCH_GUIDE.md §4.

• When, Where, and The ask are fields now. Staff had been typing them as When: / Where: / The ask: lines at the top of the intro copy, where they were formatted differently on every form, appeared nowhere except the form itself, and could not be sorted or expired by. “When” takes a start, an optional end, and a free-text override for the cases a date can’t express (“Various dates through the fall”). A blank field is left off the page entirely — no empty labels, no “TBD”.
• The details follow the alum. They now appear on the form, the thank-you page, the opportunity cards on the profile hub (When · Where), and both emails — one partial with six consumers rather than a hand-typed line in one place.
• A dated opportunity closes itself. Once its end date has passed, the public link 404s and it drops off the profile hub. The cutoff is end of day, so a 10am event stays reachable while people are still walking in. Undated opportunities are unaffected. Staff see an Ended badge in place of Live, and an expired opportunity stays fully editable in the CMS.
• The thank-you page survives expiry. It resolves without the expiry filter, so someone who submits on the final day — the busiest day — doesn’t lose their receipt at midnight. Switching an opportunity off still closes every page it has.
• The hub lists soonest first. Dated opportunities lead, undated follow, ties broken by title — replacing straight alphabetical order, which reads as arbitrary once there is a date on the card.
• Optional confirmation email to whoever signed up. Off by default, per opportunity, for the same reason the staff notification list starts empty: a widely shared link must not begin mailing strangers because somebody added a date. It carries the details, the thank-you and next-steps copy, and their own answers — and deliberately carries no profile link, no token, and nothing drawn from a matched Champion record, since the address came off an anonymous form and may not be theirs.
• Staff notification names the event. The per-response email said which opportunity but not when or where, which is what a board liaison or outside partner actually needs.

[1.0.86] - 2026-08-13

Scope grew before this shipped. The version section was written on August 6 for the mail-domain change alone. It was never tagged, and all eight sub-phases of Phase 27 landed in the meantime — so this release is both. Phase 27 first; the mail-domain notes follow unchanged.

Three migrations. Heroku deploys via GitHub Actions run them automatically (deploy-production.yml), but a direct git push heroku does not — there is no release: phase in the Procfile.

Changed — Phase 27.8: One front door, and the code leads

Follow-on to 27.7, written against the shipped flow rather than a spec. No migration, no new route, no policy change. Spec: docs/planning/phases/phase-27/27.8-one-front-door.md.

Three of its four items were the same defect wearing different clothes — a second copy of a decision, each of which had drifted within one sub-phase of being created. See §7 of the spec, and the “Link first, share second, copy never” rule now in /patterns.

• All sign-in now goes through /sign-in. The landing page and the opportunity thank-you page each carried their own copy of the “email me a link” form. Both are links to the sign-in page now, so there is one form, one confirmation state, and one code box — the copies had already drifted, having neither the code box nor the “keep me signed in” checkbox that were added to the real one.
• The landing page says what it means. “Already filled this out? Get your update link →” named a mechanism that is now one of two; it reads “Sign into your Champion Profile →” and goes to the sign-in page rather than scrolling to a form.
• Your email carries over. Enter your address, and the code box on the next screen arrives filled in with it — the only thing left to do is type the six digits. It is still editable, so a typo is fixable without starting over.
• The sign-in email leads with the code, and the link comes second. The link opens your profile on whatever device reads the mail, which loses whatever you were in the middle of; the code takes you back to the tab you left, still on the opportunity form or the page you came from. The link stays for the case it is actually better at — reading the email somewhere your original browser isn’t.
• The landing page knows you when you’re signed in. It kept selling after you had already bought: under the “Welcome back” banner sat “Get Started”, which opened a second signup under your own address. The same page now reads as a reference — the same explanation of what an Alumni Champion is and the four ways Champions show up, with every button pointing at your profile.
• The header logo takes you home, and home moves. Signed in, it goes to your profile; signed out, to the landing page.
• The email now matches what you asked for. Two shapes, chosen by whether you have somewhere to type a code:
  • From Sign in, where a code box appears as soon as you submit: the email leads with the code, and the profile link sits underneath as a small “reading this on a different device?” line.
  • From “Email me my link” on the signup form, where you stay on the half-filled page: a link email with a prominent button and no code at all — a code with nowhere to enter it is a puzzle, not a convenience.
• Fixed: four lines of developer commentary rendered as page copy inside “Things you’ve said yes to” on the profile hub, and on the opportunity thank-you page. An ERB comment ends at its first %>, so an escaped example tag inside one closed it early and leaked the rest. Every view in the app is now scanned for this on every build.

Changed — Phase 27.7: One signed-in state, and a code to get there

Migration: create_champion_signup_signin_codes. Reverses Phase 27 Decision B. Privacy policy version bumped to 2026-08-12 — the remembered-device cookie changed meaning, so anyone who ticked the box before that date consented to something weaker. Spec: docs/planning/phases/phase-27/27.7-one-signed-in-state.md.

• “Keep me signed in” now actually keeps you signed in. The cookie used to grant a reduced state — your first name and a partly masked email, no profile access, no edits. That in-between tier was the largest source of complexity on the whole surface, and its premise did not survive the device-list cut: that feature was dropped because “they can just sign out,” which is the same mitigation the tier existed to avoid relying on.
• Please read this if you use a shared computer: ticking the box now means whoever uses that computer next is signed in as you, for six months. It is unticked by default, the label says so, and Sign out ends it immediately.
• Still no password, and this was reviewed rather than assumed. A password would add a credential people forget on a signup funnel plus a reset flow — and a password reset flow is a magic link, so the mechanism would stay and a second one would join it.
• Every sign-in email now carries a six-digit code as well as the link. Read the email on your phone while working on a laptop? Type the code on the laptop instead of getting signed in on the wrong device. Codes last 15 minutes, work once, and die after five wrong attempts.
• You come back to where you were. Click “Sign in” from an opportunity form and you land back on that form afterwards, not on your profile with the link to find again.
• Cookie and privacy policies rewritten to match. The build asserts they say the right thing: the old “being remembered is not being signed in” assertion inverted rather than being deleted.

Added — Phase 27.4 + 27.5: The recognized tier reaches the opportunity form and the hub

No migration. Specs: docs/planning/phases/phase-27/27.4-opportunity-flow.md, 27.5-hub-additions.md. Phase 27 is complete — all six sub-phases shipped, and all four of its open questions are closed.

• A remembered alum no longer retypes their details to say yes to something. The opportunity form shows a collapsed card — first name, masked email, and “Not you?” — instead of five blank fields, and the contact details are filled server-side on submit.
• Those details never reach the page. Not in a field, not in a hidden input. Phase 27 Decision B contradicted itself here (its tier table promised a “prefilled contact block”, the paragraph beneath forbade “PII beyond first name and a masked email”); the restriction won, so a borrowed laptop still learns only a first name and a domain. Integration tests assert the real values are absent from the response body.
• A remembered device still cannot open a profile. The thank-you page greets a recognized submitter by name and offers to email them a link — never a direct route to the hub, and never a freshly minted profile token, which the redirect had been handing out unconditionally.
• “Things you’ve said yes to” on the profile hub: every past opportunity response, collapsed to title and date, expanding to exactly what they told us. Answers a question a list of titles cannot.
• “Already signed up as an Alumni Champion? Sign in” now appears on every opportunity form for a visitor we don’t recognize. The way back to an existing record used to be a page they had no reason to visit.
• Opportunity events now record which tier submitted (anonymous / recognized / verified).

Fixed — Phase 27.4 + 27.5

• Checkbox answers rendered wrong on the public thank-you page since 21.7: a two-box answer printed as "FridaySaturday" with no separator, and a box with nothing ticked printed an empty row. Found while extracting the receipt into a partial the profile hub now shares.
• The opportunity form ignored a merge. It resolved the session with its own lookup rather than the shared one, so a visitor whose signup had been merged away silently went anonymous there while the hub resolved them correctly.

Added — Phase 27.3 + 27.6: Remembered devices, and their disclosure

Migration: create_champion_signup_sessions. New recurring task: champion_signup_sessions:prune (schedule daily — it is the retention rule). Spec: docs/planning/phases/phase-27/27.3-remembered-devices.md.

Shipped as one release deliberately: Phase 27 §5 requires the compliance half not lag the cookie, and the coupling is now asserted in tests rather than trusted to a checklist.

• “Keep me signed in on this device for 6 months.” An unticked checkbox on /sign-in sets an optional cookie backed by a new champion_signup_sessions row. That checkbox is the consent — no cookie banner, because there is no banner-worthy category: no analytics, no pixels, no ad tech, no sale or sharing.
• Being remembered is not being signed in. A remembered device gets a first name and a masked email (j••••@example.com) and nothing else — no hub access, no edits, no unmasked contact details, and a permanent “Not you?”. That asymmetry is what makes a 6-month cookie safe on a shared or kiosk computer, so the tests that guard it are the negative ones.
• Signup::Identity now owns the anonymous / recognized / verified decision for the whole surface, resolving explicit credentials ahead of ambient ones (profile token → session → device cookie). It delegates session resolution to the one place that already owned it rather than re-deriving it.
• Remembered devices follow a merge. A device whose signup was merged away resolves to the surviving row, making it the fourth credential to route through 27.1’s follow_merge, after the access code, the profile token, and the session.
• Sign-out and “Not you?” destroy the device row, not just the cookie — a cookie the browser forgot but a row we kept is still a live credential. Other devices are untouched.
• The consent travels in the emailed link, not in the requesting browser’s session, because people tick the box on a laptop and open the email on a phone. The device that opens the link is the one remembered.
• New activity events: signin_completed, device_remembered, device_revoked.

Changed — Phase 27.6: compliance

• Montserrat is now served from our own domain. The alum-facing signup surface makes no requests to Google, where before every page load disclosed the visitor’s IP address to fonts.googleapis.com and fonts.gstatic.com — no cookie, but the IP transmission is the fact pattern behind the January 2022 Munich ruling. Ten woff2 subsets with their unicode-range declarations preserved, so a Latin-only visitor still downloads exactly two files. OFL license included.
• Privacy policy revised and version bumped to 2026-08-08. It now discloses the second cookie and its duration, explains that being recognized is not being signed in, states that we do not sell or share personal information (the documented GPC posture — no no-op handler), and discloses the email-check enumeration trade-off rather than leaving an oracle sitting silently under the policy’s no-tracking claims.
• Cookie policy corrected. Three March statements had become untrue: “that’s it — one cookie”, the third-party row that was true but doing work it could not do, and the no-banner rationale, which now rests on point-of-use consent instead of everything being strictly necessary.
• Retention rule ships with the table. champion_signup_sessions:prune deletes expired rows; expired rows are already inert before it runs. Deleting a signup now destroys its device sessions rather than leaving rows holding a user agent and an IP.
• Only two layouts actually loaded Montserrat (signup, application); the other three active layouts load Material Icons, a different Google font this phase did not scope.

Fixed — the “no third-party content” claim was not true

• Writing that sentence into the privacy policy and testing it revealed that /sign-up eagerly fetches five JavaScript modules from cdn.jsdelivr.net on every load — flowbite, trix, chart.js, chart.js/auto, @kurkle/color, pinned in config/importmap.rb and emitted as <link rel="modulepreload">. Beyond the IP disclosure, that is third-party JavaScript executing on the page where alumni type their contact details.
• Both policies now name jsDelivr instead of implying no third party exists, and the external-origin baseline is pinned as a ratchet that may shrink but never grow. Vendoring the modules is tracked in BACKLOG alongside CSP enforcement; phase-27 §9 explicitly scoped it out of this phase.

Added — Phase 27.1: Duplicate prevention and email-keyed resolution

Migration: add_merged_into_id_to_champion_signups. Spec: docs/planning/phases/phase-27/27.1-duplicate-prevention.md. Ships after 27.2, whose throttles meter the check endpoint below.

• Email leads step 1, with an inline “already registered?” check. A returning alum on a new device used to fill in the whole form before anything told them they already had a signup. Tabbing out of the email field now asks POST /sign-up/email-check, and a match offers a one-click “email me my link” that sends through the existing /profile-link and leaves the half-filled form intact. Nothing blocks — submitting anyway still creates the row, exactly as before (Phase 27 Decision C), with 27.2’s nudge email as the backstop. The endpoint is an enumeration oracle by design: gated on the form’s honeypot, metered at 10/hr/IP, and answering {"known": true|false} and nothing else.
• ChampionSignupMerger.merge_duplicates_for_email. Both existing merge entry points required a non-blank BUID, and BUID assignment is a manual staff action — so a signup with no matching Alumni row could never be merged at all. The email key reaches it. Merging fills a blank buid from the sources, which the merger never did before; under the BUID key that was a no-op, but under the email key it would have soft-deleted the only row linked to an Alumni record.
• An email set whose rows carry different BUIDs is refused, not warned about. A shared family inbox and a typo produce the same shape as one person returning. There is deliberately no bulk email merge.
• duplicates_by_email fixed before it drove any UI. It grouped on the raw email column with no blank exclusion — case-sensitive, and every blank-email row collapsed into one enormous false duplicate set. Harmless while nothing called it.
• Email duplicates surfaced in Signup Admin — sidebar badge, amber row flags, show banner, and the status=duplicates filter, alongside the BUID equivalents.
• A mailed link on a merged-away row now works again. ChampionSignupMerger soft-deletes its sources and every credential resolver scoped to active, so a permanent access code already sent in mail-merge outreach stopped resolving the moment staff merged that row — no redirect, no notice. Access code, profile token, and device session all follow merged_into_id to the surviving record. A row soft-deleted by deletion still resolves to nothing.
• signup_merged activity event, recorded against the surviving row with the merged ids, the key used, and who merged.

Added — Phase 27.2: Sign-in front door

No migration. Spec: docs/planning/phases/phase-27/27.2-signin-front-door.md. 27.2 ships before 27.1 — 27.1’s inline email check is an enumeration oracle that Decision D requires be throttled, and every throttle it needs is in this sub-phase.

• GET /sign-in — a dedicated sign-in page. The app has done passwordless authentication since 19.7, but layouts/signup had no navigation, so the “email me a link” form was reachable only by scrolling the landing page. A returning alum on a new device had no way in. The page wraps the existing POST /profile-link flow unchanged and stays enumeration-neutral: identical response for known and unknown addresses.
• Clicking an emailed profile link now signs you in for real. show was the only entry point that never established a session — the just-signed-up path and the access-code path both did — so a magic-link visitor was carrying a credential in the URL rather than being signed in. The hub threaded that token through its own links, so the hub worked and everywhere else on alumnichampions.com made you anonymous again. A 72-hour profile token now grants the same 2-week session a never-expiring access code always has.
• Header shows your first name and a “Sign out” button when signed in. First name only: Phase 27 Decision B allows the full hub to a session-verified visitor, so this discloses nothing new, and 27.3’s recognized tier will share the same partial.
• Signing out lands on the landing page with a confirmation, not on a blank signup form. “Start a new signup” on a shared device is unchanged and still goes to the form.
• Duplicate-nudge email. Submitting step 1 with an already-registered address still creates the new row (Phase 27 Decision C keeps resolution staff-side — no create-time merge), and now also mails that address a link to the profile it already has. The recipient is always the address the submitter typed, so it cannot be aimed at a third party. Resolves Phase 27 open question 3.
• signin_link_sent activity event. link_requested is unchanged and still records the landing-page form, so existing rows keep their meaning.

Fixed — Rate limiting was never actually working

Two defects found by the first test ever written against a throttle in this repo. Both predate Phase 27 and were invisible from outside, because an abusive request still got refused — just not the way the code was written to.

• Every throttle returned 500 instead of 429, and every blocklist 500 instead of 403. throttled_responder and blocklisted_responder were written as ->(env), but rack-attack 6.0 passes a Rack::Attack::Request, which has no #[]. Consequences: no Retry-After header was ever sent (so well-behaved clients retried immediately), the responders’ own log lines never ran, and every rate-limit trip was recorded as an application exception.
• fail2ban/throttle-abuse never banned anyone. It incremented its counter from inside the blocklist, reading rack.attack.matched — a key no throttle has written at that point, because Rack::Attack evaluates blocklists before throttles. The blocklist now only reads the ban flag; the counter is incremented from the throttle.rack_attack subscriber.

Changed — Throttles now cover the live signup endpoints

• /profile-link is metered for the first time. It sends a magic link to any address on request and had nothing in front of it but the global 300/5min and the honeypot — an unmetered email-bomb vector. Now capped per IP and per address; the per-address cap is the one that matters, since a per-IP cap alone still lets one attacker spray many addresses.
• New signup creates are metered — 5 per 30 min per IP, 3 per 15 min per address. Deliberately scoped to the tokenless who_you_are submit rather than to POST /sign-up, because that path serves all 13 funnel steps: a flat per-path rule would have 429’d the first alum to complete a signup, and worst for the ones who answer every question.
• champion-logins/ip, champion-signups/ip, champion-signups/email renamed to portal-*. They guard the frozen belmontalum.com portal’s Devise routes (/login, /signup — no hyphen), not the live signup ecosystem their old names implied. Phase 27’s spec originally called them “stranded” and proposed removing or repointing them; both would have stripped rate limiting off a reachable production login. Renamed in place, with the surface named in a comment.
• signup-email-check/ip (10/hour) ships ahead of its endpoint, so 27.1’s enumeration oracle is never live unmetered. Inert until that route exists.
• An expired profile token, an unauthorized hub view, and an unknown access code now redirect to /sign-in rather than the landing page — the “get a fresh link” message belongs above the form that issues one.

---

Mail domain — carried forward from the August 6 draft of this release

Deploy step required before this ships: mail.alumnichampions.com must be verified in Mailgun with SPF, DKIM and MX records, plus two Mailgun routes (alumni@ forwards to alumni@belmont.edu, noreply@ discards). Full record-by-record instructions are in docs/deployment/MAILGUN_DNS_SETUP.md. No env vars need setting — the code defaults are the intended production values. No migration.

Changed — Signup ecosystem sends from its own domain

• Champion Signup email now comes from mail.alumnichampions.com, not mail.belmontalum.com. Every signup email — welcome, profile link, admin notification, opportunity response — was sending from the portal’s domain, so mail from a product at alumnichampions.com arrived branded as belmontalum.com. Alum-facing mail sends from alumni@mail.alumnichampions.com; opportunity notifications from noreply@mail.alumnichampions.com. Reply-To is unchanged at alumni@belmont.edu.

• MailgunDeliveryMethod now picks a sending domain per message, matching the message’s own From address against MAILGUN_SENDING_DOMAINS. Changing only the From header would have been worse than leaving it alone: a single global MAILGUN_DOMAIN routed everything through belmontalum, so alumnichampions mail would have gone out signed d=mail.belmontalum.com — unaligned on both SPF and DKIM, and a DMARC failure under any policy stricter than p=none. MAILGUN_DOMAIN is now the fallback for unrecognized senders rather than the universal route, so portal and Lookup mail are untouched.

• The two alumnichampions mailboxes are not interchangeable. Alum-facing signup mail uses the forwarded alumni@; the staff- and partner-facing opportunity notifications use the discarded noreply@. Tests assert the two never converge.

Fixed — Opportunity notifications were being filed as spam

Verified against a live staging send (Aug 6, 2026): SPF, DKIM and DMARC all passed with an aligned d=, and Microsoft still scored the message SCL:5 / SFV:SPM / CAT:SPM. Authentication proves identity; it does not stop a message being filtered on shape.

• One message per recipient, addressed to that recipient. These were sent as a single message with the sender in To: and the whole notification list in bcc — the shape of bulk mail, and the strongest spam signal in the message. Per-recipient sends hide the list from its own members just as well, which was the only reason for bcc. To: is no longer the From address, so the sending mailbox is no longer a delivery target.

• Reply-To is the team inbox, not the responding alum. It was set to the alum’s own address so staff could hit Reply; that address is usually freemail, and a freemail Reply-To on a domain other than the From is a phishing signature. The alum is now one click away via a mailto: button in the body instead.

• A failed send to one recipient no longer costs the rest their notification — the rescue in NotifyOpportunityResponseJob moved inside the per-recipient loop, where there is now something to salvage.

Security — Mailgun API key was sent in the clear

MailgunDeliveryMethod constructed its client as Mailgun::Client.new(api_key, api_host, 'v3', false). The fourth positional argument is ssl, not a debug flag: it built an http:// endpoint and set ssl.verify false, so the API key went out as HTTP Basic auth unencrypted on every send. Now true. Pre-existing; unrelated to the domain change.

[1.0.85] - 2026-08-05

One migration, run automatically by the deploy workflow (deploy-staging.yml and deploy-production.yml both run rails db:migrate). Adds opportunities.listed (boolean, default true) and opportunities.notify_emails (text, nullable), plus a partial index on (active, listed). Additive and backfill-safe — every existing opportunity keeps today’s behavior, and there is no data step to run by hand.

Nothing else in this release needs running: no rake task, no backfill.

Added — Alumni Opportunities (Phase 21.7)

• Checkbox questions. A sixth field type for “pick any that apply”, where the only previous options were a dropdown that lost information or a long-text field nobody could filter on. Available on every opportunity; options are validated server-side against the list the CMS authored, same as a dropdown. Answers export as one semicolon-joined CSV cell.

• Link-only opportunities. Listed and Link only are now separate from on/off. Until now, making a form’s link work was the same switch as advertising it on every returning alum’s profile page, so a form for just the Alumni Board or just one newsletter was impossible. A link-only opportunity is fully live and serves its direct link; it simply isn’t listed anywhere. Active still governs reachability — switching an opportunity off 404s the link for everyone, listed or not.

• Per-opportunity response notification emails. Each opportunity carries its own comma-separated recipient list, so the person who actually owns a form gets the response whether or not they have a Lookup Portal account. The email includes the submitted answers, contact details, and — when the response links to a Champion record — graduation year, location, affinities, industry and job title, plus the matched alum’s degrees, BUID and BQID. Recipients are BCC’d; replies go to the submitter.

  A match made on email address alone is labeled unconfirmed in the email itself. Shared inboxes, couples and typos all produce email matches, and a guess must never read to staff as a confirmed identity.

  Recipients without a Lookup Portal account don’t get the “open in the staff queue” link, which would only land them on a login screen. Delivery splits by audience when a list contains both; a list that is all one or all the other stays a single email.

  Blank recipient list is the default and sends nothing, which is exactly how every opportunity behaved before this release. Phase 21.4 deliberately shipped in-app and push notifications only, because a widely shared opportunity link must never flood an inbox; making email opt-in per form preserves that. Admins still get their in-app notification either way, and a mail failure cannot cost staff their queue badge.

• Print / Save as PDF for a single response. Signup Admin → Responses → open one → Print / PDF opens a print-styled page; save it from the browser to send a response on to someone else. Built live off the current record rather than archiving what was emailed, so a response linked to a Champion after the notification went out prints with the record we hold today. Carries the unconfirmed-match caveat and a print date, so a forwarded copy keeps its context. No PDF library added — a print stylesheet avoids a new dependency on a stack with known memory limits.

• Trimmed “What we already know” in the notification email to what staff act on: graduation year, industry, job title, employer, interests, affinities, and degrees. Location and district came out because the contact block directly above already answers it from what the alum just typed; BUID, BQID and the signup date came out as reconciliation data. The CSV export still carries both ids.

Fixed

• A required checkbox with nothing ticked could be submitted. Found while building the field type above, before it shipped. Answer blank-checking ran through value.to_s.strip.blank?, and [].to_s is "[]" — not blank — so an empty multi-select passed validation. Blank checks are now array-aware.

• Long questions rendered off the edge of the notification email. The answers block used a two-column table whose label cell was set white-space: nowrap — correct for short labels like “Email”, wrong for a staff-authored question running 60–100 characters, which pinned the table wider than the email container and pushed every answer out of view. Questions and answers are now stacked, and essay answers keep their paragraph breaks.

[1.0.84] - 2026-08-05

Post-deployment: run the maiden-name cleanup — dry run first, and read it.

heroku run bin/rails champion_signups:cleanup_maiden_names --app alumni-lookup
heroku run bin/rails champion_signups:cleanup_maiden_names CONFIRM=1 --app alumni-lookup

The dry run’s NEEDS REVIEW section is the part no task should decide — values it could not confirm as first-name-plus-surname, and any exported / verified CRM row Advancement Services may already hold with the extra word. Nothing else in this release needs running: no migration, no schema change.

Fixed

• Signup form: “Name while at Belmont” → “Last name while at Belmont.” Alumni read the old label as “your whole name back then” and answered it with first + last, so champion_signups.maiden_name collected values like "Kate Whitfield" — and, for linked signups, handed them to Advancement Services as two-word maiden names. Field now carries an e.g. Smith placeholder as well.

• Cleanup for what the old label collected. bin/rails champion_signups:cleanup_maiden_names (dry run; CONFIRM=1 to apply) strips the first name from champion_signups.maiden_name and from pending crm_data_changes rows. The rule is deliberately narrow: a value is rewritten only when its first token is a first name we already hold for that person — the signup’s own, the linked Alumni’s first_name or pref_name, or a nickname variation of any of them (Alumni.generate_name_variations, so a Katherine who typed “Kate Whitfield” is caught). Genuinely multi-word surnames — “Van Der Berg”, “De La Cruz” — match nothing and are left alone; anything multi-word it can’t confirm is reported for a human rather than guessed at, because a wrong guess here renames somebody.

  Two refusals are built in: it never edits a CrmDataChange that is already exported or verified (Advancement Services holds that value; ours must not silently diverge — those are listed instead), and when the corrected maiden name is what the Alumni record already has, the row is skipped with a reason rather than exported as a change it no longer is.

  Cp::Champion#college_last_name — the portal’s equivalent field — is out of scope; that surface is on hold.

• Flaky test: “an instant profile-link submit is still treated as spam.” A real race, not CI noise. SignupHoneypot compares integer-truncated epoch seconds and SHORT_FORM_MIN_SECONDS is 1, so “instant” (0) and “one second later” (1) are adjacent integers with zero slack — a 2ms gap that happens to straddle a second boundary makes the difference 1, 1 < 1 false, and the submission is not spam. Now wrapped in freeze_time. The 6-field form’s equivalent test survives only because MIN_SECONDS is 3; lowering that constant would make it just as fragile.

Changed

• CRM export: one row per constituent per target record. Csv::CrmDataChangeExporter is no longer one row per CrmDataChange. Every field now has a named column, and everything that updates the alumni record — name (first_name/pref_name/maiden_name/last_name), contact (all five email columns + phone) and address (street/city/state/zip) — arrives on one line. An alum who changed their name, email and address is one record to open and one edit to make, not six rows to reassemble. A new Change Type column lists what the row holds (Name, Contact, Address).

  Employment stays on its own row, and only for a real reason: alumni.employments is one-to-many, so an employer change targets a different record than a city change, and an alum with two pending positions would collide on a single Employer Name column. Rows group by BUID + source_table, which is exactly that distinction.

  Only fields that actually changed are filled in — a blank Zip means the zip was not reported, not that it is empty. No column carries a value inferred from the alumni record. The old per-field Old Value is replaced by one Previous Values column spelling out each field’s old → new, so a grouped row is still auditable at its original grain. A field occupies one slot per row: a city corrected twice before anyone exported gets a second row rather than losing a change. An ad-hoc field (log_manual_change accepts any name) keeps its own row and the generic Field Name / New Value pair. Headers, column order and the Change Type labels are all derived from FIELD_GROUPS, so a field cannot get a column without a header.

  The staff page at /settings/bruinquest/crm_changes is deliberately unchanged — it is a work queue, not a mapping file.

• Student groups pulled out of the CRM pipeline. How an alum-reported group becomes a validated affinity code is still undecided, so ChampionSignupCrmLogger no longer writes affinity_code / affinity_other rows, and affinities is listed in the new CrmDataChange::EXPORT_HELD_SOURCE_TABLES. The rows 22.4 already wrote stay on file but are hidden from the staff page, the CSV, and “Mark All Exported” — a row nobody exported must not be marked exported.

  Nothing is lost: champion_signups.affinity_codes and affinity_other still hold what alumni reported, which is what a re-enable would diff. Turning them back on is emptying that array plus restoring the logger’s affinity branch.

  Both the page and the CSV now scope to CrmDataChange.exportable (app_originated minus held tables) rather than app_originated, in the same one place, so a held row cannot reach Advancement Services through one door and not the other.

• CI: a docs-only skip can no longer launder a red build into staging. Staging deploys on the CI workflow’s conclusion == 'success', and a docs/CHANGELOG-only push skips the suite and reports success in ~18s. On August 4 2026 CI #522 failed on 8f77fb9, the v1.0.83 CHANGELOG commit went green in 18s, and Deploy to Staging #432 shipped the untested tree. check-changes now reads the preceding commit’s CI conclusion and drops the skip unless it was success, running the full suite when the verdict is failure or unknown.

  Production was never exposed: deploy-production.yml runs its own full suite on the tagged commit with deploy: needs: test. Documented in docs/operations/DEPLOYMENT_PIPELINE.md.

• Removed a dead entry from CI’s docs-only allowlist: app/controllers/champions/roadmap_controller.rb moved to root level in Phase 23.3, so the pattern had matched nothing since. Not re-added under its new path — root-level app code runs the full suite.

[1.0.83] - 2026-08-04

Post-deployment: nothing to run. No migration, no schema change, no rake task.

Follow-up to v1.0.82, covering the one Engagement Stats code path that release missed because it lives in the controller rather than a service.

Fixed

• Matrix quadrant drill-down timed out with a college filter. Clicking “Committed” on the Matrix tab spun and died silently; without the filter it loaded fine on 5x the data (dev, Last FY: 589 rows / 7.52s filtered vs 2,832 rows / 1.00s unfiltered).

  EngagementStatsController kept its own copies of #build_filtered_engagement_scope, #engaged_alumni_count and friends, which v1.0.82 did not touch because #quadrant_alumni never goes through a service. The nested Education::AggregateScope subquery landed inside an aggregate that already carries four correlated subqueries per row (the activity caps), so the planner re-evaluated the expensive scope per row. BUIDs are now resolved once, as in EngagementStats::BaseService: 7.49s → 1.35s, identical result set.

  A query-count assertion cannot catch this — nesting keeps it one statement — so test/controllers/quadrant_alumni_efficiency_test.rb asserts structurally that no statement contains both the UNION ALL and the correlated cap alias.

• Noted, not fixed: #quadrant_alumni is outside TimeoutProtection (only: [:index]), so it runs to Heroku’s 30s H12 and the modal silently swallows the 503. See BACKLOG §5.0-A.

[1.0.82] - 2026-08-04

Post-deployment: nothing to run. No migration, no schema change, no rake task. This release is service/view code, one new shared class, tests and docs.

No measurement definition changed. Every figure on every Engagement Stats tab should read exactly as it did on v1.0.81. All 36 tab × filter combinations were diffed against v1.0.81 on a copy of real data; every value matched. The only intentional differences are tie ordering in the Breakdown description lists and in top_alumni (both previously undefined, now deterministic).

Known caveat: staging QA was not re-run after the final Demographics fix. Verification for that fix is local only — full suite plus a targeted check against dev data. If anything looks wrong on the Engagement Stats tabs, start there.

Fixed

• Engagement Stats: Analytics and Breakdown tabs timed out (“This report is taking too long to load. Please filter by college or year…”). Reproduced on local dev data for Last FY: Breakdown 17.1s / 28 queries, Analytics 42.1s / 164 queries, against TimeoutProtection’s 15s budget.

  Both services looped over a population and re-ran the expensive filtered-alumni subquery — the Education::AggregateScope UNION ALL over 70K educations + 52K degrees, with a NOT IN, ~550ms per execution — inside every iteration. Breakdown ran it once per engagement type (2 queries × 13 roled types); Analytics ran find_in_batches(1000) across all 51K alumni in the population to score the 2,832 who actually had activity in range.

  EngagementStats::BaseService#eligible_buids now resolves that filter once per service call, narrowing by the indexed activity table first (~2.9K BUIDs for a fiscal year) before touching the aggregate scope. Breakdown collapsed to 2 grouped aggregates; Analytics is now set-based over the in-range engagement rows, hydrating Alumni records only for the top 50 scorers.

  Measured after (same data, cold cache): Breakdown 1.13s / 6 queries, Analytics 0.94s / 8 queries. Every output value verified identical against independently recomputed figures.

Fixed (third pass — Demographics 500, August 4 2026)

• Demographics tab raised ActionView::Template::Error (comparison of Array with Array failed). Latent since Phase 18.6 (May 2026), not introduced here — the tab had been timing out before it ever reached the table that crashes. Making it fast enough to render surfaced it.

  DemographicsService used .compact on a grouped count intending to drop the no-college bucket, but Hash#compact removes entries with nil VALUES, not nil KEYS — and a grouped count never has nil values, so it was always a no-op. The surviving nil key then made @engaged_by_college.sort compare [nil, 5] against ["CB", 3] and raise. Now .except(nil), with the view hardened to sort_by { |code, _| code.to_s } so a nil key can never 500 the page again.

  The nil bucket is real data: AggregateScope emits no college_code for most Degree-fallback rows (563 of 604 alumni on dev). Those alumni are still dropped from the college table, matching the original intent — see BACKLOG §5.0-A item 3.

  New test/controllers/engagement_stats_tabs_render_test.rb seeds realistic data (including a college-less credential) and renders all seven tabs, with and without college/year filters. The previous controller test only ever rendered Overview, on fixtures with no engagement activity — a green assert_response :success against an empty page.

Fixed (second pass — found in staging QA, August 4 2026)

• Regression introduced by the first pass, caught before release. Collapsing every tab onto BaseService#eligible_buids silently changed Overview’s and Analytics’ numbers whenever college AND graduation year were filtered together (dev data, college=CE + year=2015: engaged 46 → 42, Level 2+ 23 → 22).

  Cause: the tabs never shared one definition of who counts. Overview and Analytics read filtered_alumni.pluck(:buid), which applies college and year independently — any credential from that college, any credential from that year, not necessarily the same one. Breakdown, Matrix and Demographics went through build_filtered_engagement_scope, which additionally requires one credential satisfying both. Unifying them onto the strict form looked like a refactor and was actually a measurement change.

  Both definitions are now explicit — #population_engaged_buids (loose) and #eligible_buids (strict) — and each tab keeps the one it has always used. test/services/engagement_stats/population_semantics_test.rb pins the split. Deciding which definition is correct is deferred to BACKLOG §5.0-A; it is a product question, not a code cleanup.

• Filtered tabs still timed out on staging after the first pass, which had only ever been measured with no college/year filter. With a college filter, filtered_alumni nests up to three unrestricted Education::AggregateScope subqueries in a single statement, each materializing ~123K credential rows. Population, college and year are now resolved as separate bounded queries, and AggregateScope.buid_subquery accepts a buids: restriction so Postgres can push the qualifier into both UNION ALL branches and use the BUID indexes.

• TimeoutProtection cannot interrupt a running query. Staging logs show Completed 302 Found in 15005ms (ActiveRecord: 14999.2ms) followed by a Heroku H12 ... service=30000ms status=503 on the same request id. Timeout.timeout raises via Thread#raise, which cannot preempt a thread blocked inside libpq, so the 15s guard only fires once the query returns — the user sees Heroku’s 30s 503 (“Something Went Wrong”), not the intended flash message. Logged in BACKLOG §5.0-A; a database-level statement_timeout is the real mechanism.

Changed

• Engagement Stats Overview tab carried the same anti-pattern (a 51K-element BUID array re-sent as an IN list across nine queries) and now shares the same base scope: 5.00s → 1.54s. It was under the timeout locally but is the default tab and the closest to tripping on Heroku. Outputs verified unchanged.
• EngagementStats::OverviewService#calculate_flagship_metrics no longer takes a valid_buids argument it never used.

• Fiscal year is now defined in exactly one place: FiscalYear (app/models/fiscal_year.rb, shared layer). The June-1 boundary was previously written out eight independent times — FiscalYearHelpers, Education::AggregateScope, EngagementStats::BaseService, EngagementStats::OverviewService, Degree (×2), EngagementStatsController, and two inline copies in the Engagement Stats views. They agreed, but nothing enforced it. Changing FiscalYear::START_MONTH now moves the boundary everywhere.

  The collapse preserved two interval shapes that were not interchangeable: FiscalYear.range is inclusive of May 31 (Degree.by_fiscal_year, current_fy_range), while FiscalYear.half_open_range returns an exclusive June-1 end for Education::AggregateScope, which pairs it with >= ? AND < ?. Collapsing them into one shape would have shifted every FY-filtered figure by a day at one edge, silently. test/models/fiscal_year_test.rb pins both, plus agreement between the Ruby and SQL implementations at all five boundary dates. No stat value changed — verified against the same recomputation used above.

[1.0.81] - 2026-07-31

Post-deployment: nothing to run. No migration, no rake task, no schema change — the whole of Phase 23 is code, routes and docs.

One caveat that only matters if you roll back. This release adds permanent 301 redirects from /champions/* to /alumni_network/*, and browsers cache a 301 indefinitely. Once a staff member has followed one, their browser stops asking the server — so reverting the deploy leaves them on a path that no longer exists, and re-deploying the old code does not fix it. Recovery is a hard reload, per browser. Prefer fixing forward over reverting. On staging, 40 of 46 persisted StaffNotification rows (87%) pointed at the old paths, which is what the redirects are there for.

Added

• A shared layer, so the walls between the five apps have doors (Phase 23.3) — 23.1 and 23.2 built walls on a premise that is false for the core domain objects: that every file belongs to exactly one app. Alumni, Affinity, District, Industry and the rest are shared by all five, and an app is a view onto them rather than an owner of them. Two costs of the omission were sitting in the tree, not argued in the abstract. The champion interest seals lived in the frozen champions/ directory while being rendered by three other apps — so editing a deliberate cross-app design choice was a held-surface write. And industry, a string on three tables across two apps, was validated in the app that merely displays it and not in the app that collects it from a dropdown, so an altered form POST stored a value no report, filter, or community-matching rule would recognise.

  Shared artwork now lives in app/views/shared/champion_interest/, each partial carrying a header naming every surface that renders it. Affinity owns both of the category lists that were scattered across two apps, Industry owns the taxonomy, and ChampionSignup validates against it. CLAUDE.md gains the placement rule and — because it looks like a bug otherwise — the note that global helper inclusion is intentional, since it is how a calculation written for one app benefits the rest.

• IdentityField: one vocabulary for the three tables that describe the same person (Phase 23.3) — alumni, cp_champions, and champion_signups used different names for the same field, and nothing translated between them. That had already produced a silent defect: Cp::ProfileChange::HIGH_PRIORITY_FIELDS — the list telling Advancement Services which changes matter most — declared pref_name and maiden_name, while the callback feeding it wrote pref_first_name and college_last_name. The constant and the callback live in the same file and disagreed about what a preferred name is called. for_field("pref_name") returned zero rows and always would; nothing raised, and the fields most valuable for CRM reconciliation were the ones dropped.

  IdentityField::MAP is a declarative map plus a lookup — explicitly not a translation engine and not a rewrite of either change log. Cp::ProfileChange now translates at query time, so for_field("pref_name") returns 6 rows and for_field("maiden_name") 16 where both were structurally 0. A test asserts every field name either log can write is one the vocabulary knows, which makes the defect class unrepresentable rather than fixed once. The three fields with no counterpart anywhere are recorded as nil rather than papered over, and the conditional legal_first_name mapping is documented rather than encoded, because a flat hash cannot express it and should not pretend to.

  This does not solve identity. It gives three tables one vocabulary; deciding which is true when they disagree is Phase 26.

• Cross-surface rendering is now enforced (Phase 23.3) — A view may render its own surface’s partials or anything under shared/; reaching into another surface’s directory fails the build. Baseline is empty, because the violations were removed rather than allowlisted. This is the only genuinely enforceable half of the shared-layer rule — a render target is a static string, a helper call is not — and the spec says so plainly instead of adding a test that implies otherwise.

• Surface boundaries are now enforced by the test suite, not just documented (Phase 23.1) — This repo is five apps in one codebase, and two of them are on hold. CLAUDE.md described the boundary between /champions/ (frozen Alumni Network Admin) and /champion_signups/ (the live Signup Admin) in a table, in bold, and as a numbered rule — and it was crossed often enough that a hard gate had to be added. The reason is mechanical rather than a matter of care: deciding where a file belongs usually means reasoning over grep output, and grep -rn "champion" returned both directories with nothing indicating which was frozen. test/architecture_test.rb now fails bin/test when a file lands in a held tree, when a new cross-surface Cp:: reference appears, or when a controller declares a layout belonging to a surface it does not live in.

  It is a ratchet, not a clean assertion. The tree does not pass a strict version of these rules, so every existing violation is committed as a dated baseline that may shrink and never grow — a test that fails on arrival gets disabled within a week and buys nothing. Capturing that baseline turned up two things planning had missed. EngagementStats::RetentionService and EngagementStats::DiscussionBoardsService are wholesale Cp:: analytics sitting inside engagement_stats/, which CLAUDE.md rules against by name — retention_service’s own header comment says it queries Cp:: tables rather than Alumni. And excluding comments from the reference count cut the apparent coupling inventory from 34 files to 17: half of what a raw grep reports as coupling is documentation about coupling, which is worth knowing before anyone estimates a monolith split off a grep count.

• A shared Industry taxonomy (Phase 23.1) — The alum-facing signup flow read its industry list from Cp::Champion::INDUSTRIES, on the frozen belmontalum.com member model. Phase 23.4 renames that class, so the live signup flow would have gone down as a side effect of refactoring a surface nobody is using. The list now lives in the shared, identity-agnostic layer. Cp::Champion keeps its own copy for now — pointing it at the shared constant is a write to a held path — so a test asserts the two lists stay identical rather than leaving it to vigilance.

Changed

• The Alumni Network Admin is no longer called champions (Phase 23.4) — app/controllers/champions/ → app/controllers/alumni_network/, /champions/* → /alumni_network/*, and Champions:: → AlumniNetwork::. This is the collision the hold gate exists for: /champions/ and /champion_signups/ sat one character apart and administered different products, and grep -rn "champion" returned both with nothing marking one as frozen. Both halves of that pair are now gone — 23.2 renamed the signup side, 23.4 the portal side. 185 files, 1,401 route-helper references, no migration.

  The rename was generated from bin/rails routes rather than grepped, because four helper families contain champion and are not this namespace — the cp_champion_* Devise scope, the public cp_champions_landing, alumnichampions_root, and 23.2’s champion_signups alias — and one helper’s own action is named autocomplete_champions. A regex would have mangled all five.

  Three items were pulled forward from the cut 23.5 because they had no later home: resources :champions became resources :members (/alumni_network/members, backed by an unrenamed Cp::Champion — the URL is what staff and agents reason over), both layouts named “champion” were renamed, and Cp::Champion::INDUSTRIES was deleted in favour of the shared Industry::ALL. 34 “Champion Program” labels became “Alumni Network.”

• Phase 23.5 was cut — the Cp:: → An:: module rename and Cp::Champion → Member model rename, 389 files and 56 tables, will not happen. The phase’s own value-vs-churn ranking had already answered “prevents misroutes? No”: Cp:: is a fossil of “Champion Portal,” but an unambiguous one — nothing else in the repo looks like it, so nothing has ever been misfiled into it. Against that sat the largest file count in the phase, its only migration, its only irreversible step, and the one change that fails silently rather than loudly (a missed polymorphic type string makes associations return nothing instead of erroring). Cp:: is now documented as permanent, not transitional.

• The development roadmap moved out of the frozen Alumni Network and onto the lookup (Phase 23.3) — app/controllers/champions/roadmap_controller.rb → app/controllers/roadmap_controller.rb, and /roadmap is now served on alumnilookup rather than belmontalum. It is an HTML rendering of the phase docs describing all five apps: repo development tooling that happened to sit inside a frozen product, which was the only reason CLAUDE.md needed a hand-carved exception letting /phase-wrap write to a held path. That exception is now deleted rather than ported — the point of the move. Non-production only, so no production bookmark is affected; the guard also became host-agnostic, an allowlist of non-production environments rather than a blocklist of one host.

• docs/planning/champion-portal/ split, because the name said something false (Phase 23.3) — It had come to hold the development record for the whole repo (25 phases across five apps, the backlog, QA guides) alongside genuinely Alumni Network product docs. phases/, BACKLOG.md, qa/, and development/ moved up to docs/planning/; source/, ai/, features/, and the network’s own overviews moved to docs/planning/alumni-network/. ~230 textual path references and 88 markdown links were rewritten by resolving each link to an absolute repo path before the move and recomputing it after, rather than by hand. Repo-wide broken links went 88 → 85.

• The signup ecosystem is split by audience instead of auth state (Phase 23.2) — The alum-facing signup lived under public/, a name describing authentication, which was the wrong axis: the returning-visitor profile hub is session-gated and lives there too. Meanwhile the staff tooling sat at /champion_signups/, one character from /champions/, administering an entirely different product. Both now name their audience: Signup:: / layout "signup" for alumni, SignupAdmin:: / layout "signup_admin" for staff. ChampionSignup and its table are not renamed — “Champion Signup” is the product’s own name for the flow and is correct.

  No alum-facing URL changed. /sign-up, /sign-up/:id, /profile/:code, /opportunities/:slug and /privacy all still resolve; only module and helper names moved. The mail-merge outreach to v1 signups uses permanent /profile/:code links that are already in alumni inboxes.

  Staff URLs did change, and that turned out to be the risk. StaffNotification#url writes a route path into the database — four notification jobs do it — so every row created before this change points at /champion_signups/.... The rename on its own would have 404’d the entire existing staff notification inbox on click. Eight 301 redirects cover them, ordered specific-first so champion_signups/:id cannot swallow champion_signups/opportunities as id="opportunities", with an end-to-end test that follows a redirect and asserts staff reach the real page. These redirects are permanent, not transitional; the rows are already written. Their route helpers are named legacy_* on purpose — left unnamed, Rails derives helper names from the path and quietly recreates the very names the rename removed, except now they 301 instead of erroring, and nothing would ever flag their use.

Fixed

• The Alumni Network Admin sidebar highlighted nothing, on every page (Phase 23.4) — Caught before shipping, and the more useful half of the sub-phase. The sidebar decides which nav item is active by comparing request.path against 25 hard-coded path literals, not route helpers. Driving the rename off the route table — the right way to do it, since it cannot be fooled by lookalike helpers — rewrote all 1,401 helper calls and left every literal pointing at /champions/....

  The result was a fully working admin surface with an invisible defect: identical rendering apart from one CSS class, no test touching it. The same failure was in ActionItemsService’s six navbar-bell links, two of which carry query strings — and dropping ?needs_leader=true is worse than a 404, because staff land on an unfiltered list that looks like a working page while answering a different question. A rename driven off the route table only fixes what the route table knows about.

• Persisted staff notification URLs would have 404’d — again (Phase 23.4) — 23.2 found that StaffNotification#url writes a route path into the database; 23.4 found the same hazard on a surface with higher volume, since Cp::NotifyAdminsJob persists one on every member signup. Mitigated with a permanent wildcard 301 rather than 23.2’s enumerated list: two more controllers and two mailers also emit /champions/... URLs, one of them into alumni inboxes, and an enumeration missed all four. The query string is preserved, every redirect is explicitly named legacy_* so Rails cannot silently resurrect the helper names the rename removed, and a test asserts those names no longer resolve.

• ChampionSignup accepted any string as an industry (Phase 23.3) — The column had been unvalidated since Phase 19 while Cp::Champion enforced the same list. Existing rows were audited first and none held an off-list value, but three tests did: they stored "Education", "Music", and "Entertainment" — titleized display labels the form’s <select> can never submit, since it submits the underscored key and humanizes only what the alum reads. The divergence the shared layer exists to prevent, found in the test suite rather than the data.

[1.0.80] - 2026-07-29

Post-deployment: adds an index on champion_signups (buid, created_at). Run heroku run rails db:migrate on the target app — there is no release phase in the Procfile, and district search will table-scan champion_signups once per alumni row until it exists.

Added

• Everything the v2 signup collects now reaches the people who use it (Phase 25) — The signup flow has been gathering location, interest leaning, student groups and return-visit activity since Phase 19, and none of it was visible in the Lookup Portal. Staff opened a profile and saw a v1-shaped “Alumni Champion Status” card describing a five-step wizard that no longer exists; they searched a district and got CRM addresses only, missing every alum who had told us they moved; they exported a CSV with one champion column and no idea what the alum had actually said. A new Alumni::SignupProfile (same shape as Alumni::EducationProfile) is now the single read layer for all of it, and the profile, the search results, the filters and the export all go through it.

  Location resolves at read time and never overwrites the CRM. A signup value is pending truth, not competing truth — ChampionSignupCrmLogger writes it to crm_data_changes, Advancement Services keys it into Affinaquest, and it flows back into alumni on the next sync. So the newest active signup’s ZIP now outranks alumni.zip for both display and district search, while alumni.zip is left exactly as it was. This changes who a district search returns: an alum who told us in March that they moved to Nashville used to keep surfacing in a Memphis search for as long as the CRM round trip took, and never in Nashville — which is the search someone actually ran. Divergence is shown with a “self-reported” badge and the CRM address underneath it; once the two ZIPs converge the badge disappears, because a closed loop flagged as an open one is just noise.

  Champion Role is replaced by interest leaning. v2 dropped “pick the role you are” in favor of a four-area spectrum, so the portal crowning someone a “Connection Advisor” described a flow that no longer exists. The profile now shows the full four-bar spectrum (the same partial the public quiz reveal and Signup Admin render) and the badge reads “Leans Bringing People Together”. The seal artwork is reused as-is — the area keys and the old role keys are the same four strings. An alum with no scorable quiz and no explicitly chosen role gets no leaning rather than a fabricated one, which also meant fixing an all-zero spectrum that max_by was silently resolving to whichever key came first. List views (search results, the CSV) read stored interest_scores only; recomputing a v1 quiz through ChampionQuizService fifty times a page — or 49,000 times an export — is not a trade worth making for a decorative chip.

  Student groups are shown as two sources, because they will never be one. ChampionSignupCrmLogger only ever read alumni_affinities to diff against; nothing writes signup-reported groups into it, and nothing should — they reach the CRM through the export and come back on a sync. Affinity search now matches either source, and every chip carries its provenance in its fill — tinted for BruinQuest-confirmed, plain white for self-reported-and-not-keyed-in-yet — with the free-text “other” group shown on the profile. Showing them identically would present a self-report as CRM fact.

  The CSV gains a signup_* block — city, state, ZIP, district, location_source, top_interest_area plus all four area percentages, and self-reported affinities. The existing district and affinities columns keep their current CRM-only meaning, so sheets built against this export do not silently change what they are reporting.

Changed

• The “Alumni Champion Filter” is now one question with three answers (Phase 25.5) — It offered six options modeled on v1’s five-step wizard. Four of them could no longer match anything new: v2’s first step requires a ZIP, and ChampionSignup#calculate_status returns 5 (“Completed”) the moment a ZIP is present, so every v2 signup is complete on creation and “Show Signups In Progress” can only ever surface a v1 straggler. The dropdown is now All / Completed the Champion form / Has NOT completed the form, and the manual prospect_status flag — a staff judgment about someone who hasn’t filled the form out, not a competing degree of completion — moved to its own “Manually flagged prospect” checkbox. Retired param values map forward through Alumni::ALUMNI_FILTER_ALIASES so bookmarked URLs keep working and label themselves with what they now do; champions_and_prospects resolves to “all”, since the distinction it drew no longer exists. “Has Alumni Network Account” is untouched and stays separate — that filter is the belmontalum.com portal and must not bleed into signup completion.

Changed

• The CRM is called BruinQuest, everywhere staff can see it — the vendor name “Affinaquest” and its parent “Salesforce” have been removed from every page, page title, form label, tooltip and CRM-source badge, and the settings URL moved from /settings/affinaquest to /settings/bruinquest (the old path 301s, so saved links and anything Advancement Services bookmarked keep working). The Ruby side — Settings::AffinaquestController, AffinaquestImportBatch, the affinaquest_import_* tables, the affinaquest_updated_at / affinaquest_synced_at columns, and the affinaquest_import change-source value — deliberately keeps the old spelling: renaming those is a migration with real risk and zero visible benefit, and a half-renamed identifier is worse than a consistent one. A controller test asserts the import page never renders the string.
• The alumni search filters are grouped by what they are about — five checkboxes and a dropdown in one flat row became three labeled groups: Alumni Champions (alumnichampions.com), Alumni Network (belmontalum.com), and Alumni Record. The grouping is load-bearing rather than decorative — a flat row invites reading the two surfaces as two flavors of the same thing, which is exactly the confusion this codebase keeps having to unwind. Alumni Champions is two checkboxes, “Completed Form” and “Manually flagged prospect”. “Has not completed the form” is deliberately not offered: filter_by_alumni_status still understands no_form so legacy bookmarks resolve, but who we haven’t reached is a question for a later phase, and a checkbox that returns every alum Belmont has is not one staff should trip over on the way to something else. A view test asserts the option is absent.
• alumni#show uses the role icon, never the full seal — a seal is a circular badge with the role name baked into the artwork, so nesting one in a bordered card double-frames it and repeats a label the markup already renders. The public landing page and the spectrum bars had always used the icon; the profile now matches.
• The two affinity lists on alumni#show are one list — BruinQuest-confirmed groups and signup-reported ones were rendered as two separate sections with different visual treatments, which made a self-report look like a lesser kind of fact rather than a differently-sourced one. Now a single list, equal weight, each entry carrying 2003 - 2004 • Webmaster where the detail exists and a Source: BruinQuest / Source: Champion Signup line underneath. A BruinQuest row shows more because BruinQuest holds more, not because it outranks the alum. The free-text “other” group is now an entry in that list instead of a footnote, and only BruinQuest rows show edit/delete — a signup-reported group has no record behind it to edit. Search-result chips, which have no room for a source line, carry the distinction in the fill instead: same solid border on every chip, tinted background for BruinQuest, white for self-reported. Dashed borders did that job first and read as broken rather than provisional — especially six across in one table cell.

Fixed

• The alumni search affinity dropdown submitted values that could never match — The server-rendered <option>s carried Affinity#id while filter_by_affinities matches on affinity_code, so submitting without first changing the category filtered on a number against a column holding codes like BAMB and returned nothing. It went unnoticed because the affinity-selector Stimulus controller replaces the whole option list with real codes as soon as a category is picked, which is the normal path through the form.
• The “completed champion” card in engagement breakdowns had never been styled — It built its class names by interpolating a role color (bg-#{color}/10, text-<%= color %>), which Tailwind’s JIT cannot see and therefore never compiled, so the card rendered with no color at all. Rebuilt on a literal class map, alongside the same fix in the profile header badge.
• Alumni#reload now clears the memoized signup profile — reload drops association caches but not plain instance variables, so current_champion_signup and signup_profile would survive it and keep answering with pre-reload data, in exactly the situation where a caller reloads because something changed.

[1.0.79] - 2026-07-28

Added

• champion_signups:backfill_crm_changes rake task — the Phase 22.3-22.5 CRM feedback loop (ChampionSignupCrmLogger) only ever ran live, from a controller after_action, so signups completed or updated before that shipped never produced CrmDataChange rows. The logger diffs a signup’s current columns against the linked Alumni’s current columns rather than a point-in-time snapshot, so no historical data is needed to backfill — this task simply calls the same logger once per already-linked signup. Idempotent (already_logged? guards re-runs); ships with a dry_run mode that runs the real logic inside a transaction and rolls it back so nothing is persisted during preview.

  bin/rails champion_signups:backfill_crm_changes[dry_run]
  bin/rails champion_signups:backfill_crm_changes
  

[1.0.78] - 2026-07-28

Fixed

• CI crash in OpportunityMarkdownTest traced to a memoized Redcarpet renderer — OpportunityMarkdown#renderer cached a single Redcarpet::Markdown instance for the life of the process (@renderer ||= ...). Redcarpet wraps a stateful C parser: if a call into a shared instance is ever interrupted mid-render — every test is wrapped in Timeout.timeout, which fires via async Thread#raise — the parser’s internal buffers are left dirty and every later call on that instance is corrupted for the rest of the process. That surfaced in CI as two unrelated-looking failures on two different tests in the same file: markdown.c:2927: sd_markdown_render: Assertion followed by TypeError: wrong argument type String (expected Redcarpet/rndr). It read like a CI infra fluke — not locally reproducible, two different-looking crashes — but was a real defect: local runs are fast enough that the timeout rarely fires mid-render, so the corruption path almost never triggers there. Fixed by building a fresh Redcarpet::Markdown instance per call instead of memoizing one; a fresh instance has no state left over from a previous, possibly-interrupted call to corrupt. Cp::WelcomeContentGenerator, the only other Redcarpet caller in the codebase, already built a fresh instance per call and was unaffected.

[1.0.77] - 2026-07-28

Post-deployment: this release adds crm_data_changes.champion_signup_id. Run heroku run rails db:migrate on the target app — there is no release phase in the Procfile, so an unmigrated deploy will 500 on the CRM changes page.

Added

• Staff notifications are finally readable — a real inbox at /notifications (Phase 22.1) — StaffNotification has been a complete, correct model since Phase 1: six jobs write to it, it has read_at, clicked_at, mark_read!, an unread scope and a seven-entry type list. It had no controller, no route, and no view. Every row was written to the database and surfaced only as a transient web push — miss the push and the notification was gone forever. There is now a full-page inbox: filter by surface, by type, and by read state, paginated, with the receive → clear → gone flow the model was always built for. It is per-user, and enforced at the lookup, not the view — every action scopes to current_user.staff_notifications, so a colleague clearing theirs can’t hide an item from you and can’t be probed for one either. Clicking a notification is the read: it stamps read_at and clicked_at (a column that existed and was never once written) and forwards you to whatever the notification points at, while “Mark all read” deliberately sets only read_at — that distinction is what makes clicked_at mean “I went and looked” rather than “I dismissed a batch”. Surface grouping is data-driven, not a view conditional: a new StaffNotification::SURFACES map is the single place a notification type declares whether it belongs to Champion Signup or Alumni Network, and a model test fails the build if a type is ever added without one. Because the list paginates, ordering is surface-major with recency inside — sorting by recency alone would repeat both headings on every page. The inbox lives at the unnamespaced /notifications on the shared application layout rather than under /champion_signups/ as the phase spec first called for: the feed spans both surfaces and the bell that opens it renders in layouts/_navbar, which all five Lookup Portal layouts include, so filing it under the signup namespace would have put Alumni Network notifications at a signup URL. (/notifications is free on the Lookup Portal — the Cp:: one of the same name sits inside the belmontalum.com host constraint and never matches on *.alumnilookup.com.)

• What alumni tell us through the signup now reaches Advancement Services (Phase 22.3–22.5) — CrmDataChange has been a mature pipeline since Phase 1 — a pending → exported → verified lifecycle, export batches, field protection against Affinaquest overwrites, and a working staff export at /settings/affinaquest/crm_changes. Not one signup had ever written to it. Its only alum-facing caller was the belmontalum.com portal, so an alum could update their address, their employer and their student groups through alumnichampions.com and it would land in champion_signups and die there. A new ChampionSignupCrmLogger closes the loop: it runs on every public save point and on staff linking, resolves the alumni record by BUID, and logs only what’s genuinely new under a champion_signup source kept deliberately distinct from champion_portal — Advancement Services needs to know which product the alum used. Contact fields diff against the alumni record, with the mapping spelled out rather than assumed (zip_code → the zip column) and an email checked against all five of alumni’s email columns, so an address already on file as email_business isn’t reported as a change. street is the one field with nowhere to diff against — alumni has no street column — so it logs as a plain “they report this” with a blank old value rather than being dropped. Employment matches against every one of an alum’s employment rows, not just the most recent. Alumni genuinely hold more than one current position (that’s why Phase 24 made the table one-to-many), so checking only the latest would flag someone’s second job as a brand-new employer every single time they saved. A new employer diffs against the most recent position; an alum with nothing on file logs a blank old value. A match doesn’t end it — a promotion inside the same company is reported too. The first real test of the feature was someone changing their job title at an employer we already had, and the original rule (“any employer match suppresses”) dropped it silently; the title now diffs against the position that matched, so an alum promoted at their older employer isn’t compared against their newer job’s title. Identical title, or none given, still logs nothing. Industry rides along as a note, since there’s no column to diff it against. Student groups log additions only — a group missing from a form is silence, not someone announcing they left an organization — and free-text “other” groups log under their own field with a note that they need staff review, never as a code that would fail against the affinities table. Nothing an unlinked signup reports is lost. A change with no constituent to attach to is unusable, so unlinked signups log nothing and instead surface in Signup Admin as “needs identity match” — narrower than the existing “not linked” filter, meaning unlinked and actually holding data the export is waiting on — with a dashboard callout, a list filter, row badges, and a note on the detail page saying exactly which fields are being held. Linking an alumni record runs the logger retroactively and tells you how many changes it just queued. Two things were fixed on the way through that would have made the whole feature silently useless: the app_originated scope that both the staff page and the CSV are built on was a hardcoded source list (a new source added to the model but not to that list writes perfect rows and ships none of them — it’s now derived from the sources, with a test), and the protecting-source list was inlined in two places that could drift, so a signup value would have blocked an import overwrite on one code path and not the other. The export itself was extracted out of the controller into Csv::CrmDataChangeExporter — it had been building CSV inline with an Alumni.find_by per row — and gained two columns: Champion Signup ID for traceability, and Source Table, which became load-bearing the moment employer_name and affinity_code joined alumni, since several rows can now share a BUID and a field name and only the table says what to update.

Fixed

• Entering a new ZIP left the old city on the profile — “We have you in Brentwood, TN” against a Madison ZIP — Reported by a signup who updated their ZIP to a Wisconsin one and watched the hub keep showing their old Tennessee city. The district callback populated city/state/district from the ZIP but deliberately never overwrote the city/state a v1 signup had typed in — correct for not clobbering a real address with a ZIP’s canonical city, and wrong for the case that matters most, since an alum entering a new ZIP has moved and everything else on file describes where they used to live. A ZIP that replaces a different ZIP now clears the stored city, state and street; a ZIP arriving where there was none is initial entry and clears nothing, so the street address given in the same submission isn’t deleted as fast as it’s collected. The values are cleared rather than recomputed, because display already resolves the canonical city from the ZIP when they’re blank — that’s what makes the new location show through, and it keeps city meaning “what the alum typed”. This also mattered for the CRM loop above: it would otherwise have reported the stale city to Advancement Services as though the alum had asserted it. Cp::Champion and OpportunityResponse derive location the same way and already overwrote unconditionally, so neither was affected — ChampionSignup was the outlier precisely because of the hand-written exception.

Changed

• The navbar bell is now one dropdown with two honest halves (Phase 22.2) — The bell rendered ActionItemsService only: live aggregate counts, explicitly documented as “not persisted”, of which six of eight items linked into the held /champions/ surface. The one active-surface signup item was a 7-day rolling count of new signups — the “bucket of 2 new updates” that clicking through changed nothing about, and that only disappeared when the signups aged out. Nothing at all represented opportunity responses, returning-visitor updates, or consent changes. The dropdown now has a New section (your unread notifications, clearable — per-item click marks read, “Mark all read” clears the lot) above a visually distinct Pending work section (the standing queues, relabeled to read as counts that resolve themselves as the work gets done). The badge counts unread notifications only. It previously showed priority_count, a sum of support requests, champion verifications and moderation queues — every one of them on the held surface, none of them clearable from the bell. The number staff see is now the number they can actually act on; pending work carries its own muted count beside its heading. priority_count and its discussions_needing_moderation_count helper were removed outright, since the badge was their only caller. Alumni Network action items collapse under a single de-emphasized heading while that surface is on hold, driven by a new surface attribute on ActionItem with a test asserting that the held-surface grouping and the /champions/ paths can never drift apart. The footer link, which pointed at champions_root_path, now goes to the notification inbox — the label rename is Phase 23’s job, not this one’s.

[1.0.76] - 2026-07-28

Changed

• Alumni search result rows: employer/title redesigned, Phase 24 wrap — The Phase 24.5 result row shipped in 1.0.75 as a briefcase icon plus one combined “Employer — Title” line under the district, inside a cell forced to nowrap. In practice the icon read as oversized next to everything else in the row, and a long combined string couldn’t wrap — nowrap forces the column’s minimum width to its full one-line width — so it dragged the Name column wider and squeezed Degree and Affinities into a sliver on the right. Redesigned LinkedIn-style: job title and employer are now two separate lines directly under the name (icon dropped), each allowed to wrap instead of forcing column width, with district and BUID/BQID swapped below them. Two more row-level fixes landed alongside it: the avatar now top-aligns with the name block instead of centering against it, and the engagement scorebar — previously a sibling of the avatar+name row, so its left edge lined up with the avatar — now lives inside the name column, lining up with the name/title text instead. Phase 24 is fully wrapped as of this change.

[1.0.75] - 2026-07-28

Changed

• Opportunity thank-you page is no longer a dead end, and no longer relies on the body copy to say what you signed up for (Phase 21.6) — The page now names the opportunity itself (“You signed up for Admissions Fair”) instead of hoping the staff-written thank-you text mentions it, and reads back a “What you sent us” receipt of the contact details and answers just submitted, so a typo is catchable before staff follow up. Every visitor now leaves with somewhere to go.
• A signed-in submitter is treated differently from an email match (Phase 21.6) — champion_signup_id alone conflated two very different confidence levels, so a new signup_link_method column records how the link was made: verified (they arrived with a profile token or an active session and submitted from their own hub — this is them) or email_match (the address they typed belongs to a signup on file — probably them, and nobody confirmed it; shared inboxes, couples and typos all land here). A verified submitter now gets a personalized thank-you (“Thanks, Chip”) and a Back to your profile button, and is no longer asked to “make it official” or offered “already signed up with us?” — they plainly are. Everyone else, including an email match, still gets the identical anonymous page, since treating a guess as proof would make the form a backdoor login and reintroduce the enumeration leak. The personalization requires live proof on the request, not the stored flag, so a stale session can’t unlock it. In Signup Admin the “Are they on file?” panel became three states with matching list badges and filter options — Confirmed — same person, Likely — matched on email (“don’t treat it as confirmed”), and New to us — and the CSV gained a signup_match column so a list handed to whoever does outreach doesn’t present a guess as a confirmed identity.
• Profile hub relaid out as a two-column dashboard that adapts to where you are (Phase 21.6) — The hub had grown to six equal-weight full-width surfaces stacked in a narrow max-w-2xl column, which read as an undifferentiated pile of white boxes and buried the highest-value action fifth. It’s now max-w-5xl with the things to do (opportunities, profile sections) in a main column and reference material (contact details, the alumni team) in a sidebar, collapsing to one column on mobile. The lead block adapts: an unfinished profile leads with “About you” and the ask to complete it; a finished one leads with “Ways to show up” and collapses the completed sections to a quiet “All set — thank you!” strip with their explanatory blurbs dropped, so a finished profile stops looking as noisy as an empty one. A missing ZIP still outranks both and is hoisted full-width under the header. The standalone “why more info helps” surface was folded into the section heading and progress bar it was explaining.
• The Opportunities editor moved into Signup Admin (Phase 21.4) — 21.5 shipped the CMS under Champion Admin at /champions/opportunities while the leads it produces belong to the signup ecosystem. Two admin shells for one feature is wrong, so the editor relocated to /champion_signups/opportunities and the responses queue landed beside it under a new Opportunities sidebar section. ensure_portal_admin! is now declared on the controller rather than inherited — editing a live public form is a publishing action, so it stays portal-admin-only while the responses queue is staff-level like every other lead list in that shell. The old /champions/opportunities path and its Champions sidebar entry were removed outright with no redirect: nothing external pointed there and nothing had been authored in production. A namespace/shell move only — models, migrations, the row editor and the public field partials are untouched.

Fixed

• CSV export buttons spun forever and downloaded nothing — 11 of them, across the whole app — Reported on the Opportunity Responses queue, but the sweep found it everywhere. Turbo intercepts every same-origin link click and fetches it expecting an HTML document to swap into the page; a send_data response is an attachment with no document to render, so Turbo never completes the visit. The progress bar spins indefinitely, no file arrives, and there is no error, no console warning, and no failing test — the controller test passes because the endpoint itself was always fine. The bug lives entirely in the link markup, which is exactly why it had shipped eleven times. Every export link now carries data: { turbo: false }: opportunity responses, Affinaquest conflicts and CRM changes, orphaned alumni, the education-import gap CSV, data health unmapped schools, both statistics downloads (degrees and lifestage), batch search, legacy verification, engagement-stats activity pairs, and champion email logs. This class of bug is now test-enforced rather than documented and forgotten: test/views/csv_export_links_test.rb parses every controller for actions that reach send_data/send_file — following one level of indirection, so an index that delegates to a private send_csv_export is still caught — resolves them to route helpers, and fails if any view links to one without an opt-out. A new export shipped with a naive link fails that test before it reaches staging; nobody has to remember the rule. Two things the scanner had to get right: comments are stripped before matching call sites (a stray # persisted to disk for download/resolution otherwise parses as a call to #download and taints every caller), and a helper serving both HTML and a download is only flagged when the link actually requests the file, so a “Back to Logs” link isn’t a false positive.
• An opportunity title containing a hyphen produced an invalid slug — parameterize(separator: "_") does not strip hyphens already in the string; its regex whitelists - alongside alphanumerics. So an everyday title like “Send-Off Party” generated send-off_party, which then failed the Opportunity model’s own slug format validation, and the save died with “Slug may only contain lowercase letters, numbers, and underscores” on a title staff had every reason to type. Opportunity#slugify now folds hyphens into underscores, collapses runs, and trims the edges, so any title produces a slug that validates. Regression tests cover a hyphenated title and one with punctuation at the edges. No other caller in the codebase uses that parameterize form.

Security

• Staff-authored markdown on public pages is now sanitized — Opportunity copy is typed into a web form by staff and rendered on an anonymous public page, so it gets its own renderer (OpportunityMarkdown) with escape_html and safe_links_only: raw HTML is shown as text rather than parsed, and javascript:/data: URLs never become links. The existing Cp::WelcomeContentGenerator.markdown_to_html was not reused despite the spec calling for it — it sets neither flag and ends in .html_safe, which is safe for its own developer-authored YAML input but would have been stored XSS here. That method is unchanged and still serves welcome packs.

Added

• Alumni employment is importable from the CRM (Phase 24.1–24.3) — Staff had no way to answer “which of our alumni work at HCA?”, a question that comes up constantly for corporate partnerships, event hosting and career-connection asks. Advancement Services has had the export the whole time; it had never been ingested. A new employments table now holds it, with the import wired end to end at Settings → Data Imports → Employment (CRM) on the same background scan → preview → commit flow as the Phase 18.3 education imports (upload, poll a live progress bar, review, commit — no 30-second request to time out). It stores current employment only, one-to-many. The source feed emits an alum’s current positions and nothing else, so an employment history table would be populated with fiction; alumni genuinely holding two jobs get two rows. The import is a per-BUID replace, and the preview says so before you commit. For every BUID the file names usably, the file’s rows become that alum’s complete current set and existing rows the file omits are deleted — which is the only way stale employment gets removed rather than accumulating. Alumni absent from the file are untouched, so a partial export is safe where a global truncate-and-sync would wipe everyone it omitted. Because that is destructive by design, to_delete is a first-class count alongside create/update/skip: the batch page shows a red banner naming how many records will go and a table listing each one, and the operator sees the number before clicking Commit rather than discovering it after. A BUID whose only rows are unresolvable (bad alum, no upsert key) is deliberately not treated as a replace instruction — their real rows survive rather than being destroyed on the strength of a broken row. Upserts key on the Salesforce Employment: ID, so re-uploading an identical file reports 0 created, 0 updated, 0 deleted. The export pads with thousands of ,,,,,,,, rows; those are dropped at parse time and never reach the counts. Only three things stop a row being written — no BUID, a BUID matching no alum, or a missing Salesforce id to key on — and each lands in a downloadable gap CSV carrying both BUID and BQID for cross-reference. A missing employer name no longer blocks the row, and isn’t treated as a gap at all. It’s the largest blank bucket in the real export; skipping those rows threw away the job title, start date and record id that came with them, so they now import with the employer blank (rendered as a labeled “no employer name” rather than an empty cell). Unlike an unresolved BUID or a bad date, there’s nothing upstream to chase on a missing employer — the CRM simply doesn’t have one — so it stays out of the gap CSV entirely and only shows as a one-line warning in the preview. A bad start date or an unrecognized Started value is different: those do land in the gap report, imported blank, rather than being silently nil’d. Dates run through the shared Csv::DateParser, so 4/1/84 is 1984 and 7/27/26 is 2026. Employer names are normalized (unaccent, downcase, punctuation stripped) into a trigram-indexed column, with legal suffixes deliberately kept — stripping them would collide genuinely distinct entities. Profile display and employer search shipped separately as Phase 24.4–24.5, below.
• “Which of our alumni work at HCA?” is now a search box (Phase 24.4–24.5) — The question that motivated the whole phase is answerable in the app. An Employer field joins the Advanced Search Options, and it’s forgiving in both directions: universal music finds Universal Music Group (partial match), and a typo like vandrbilt falls through to a trigram match ordered by how close it is, showing the same “showing closest spelling matches” notice the name search uses. Your term is normalized exactly the way the importer normalized the stored value, so Prince Properties, LLC typed verbatim matches. soundex is deliberately not in the mix — it’s tuned for single surnames and turns multi-word company names into false matches. Matching runs through a subquery rather than a join, which is the difference between an alum with two matching positions appearing once and appearing twice — in the results list and in the CSV. Results rows gained an employer + title line under the district, showing the most recent position only so row height survives 50 results a page; the full set lives on the profile, where a new Employment card after Degrees lists every current position most-recent-first with its start date rendered at the precision the CRM actually has it (Since Aug 2013 when the date is known, Since on or before Mar 2026 when it isn’t, nothing at all when there’s no date). Rows imported without an employer — a large bucket, kept for the title and start date they carry — render as “Employer not on file” rather than an empty heading, and can’t match an employer search, which is expected rather than a bug. The card carries a one-line note that this data comes from BruinQuest and changes only by import, since editing it in the app would be silently reverted by the next run (that’s Phase 22 territory). The alumni CSV export gained employer and job_title, most recent only.
• Alumni can now say yes to something specific (Phase 21.2) — Opportunity forms are live on alumnichampions.com at /opportunities/:slug: a shareable, anonymous-capable page rendering the questions staff authored, with the contact block that turns an answer into a lead. Submitting records an OpportunityResponse, alerts staff in-app and via web push, and lands on a per-opportunity thank-you page carrying the staff-written copy and “what happens next”. An inactive or unknown slug 404s — there’s no public index, and no “this is closed” page that would confirm a link was once real. Spam protection is the signup flow’s honeypot (silent fake success: the bot gets the same redirect, nothing is written, nobody is notified) plus a new per-IP rack-attack throttle of 5 submissions per 30 minutes; legitimate repeats are days apart, so it never bites a real person. Privacy consent follows the 19.11 treatment — a plain disclosure + link, no checkbox, with the version shown recorded on every response. The thank-you page reads identically for everyone, whether or not the submitted email matches a signup we already have: no “welcome back”, no name echo, and never a link into the profile hub. A public form that revealed or granted on-screen access to someone else’s record on an email guess would be a backdoor login, and identical copy also closes the email-enumeration leak. The only route to a returning signup’s record stays the link emailed to the address on file, offered to everyone by the same CTA. A test asserts the two pages are byte-identical once per-request tokens are normalized out.
• The conversion loop — an anonymous form-filler becomes a signup (Phase 21.2) — The thank-you page invites people to “make it official”. The link carries a signed, 7-day reference to the response they just submitted, so the signup form arrives pre-filled with what they already typed (“We’ve started you off with what you just told us”), and completing it links the response back to the new signup. This is the thing a Google Form can’t do: the lead, the conversion and the CRM linkage stay attached instead of ending up in a disconnected spreadsheet. Signed rather than a bare id, because the token pre-fills a form with someone’s contact details.
• Opportunities on the profile hub (Phase 21.3) — Returning signups see a “Ways to show up” section listing every live opportunity — distinct from the profile sections above it, which ask about them. Each link carries their profile token, so the form arrives pre-filled and the response is attributed to their signup rather than landing anonymous (source: opportunity_hub). The section disappears entirely when nothing is live; an empty “nothing right now” block would be worse than silence. Known-signup views and submits record opportunity_viewed / opportunity_submitted ChampionSignupEvents; anonymous traffic records nothing, since it has no signup to hang an event on and the response row is its record.
• Staff queue, notifications and export for opportunity responses (Phase 21.4) — New Responses view in Signup Admin: filter by opportunity, district, already-on-file vs. new to us, review state and date range; sortable and paginated, with location shown as city, state rather than the Census metro district. The detail view shows every answer — including answers to since-retired questions, labeled as such, which is the whole reason fields soft-delete — plus contact details, consent state, and a link to the linked ChampionSignup when there is one. Opening a response marks it reviewed (idempotent, so a reload doesn’t move the timestamp) and there’s a manual Mark unreviewed toggle; the sidebar badge counts unreviewed, not total, because a badge that only ever grows stops being a signal. This is read/unread only — deliberately not the deferred applied→confirmed→completed workflow. Every response fans out one StaffNotification (in-app + web push, no email) to admins and portal admins via NotifyOpportunityResponseJob. Csv::OpportunityResponseExporter exports one opportunity at a time with dynamic columns — one per question in the opportunity’s own field order, retired ones included and marked — plus contact, city/state/district, consent, champion_signup_id and, when the linked signup has a BUID, both buid and contact_id. A union CSV across all opportunities is deliberately not offered: answer keys differ per form, so it would be sparse and grow a column every time staff author a new one.
• Opportunities CMS (Phase 21.5) — Staff can now author an opportunity end to end in the admin, so adding one is an afternoon’s work instead of a developer ticket and a deploy. New Opportunities section under Content in Champion Admin (/champions/opportunities, portal_admin only): title, shareable link, three markdown copy blocks, and a repeatable question editor covering the five field types. A Preview renders the real public form off the real partials — disabled, unsubmittable, and it creates nothing — so what staff approve is literally what an alum will see. Duplicate deep-copies an opportunity (inactive, fresh link, regenerated question keys, no responses) since most new opportunities are variations of an existing one. Going live is a toggle, not a deploy. The editor makes the destructive moves impossible rather than merely discouraged: a question’s key is shown as permanent metadata, “Retire” replaces delete (retired questions leave the form but keep their answers in the staff view and export), the link renders read-only and is stripped from the submitted params once it’s been shared, an amber banner explains what’s still editable once people have answered, and Delete disappears entirely once a single response exists.
• Opportunities data model (Phase 21.1) — Foundation for Alumni Opportunities: concrete things an alum can sign up to do (represent Belmont at an admissions fair, host a watch party, speak to prospective students, host a send-off). Two new tables, nothing routed or publicly reachable yet. opportunities holds staff-authored definitions — title, URL slug, an active toggle, three markdown copy blocks, and an ordered fields jsonb array — so a new opportunity is authored in the admin rather than shipped in a deploy (spec §2c). opportunity_responses is the submission: contact block, city/state/district derived from the ZIP via ZipCode.lookup, consent stamps mirroring 19.11, and answers jsonb keyed by field. Three integrity rules live in the model, not the UI, because they’re what make editing a live form non-destructive: a field’s key is minted once from its label and frozen forever (answers are keyed by it), fields are soft-deleted rather than removed (an inactive question stops rendering but its answers stay readable), and the slug locks once an opportunity has been activated or has responses — keyed off activated_at so the documented deactivate → fix → reactivate rollback can’t quietly break links already shared. A submitted email matching an active signup auto-links champion_signup_id server-side only; nothing about the match may surface on the page, since a public form that revealed or granted access to someone else’s record on an email guess would be a backdoor login. Responses stay identity-agnostic (nullable FK only, own table) so a future portal surface is an additive column, not a rebuild.

[1.0.74] - 2026-07-26

Fixed

• Location displays led with the Census metro district, not the alum’s city — A signup reported their profile said they were in “Kiryas Joel” when their ZIP (12520) is Cornwall On Hudson, NY. The data was correct: 12520 resolves to city Cornwall On Hudson but sits in the “Kiryas Joel-Poughkeepsie-Newburgh, NY” metro district, and every location display was surfacing the district name as the headline. v2 signups store only a ZIP (no city), so the confirmation card fell straight through to district.name. Fixed everywhere location is shown: the public profile hub (sign-up/:id) now confirms “We have you in Cornwall On Hudson, NY · 12520” — the city resolved from the ZIP via a new ChampionSignup#primary_location / #resolved_city (never the metro district on this user-facing card), plus the entered ZIP echoed back so people can verify it. The staff signup detail page and the belmontalum.com portal (My District sidebar, own profile, directory) got the same treatment: City, ST · ZIP as the bold primary with the district demoted to a faded “Part of the {district} district” reach line (Cp::LocationHelper, Cp::Champion merged city/state). The directory stays privacy-aware — it shows a champion’s city only when their address privacy is Public, never leaks the ZIP to other alumni, and keeps district-only records district-only. Tests: new helper + model coverage and controller regressions reproducing the ZIP-only “Kiryas Joel” case; full suite 4,742 runs / 0 failures / 0 errors.

[1.0.73] - 2026-07-24

Added

• Returning signups are prompted for a missing ZIP — ZIP is now a required field, but people who signed up before that (or who skipped it) had no idea we were missing it. The profile hub now surfaces contact + location at the top of the page: when a ZIP is on file it confirms “We have you in {city/district}”, and when it’s missing it shows a prominent amber prompt (“We’re missing where you live”) explaining that a ZIP is how we connect them with Bruins nearby and invite them to local things, with an “Add your location” button. The old quiet contact card at the bottom was removed.
• “Already filled this out?” link on the signup landing — A small link under the hero CTA anchors down to the existing “Already signed up? Get your update link” form, so returning alumni don’t scroll past the whole page looking for it.

Changed

• Signup Admin list restructured into a scannable roster — Reworked from spacious, wrapping rows into four tight columns modeled on the alumni roster: Name (with BUID + location stacked beneath), Class & Degrees (pulled from the linked alumni’s real education — degree, major, college, year — eager-loaded to avoid N+1; falls back to the self-reported class year when unlinked), Interests & Groups, and a terse Last activity (“Updated contact” / “Opened via link” / “Requested link” instead of full sentences). To tell interest-lean from group affinities at a glance, the lean pill is a solid role color while group pills are outlined (rare groups keep an amber outline). Location now includes the state — “Nashville, TN” / “Madison, WI” — matching the District Activity chart so it’s clear which “Madison” someone means (district→state preloaded in one query). whitespace-nowrap on the degree/lean cells stops the earlier wrapping.

[1.0.72] - 2026-07-24

Added

• Signup Admin gains a real segmentation List (Phase 19.12) — /champion_signups/all was a data dump that “segmented for the sake of segmenting”; it’s now a tool for answering a specific ask (find people in a metro for an event, in a group for a reunion, in an area for a panel). Every filter passes a “find people who __ so that I can __” test. New capabilities: a Sort control (Most recently active — the default — / Newest / Name / Rarest group first); Leans toward [area] as the person’s dominant interest, replacing the deprecated Role column with a sortable one-word chip; and rare/popular group targeting — each Belmont group’s total size is precomputed, rare groups (≤5) are annotated inline (e.g. “Chess Club · 2”), and a Group size band filter surfaces reunion-able niches (≤5, a member could host it) or movement-sized cohorts (≥15). Columns collapsed to Person / Last activity / Location / Interests-&-Groups / View (Date, Status and Role folded into Person and Last activity), and the Interests cell now wraps — together the real fix for the residual horizontal scroll. The person’s name links straight to their signup, and the Leans chip is color-coded to the role it names (connection→fountainblue, digital→skyblue, community→belmontblue, giving→belmontred). The lean is derived from stored interest_scores when present and otherwise computed from the quiz answers, so v1 signups — who answered the same quiz but never had scores backfilled — get a lean too (ChampionSignup#top_interest_area).
• Top Groups on the Signup dashboard — Alongside Top Districts (where our people are), the dashboard now shows the top Belmont affinity groups by member count; both lists click straight through to the auto-filtered List, so a hot spot or a large cohort is one click from the people in it.
• Dashboard activity feed — Replaces the flat “Recent Signups” list with one time-ordered stream that states what happened — “signed up”, “Saved their professional info”, “Came back and saved their Belmont groups” — merging new signups (by created_at, so event-less/legacy rows still appear) with profile-update events. Answers “who’s new AND who re-engaged, and exactly what they touched” at a glance.

Changed

• Signup detail page reorganized v2-first and de-cluttered (Phase 19.12) — The show page was label-value soup with v1 and v2 data at equal weight. It now opens with an identity bar (name, class, v1/v2, link status, location, return activity) and groups data into signup-shaped sections — Contact, Education, Groups, Professional, Interests, Activity — with empty sections hidden entirely (no more “Not provided” rows) and all v1-only data (deprecated Role, life stage, quiz responses, legacy notes) collapsed into a single “Legacy (v1) details” block. On unlinked records the alumni-matching panel floats to the top (linking is the job there); on linked records it’s a compact side-rail reference.
• Signup dashboard is now activity + triage, not analytics — Stat cards became a clickable health strip (Total, New this week with a week-over-week delta, % linked, Needs attention = unlinked + duplicates), each linking to the matching filtered List. The completion funnel moved off the dashboard to Signup Insights, where process-rate analytics belongs.
• Signup Insights is now rates-only — The “Most Recent Returners” individual list was removed; naming specific people is the Dashboard activity feed’s job, so Insights stays focused on funnels and return-rate analytics for improving the signup instrument.

Fixed

• Education on the signup detail page was blank for linked alumni (Phase 19.12) — The page read the signup’s own college_code/major_code — v2 self-reported columns that are empty for nearly everyone — so a linked alum with real degrees showed “College Code: Not provided” even though their alumni profile listed a BS in Accounting. The Education section now reads the linked alumni’s Alumni::EducationProfile#all_entries (the same verified read path alumni#show uses), rendering every awarded degree; the self-reported codes remain only as a decoded fallback for unlinked v2 records. Regression test guards a linked signup rendering its real degree.

[1.0.71] - 2026-07-23

Added

• Full education record on the public profile hub (alumnichampions.com) — The “we have you down as…” note named a single college derived from alum.educations.first, so multi-degree alumni saw only one of their degrees; one reported it as us not knowing them (“I graduated with 2 degrees and would associate with College of Business (BBA) more than my education degree”). New ChampionEducationService returns every awarded degree via Alumni::EducationProfile#all_entries (Education-first with legacy Degree fallback), oldest first, deduped on degree/program/college. One degree renders as a sentence (“We have you down as a BS in Accounting from the Jack C. Massey College of Business (2020)”); two or more render as a bulleted list closing with “If something’s off — or there’s one you’d rather we lead with — just let us know.” article_for picks a/an by how the code is spoken: all-caps codes read letter by letter (“an MBA”, “a BBA”), mixed case by spelling (“a PhD”, “an EdD”). Still shown only for BUID-linked signups.
• Return-visit tracking for signup re-outreach (Phase 19.10) — Answers “did the permanent-profile-link mail merge to v1 signups actually work?” Two denormalized columns on champion_signups — last_return_visit_at (opened their link) and last_enriched_at (saved an optional section >1h after signing up, i.e. told us something new) — stamped by a ChampionSignupEvent after_create callback and backfilled in the migration from events already on file, so activity predating this release is captured. Scopes returned/enriched/returned_or_enriched/never_returned. Surfaced three ways: “Came back”/”Added info” chips + a Return Activity filter on /champion_signups/all (counts follow the v1/v2 tab); a header summary and plain-language Activity timeline on the signup detail page; and on Signup Insights, the v1 came-back vs added-info split, which sections returners filled in, a v2 comparison, and the 20 most recent returners by name. NotifyChampionSignupReturnJob alerts admins on the first enrichment per signup (once per person, not per section) via in-app + web push — deliberately no email, so re-outreach campaigns don’t flood the admin inbox.
• Text-message consent alerts staff as discrete tasks — Nothing syncs sms_opt_in to any texting tool, and re-pulling the full list before every send isn’t practical, so every grant and withdrawal becomes a human task. A ChampionSignup after_commit records a consent_changed ChampionSignupEvent and enqueues NotifyChampionSignupConsentChangeJob, which creates a StaffNotification (in-app + web push) stating the action outright — “Add to the text-message list: Jane Doe (615-…)” / “REMOVE from…”. Fires on every change (unlike the return alert’s once-per-signup) because each one is a separate list edit that has to actually happen, and on create too, since a new signup who opts in still needs adding. The event row is also the only permanent record of an opt-out: the model NULLs sms_opt_in_at on withdrawal, so the column can’t say when someone left. Visible in the signup’s Activity timeline as “Opted IN/OUT of text messages”.

Changed

• Consent simplified to what the law actually requires (Phase 19.11) — Reworked the public signup’s three consent controls down to their real legal shape, replacing the coercive “must agree” gate that never reached production. Privacy Policy: a privacy policy is a disclosure, not a contract — no law requires collecting affirmative assent — so the checkbox is gone, replaced by a plain summary + link on the contact-info form; submitting is the acknowledgment, and the controller stamps privacy_policy_accepted_at/_version on a new signup to record which version was shown (never on an edit, so v1 legacy rows aren’t given a consent they never saw). Newsletter opt-in: dropped entirely — general alumni email is CAN-SPAM opt-out, there was no integration syncing the box to the newsletter tool, and Belmont runs its own public signup page; the hub now links straight to that page instead of offering a checkbox that pointed at nothing. Columns marketing_opt_in/marketing_opt_in_at removed; the newsletter is promoted through other channels (Champion emails, etc.) rather than cluttering the signup hub. Text messages: the one real gate (TCPA prior express consent) stays, and now rides contextually on the contact-info form’s phone field — the SMS opt-in reveals only once a number is entered, so the separate reach_you consent step was removed altogether.
• Signup CSV export carries consent state — Csv::ChampionSignupExporter gained privacy_policy_accepted_at, privacy_policy_version and sms_opt_in(_at). A list handed to whoever sends a text previously carried no record of who agreed to what. Blank/No means no recorded consent — which for SMS means do not text.
• Signup Admin list adapts to narrower desktops — /champion_signups/all forced a horizontal scrollbar around 1270–1570px because all seven columns were fixed-width with generous padding. Columns now drop progressively via container queries keyed to the table card’s own width — not the viewport, which mis-fired because the fixed 256px sidebar makes the content area much narrower than the window (a viewport xl: reveal showed columns the ~1000px content box couldn’t fit). Role + Interests hide below @6xl (1152px of card width), Location below @3xl (768px); Date, Status, Alumni and Actions always stay, cell padding tightened px-6→px-4, and overflow-x-auto remains as a last-resort safety net. The mobile card view (<sm) is unchanged.
• Staff signup consent panel trimmed — With the Privacy Policy now a disclosure rather than a gate, the signup detail page no longer shows “Privacy Policy accepted / Predates the policy” for every record. It surfaces the version shown at signup only when one is on file (evidentiary) and stays silent for legacy rows; the text-message line — the one staff must act on — is unchanged.

Fixed

• Public signup wasted mobile width and had two layout snags — Every signup page except the landing nested three padded layers (layout px-6 → step container px-4 → white card p-6), burning ~64px of side gutter on a 375px phone; only the landing escaped via its -mx-6 full-bleed sections. Tightened the layout to px-4 sm:px-6 and dropped the redundant middle px-4 on the step shell and profile hub, so it reads as one clean gutter around a single card (~+48px usable width on mobile); the landing’s full-bleed breakouts became -mx-4 sm:-mx-6 so they track the new gutter without overflowing. Two related fixes: the returning-user resume banner no longer horizontal-scrolls (its two whitespace-nowrap buttons stack on mobile), and the “I had a different last name” toggle is left-aligned with single-line copy in both states so opening it no longer shifts the fields below.
• Stale session swallowed the emailed profile token (alumnichampions.com) — load_signup was if session… elsif token…, so a session[:champion_signup_id] pointing at a soft-deleted or vanished record blocked the token branch entirely and left @signup nil. Two user-visible symptoms: people arriving on an emailed link who clicked an optional section were bounced to a blank “Let’s start with you” form (the STEPS_REQUIRING_SIGNUP guard also dropped the token on redirect), and the hub’s “Edit” link 500’d with undefined method 'maiden_name' for nil because editing_who_you_are? ran its own token lookup and disagreed with load_signup — returning true while @signup was nil, which skipped the ChampionSignup.new fallback. The explicit token now resolves first with the session as a fallback, dead session ids are deleted, editing_who_you_are? reads the single resolution (@token_signup), and an unresolvable token on a signup-requiring step goes to the expired-link prompt instead of a blank form. Token-first also closes a data-integrity hazard: under session-first, opening someone else’s emailed link while holding your own session rendered their hub but loaded your record into the edit form.
• Spam guard silently rejected real people on the “email me a link” form — SignupHoneypot::MIN_SECONDS = 3 is calibrated for the 6-field signup form, but the profile-link form is one field and a button; a returning user pasting their address or accepting autofill submits in ~2s and was classified as a bot. Because the guard responds with a silent fake success, the failure was invisible — same “check your email” screen, no email ever sent, only a [honeypot] blocked log line as evidence. spam? now takes min_seconds:; request_link passes the new SHORT_FORM_MIN_SECONDS (1s, still stopping a bot that POSTs straight after its GET) while the signup form keeps 3s.

[1.0.70] - 2026-07-21

Fixed

• Champion Form (alumnichampions.com) now sends staff push/in-app notifications on new signups — Previously a completed public Champion Form fired only the admin email; it never created the in-app bell notification or web push that the belmontalum.com signup flow produces. New NotifyChampionSignupAdminsJob mirrors Cp::NotifyAdminsJob: on first completion of step 1 it sends the admin email and creates a StaffNotification (new champion_signup type) per admin/can_portal_admin user, whose after_create_commit fans out to web push. The controller now enqueues this job instead of calling admin_notification directly. To match the push audience, the admin email recipients moved from the static CHAMPION_SIGNUP_ADMIN_EMAILS env list to the same admin/portal-admin User set used by belmontalum.com (the now-unused config/initializers/champion_signup.rb + CHAMPION_SIGNUP_ADMIN_EMAILS var were removed). Tests: 5 job tests, updated mailer recipient/no-op tests, updated controller enqueue test; full suite 4,668 runs / 0 failures / 0 errors.

[1.0.69] - 2026-07-21

Fixed

• Belmont privacy policy link on the portal Privacy Policy page — the outbound link to Belmont University’s general privacy policy pointed at belmont.edu/privacy/, which no longer resolves; it now points to belmont.edu/notices/privacy-policies/ and displays the full URL.

Added

• Portal feature flags — content-surface follow-up (Phase 20) — Second pass catching non-functional references to flagged features (help/FAQ, settings, submissions) that the controller/dashboard gating didn’t cover. The Help & FAQ page (config/faq.yml + Cp::HelpController) now filters FAQ questions/categories by a feature:/features: tag: the “Champion Roles” category, the news question, the event questions (incl. “career events”), and the whole “News & Events” category when both are off, all drop out. Settings → Notifications hides the “New Events” preference toggle when events is off. “My Submissions” hides the Share-News / Submit-Event buttons (and adapts its empty-state copy) per flag, and the “My Submissions” nav link hides when both news and events are off. cp_feature_enabled? moved from Cp::BaseController up to ApplicationController so it’s available to the ApplicationController-based controllers that also render the champions layout (Help, Policies). Legal pages (Terms, Privacy, Community Guidelines, Cookies) were reviewed and intentionally left unchanged — they are versioned, consent-tracked documents and their news/event references are forward-looking. Tests: 5 new (FAQ category/question filtering, settings toggle, submissions buttons); full suite 4,662 runs / 0 failures / 0 errors.
• Portal feature flags — Champion Role & Your Impact gating (Phase 20.3) — The Champion Role feature and the Your Impact card now hide from the belmontalum.com portal when their flags are OFF. champion_role gates the roles microsite, role detail, and Champion Info pages (Cp::RolesController/RoleIdeaClicksController/ChampionInfoController), the role-quiz wizard actions (Cp::ProfileWizardController#quiz/save_quiz_answer/quiz_results/select_quiz_role), and home#refresh_role_ideas — all redirect to the dashboard when off. Cp::DashboardVisibility now also gates role_ideas and champion_nudge on champion_role and your_impact on its own flag, so the role-ideas card, the “Find Your Role” nudge, and the Your Impact sidebar disappear regardless of journey stage. Role badges are hidden portal-wide from a single choke point (champion_role_badge helper returns nil), covering directory cards, discussions, boards, the dashboard hero, and the profile page; the dashboard role card, hero role text, and the profile Champion Role section are gated directly. Your Impact is independent of Champion Role, as specified. Note: the wizard has no discrete “role step” to skip (a stale doc comment implied one) — the quiz is a set of dedicated actions, gated directly. Tests: 9 new (role/impact controller redirects, badge+section hidden on profile, all-five-off dashboard smoke, DashboardVisibility gating + Your-Impact independence); full suite 4,657 runs / 0 failures / 0 errors. Phase 20 complete.
• Portal feature flags — content gating (Phase 20.2) — News, Photos, and Events are now hidden from the belmontalum.com portal when their flag is OFF. Gated controllers (Cp::NewsController/NewsSubmissionsController → news, Cp::EventsController/EventSubmissionsController → events, Cp::PhotoAlbumsController → photos) redirect to the dashboard via a require_feature! before_action (the public events#show page too). Cp::DashboardVisibility gains a SECTION_FEATURE_FLAGS map so show?(:events) returns false when the flag is off — one choke point covering the desktop sidebar, the mobile “events first” block, and event loading. The dashboard “What’s New” bar zeroes flagged-off content types and the activity feed drops news/photo items (discussions stay). The community page wraps its News, Photo Albums, and Upcoming Events sections in cp_feature_enabled?, reflowing cleanly with no empty gaps. No nav/footer changes needed (these features have no top-level links). Tests: 13 new (controller redirects both states, community reflow, all-off dashboard smoke, DashboardVisibility gating); full suite 4,648 runs / 0 failures / 0 errors.
• Portal feature flags — foundation (Phase 20.1) — DB-backed, staff-toggleable feature flags for the belmontalum.com portal so it can launch as a stripped-down, approvable core and re-introduce features (News, Photos, Events, Champion Role, Your Impact) one at a time. New cp_feature_flags table + Cp::FeatureFlag model with a closed 5-key set and resolution order ENV override (FEATURE_<KEY>) → cached DB value → false (fail-closed); the compact enabled-keys map is cached and busted on write. Cp::BaseController gains cp_feature_enabled?(feature) (helper, available in portal controllers + views) and a require_feature!(feature) guard (OFF → redirect to dashboard) for use in 20.2/20.3. Champion Admin toggle UI at /champions/feature_flags (portal_admin) with per-flag On/Off, description, and last-changed-by; new “System” sidebar section. Rows are created enabled: !Rails.env.production? (dev/staging unchanged, production launches dark) via the migration data-insert and an idempotent db/seeds.rb block; tests use test/fixtures/cp/feature_flags.yml (all on). This sub-phase is infrastructure only — no features are gated yet. Tests: 15 new (9 model + 6 controller); full suite 4,634 runs / 0 failures / 0 errors.

[1.0.68] - 2026-07-10

Added

• Public signup consent & privacy policy (alumnichampions.com) — The signup site now serves its own plain-language Privacy Policy at /privacy (Public::PoliciesController; nested domain-constrained route placed before the shared cp legal routes so it doesn’t resolve to the Alumni Network’s platform policy), committing that signup data is used entirely within Belmont and never sold. The who_you_are step now collects: a required Privacy Policy agreement checkbox (stored as privacy_policy_accepted_at + privacy_policy_version, versioned via ChampionSignup::PRIVACY_POLICY_VERSION; records predating the policy are asked to agree on their next edit), an optional “keep me in the loop” email opt-in (marketing_opt_in + timestamp), and an optional TCPA text-message consent checkbox with may-call disclosure (sms_opt_in + timestamp; cleared server-side when no phone is given). To keep the step from feeling overwhelming, the SMS consent block is progressively disclosed — hidden until a phone number is entered (new sms-consent Stimulus controller; unchecks itself if the number is cleared), and the policy/marketing checkboxes sit in a light divider-separated section rather than a boxed panel. Opt-in timestamps are stamped on grant and cleared on withdrawal (model callback). The site footer’s Privacy Policy link now points to the site’s own policy instead of belmont.edu’s. Champion Admin signup detail shows a “Consent & Communication Preferences” panel (policy acceptance date/version, email opt-in, text consent) so staff can check before reaching out. Tests: consent checkbox rendering/requirement, acceptance stamping, opt-in defaults and timestamps, SMS-without-phone clearing, edit re-consent for pre-policy records, privacy page rendering, footer link, staff consent-panel states, SMS block hidden/shown states; full suite 4,619 runs, 0 failures.

Removed

• Dead Google Maps/Places loader on the public signup site — the public layout loaded the Google Maps JS API (with Places) on every page for every visitor, but its only consumer, address_autocomplete_controller.js, was referenced by no view (v1 wizard leftover — the v2 flow collects a plain ZIP text field). The CSP script_src didn’t even allow maps.googleapis.com, so the script was already blocked wherever CSP is enforced. Removed the layout block, the orphaned Stimulus controller, and the window.initAutocomplete global in application.js. One less third party receiving visitor IPs pre-consent; the GOOGLE_PLACES_API_KEY env var is now unused and can be dropped from app config.
• Public signup site chrome: sticky header, Belmont logo link, footer, team call-out — The alumnichampions.com header now sticks to the top on scroll (sticky top-0 z-50) and its right side carries the reversed Belmont University logo linking to belmont.edu/alumni (user-swapped; alt text corrected to “Belmont University”). New site-wide footer (public/champion_signups/_footer, rendered by the public layout with a min-h-screen flex column so it pins to the bottom of short pages) modeled on the Alumni Network footer — Belmont logo + address/phone, social icons, © year — with the bottom links matching belmont.edu’s standard set: Legal Notices, Privacy Policy, Non-Discrimination, Title IX. The profile hub’s “← Back to Belmont Alumni” text link was replaced with a “The people behind Alumni Champions” call-out card whose CTA sends visitors to the Meet the Alumni Team page (belmont.edu/alumni/about-the-team.html). Tests: header/footer/call-out coverage in the public controller suite; full suite 4,604 runs, 0 failures.

[1.0.67] - 2026-07-09

Fixed

• Welcome email text/HTML drift — a copy edit to the HTML welcome email (new “Alumni Champion FYI” newsletter paragraph, reworded P.S. link text, P.S. block moved to after the signature) wasn’t mirrored in the plaintext version, which still had the old link text and the P.S. in its original position (right after the intro paragraph, well before the signature). Reordered and reworded the text template to match the HTML exactly; added a regression test asserting the signature precedes the profile-link P.S. in both formats.
• v1 quiz answers rendered as one interest area at 100% — v1 (legacy) signups store quiz answers as {"q0" => "a", …, "q8" => "d"} (letter values, 7–9 questions — all 1,277 stored values are scoreable letters). The public interest-spectrum fallback did answers.transform_keys(&:to_i), and since every "qN".to_i is 0 the whole hash collapsed to a single surviving answer — so returning v1 users (via the new permanent profile links) saw one area at 100% instead of their real mix. New ChampionQuizService.normalize_answers is the single cross-generation answer parser (v2 "0"-keys, legacy "q"-keys kept distinct as integers; word-valued oldest rows dropped) and now feeds the public spectrum fallback, the quiz current-answer prefill, the final-answer scoring, the staff show-page fallback (replacing its all-letters guard), and handle_question’s merge — which also converges a legacy record’s "qN" keys onto canonical "0".."6" and drops beyond-range leftovers when they retake the quiz. The champion_signups:backfill_interest_scores rake task no longer skips legacy rows: it scores anything normalize_answers can parse (dry run against dev data: 163 of 188 legacy rows get real distributed spectrums) and now writes result_role through explicit enum-value mapping instead of the raw key. Why it wasn’t caught: the fixture’s legacy answers used word values unlike real production letter data, so no test exercised the true legacy shape. Regression tests at the service level (normalize_answers) and through the public flow (legacy q-keyed answers render a distributed spectrum; word-valued rows render empty, not garbage).

Added

• Phase 19.9 — Signup Admin dashboard, zip-to-district, spam guard, mobile cards — Re-elevates Champion Signup admin tooling and de-elevates the Alumni Network in the staff nav. Dashboard: /champion_signups becomes a sidebar-based dashboard (layouts/signup_admin, champion_signups/_sidebar, reusing the champion-admin-sidebar Stimulus controller) with quick stats, recent signups, top districts, a completion funnel, and a duplicates alert; the filterable list moves to /champion_signups/all. The dead duplicates route/action (no template — would 500) was removed in favor of ?status=duplicates. Navbar dropdown section renamed “Champion Signups” (Dashboard + Signup Insights); Alumni Network admin is now reached via the sidebar’s “Alumni Network Admin” link rather than its own dropdown section. Districts: new champion_signups.district_id (migration backfills 157/158 zip-bearing rows in place), assigned from zip_code on save (ZipCode.lookup, digit-stripped so a spam row’s quote-wrapped zip resolves correctly; self-heals nil districts; never overwrites v1 city/state). ChampionSignup#location_label (“District — Region”, falling back to city/state, then raw zip) now leads every location display — list column, show page, and the admin-notification email’s new Location row. The staff list filters by district via the shared district-autocomplete Stimulus controller + /api/districts (same mechanics as /alumni_search). Spam guard: new SignupHoneypot service — an off-screen website field plus a signed 3-second minimum-time render trap — on the public step-1 and profile-link forms. Tripped submissions get a silent fake success (no record, no email) and are logged with a [honeypot] tag for auditing. Email signature: all three signup mailer emails (welcome, profile-link, admin notification) now render a shared shared/email/_team_signature partial (“The Belmont Alumni Engagement Team”) in place of per-email hardcoded signatures. Mobile: /champion_signups/all gets a sm:hidden tappable-card list (name, v2/status/BUID/duplicate badges, location, date, simple pagination) mirroring /champions/champions/all, with the desktop table under hidden sm:block; secondary filters (Interest Area, Submitted, Affinity) collapse into a “More filters” disclosure that auto-opens when active, leaving Status/Role/District visible by default. One migration (20260709120000_add_district_to_champion_signups, backfills in-place, no rake task needed). Tests: new/updated coverage for district assignment + location_label (model), the honeypot on both public forms (controller), the district filter and dashboard rendering (staff controller), and the unified signature (mailer); full suite 4,601 runs, 12,521 assertions, 0 failures, 0 errors, 3 skips.
• Signup flow polish: page titles, email header/footer unification, v1 re-entry codes, and Signup Insights — Page titles: the public layout’s hardcoded <title>Belmont Alum</title> (which silently ignored the content_for :title views were already setting) now yields per-page titles in the standard Page Title | Belmont Alumni Champions format — landing is the bare site name; steps get “Sign Up”, “Your Belmont Groups”, “Where You Are Now”, “Interest Quiz (N of 7)”, “Where Your Interests Lean”, “Your Interests”; the hub is “Your Profile” (STEP_TITLES + page_title_for in the public controller). Emails: the welcome email’s image header band was replaced with the text header format from the profile-link email (uppercase “Alumni Champions” eyebrow + personalized headline); all three signup emails (welcome, profile-link, admin notification) were converted to the shared shared/email/base_styles document pattern (dark-mode support included) and now end with the Belmont branded footer (logo-primary-reversed.png, address, phone, social icons, “You’re receiving this because…”) in HTML and the shared text footer in plaintext; _branded_footer learned an explicit manage_url: nil to omit the preferences link for recipients with no portal account. The alumnichampions.com host/staging detection was extracted from ChampionSignupMailer into AlumniChampionsHost so mailer and model links can’t drift. v1 re-entry codes: new champion_signups.access_code column (unique index, has_secure_token on create, ensure_access_code! lazily backfills pre-column rows) backs a permanent — unlike the 72-hour signed tokens — re-entry link at GET /profile/:code, which adopts the signup into the session and lands on the profile hub (unknown/deleted codes fall back to the “email me a link” prompt). No v1→v2 data migration was needed: both generations share the champion_signups table, the hub renders v1 contact data as-is, and v1 quiz answers already fall back to live interest-spectrum computation. The CSV export gains access_code + profile_link (mail-merge-ready https://alumnichampions.com/profile/CODE) columns, and the staff index source toggle gains a v1 (legacy) pill (virtual source=v1_legacy filter → ChampionSignup.v1_legacy; v2 rows now stamped via ChampionSignup::V2_SOURCE). Signup Insights (GET /champion_signups/insights, staff): top-line counts (total/v2/v1/return visitors/link requests), a v2 optional-section completion funnel (column-derived predicates, so it covers pre-event records), a v1 legacy wizard funnel with a “v1 signups that returned” counter, and an initial-sitting vs. return-visit table backed by a new champion_signup_events table (ChampionSignupEvent.record — fire-and-forget, never breaks the public flow) instrumented on signup creation, every section save (returning = saved >1h after signup), token/access-code return visits (30-minute throttle), and link requests. Production bug root-caused (no code fix): /champion_signups 500 (PG::UndefinedColumn: column "source" does not exist) is the Phase 19 migrations never having been run on production — deploys don’t auto-migrate (no Procfile release: phase); documented in the debug skill + copilot gotchas, fix is heroku run rails db:migrate -a alumni-lookup. Tests: new coverage for access codes/scopes/permanent URLs (model), ChampionSignupEvent, the /profile/:code route + event instrumentation + page titles (public controller), the v1 filter/insights/CSV columns (staff controller), and email header/footer assertions (mailer); full suite 4,576 runs, 12,410 assertions, 0 failures, 0 errors, 3 skips.
• Welcome email rewrite + Alumni Champions branding pass + dev-server URL bug fix — The welcome email body was rewritten to a fixed letter format (“Dear [name],” → “You are now officially an Alumni Champion!” → magic-of-Champions paragraph → the “Want us to connect you with the right opportunities?” profile-link card → the three Bruin/social-follow action items → “— The Alumni Team”), replacing the prior per-role-personalized copy; the header band now renders the Champions logo (header-alumni-champions-white.png) instead of plain text. Champions branding on alumnichampions.com: favicons and the PWA manifest (manifest-champions.json, not previously linked from the layout) now point at the -champions icon set instead of -alumni-network; meta-image-champions.png is the Open Graph/Twitter image on both the landing/signup flow and the congrats hub; the site header swapped the Belmont wordmark for the white horizontal Champions lockup. (Hero and congrats-hub logo placement is still being iterated directly by the user — currently on the generic Belmont wordmark rather than a Champions-specific lockup.) Bug fix — dev server is SSL-only: Procfile.dev binds Puma as ssl:// with no plain-HTTP listener, but protocol: "http" was hardcoded for dev.* hosts in 7 places (ChampionSignupMailer#default_url_options/#lookup_url_options, ChampionEmailUrlHelpers#default_url_options/#lookup_url_options, Cp::ChampionMailer#default_url_options, Cp::Champion#invite_url/#community_invite_url) — any image or link built from them connected but hung/returned an empty reply instead of erroring, with no exception to flag it. All switched to https. A related but distinct bug surfaced in the same sweep: Cp::ContentSubmissionMailer#staff_submission_url and Cp::SupportThreadMailer#staff_thread_url pointed at local.test, a host with no DNS record at all (broken regardless of protocol) — repointed to dev.alumnilookup.com:3000, matching every other Lookup Portal link in the app. Cleanup: removed two untracked, unreferenced image files (28F2FCBC216BD19.png/.jpg) that had been dropped directly into public/. Tests: new/updated mailer and model coverage for the corrected URLs (champion_signup_mailer_test.rb, content_submission_mailer_test.rb, support_thread_mailer_test.rb, cp/champion_test.rb); full suite 4,549 runs, 12,266 assertions, 0 failures, 0 errors, 3 skips.
• Public signup — landing & email polish + shared-device safety — The landing hero now layers the campus photo behind the blue gradient wash. The landing is session-aware: when the current device already has a signup, a resume banner offers “Continue to your profile” plus a confirm-gated “Not you? Start a new signup” that clears the session (DELETE /sign-up/session → champion_signups#reset, 303). Fixed a latent shared/kiosk bug where a tokenless “Get Started” on a device that still held a prior session would silently overwrite the previous person’s record — create-vs-edit on who_you_are is now driven by the profile token (which the hub’s edit links carry), never the session. Emails: the welcome and profile-link emails were redesigned around a shared card layout (Belmont-blue gradient header band, white rounded card, prominent CTA, divided footer) and now send from “Belmont Alumni Engagement” (class-level default on ChampionSignupMailer, overridable via ALUMNI_ENGAGEMENT_FROM) and sign “— The Belmont Alumni Engagement Team”; the profile-link blurb was aligned to the landing copy. Staging-aware links: default_url_options/lookup_url_options now resolve the correct host on staging — staging_app? infers staging from HEROKU_APP_NAME or the LOOKUP_PORTAL_HOST/CHAMPION_PORTAL_HOST staging vars, with an explicit ALUMNI_CHAMPIONS_HOST taking precedence (also set ALUMNI_CHAMPIONS_HOST=staging.alumnichampions.com on the staging app). Tests: new controller tests for the resume banner, the fresh-vs-overwrite create path, and the reset action; new mailer tests for the from address, the matched blurb, and staging host resolution.
• Phase 19.8 — Interests Redesign: Spectrum Quiz — Replaces the single-winner Champion role quiz with a 4-area interest spectrum on the public signup flow, reusing the same 7 quiz questions. Scoring: new ChampionQuizService.interest_spectrum(answers) (additive — role_counts/generate_results/calculate_primary_role are untouched, so the authenticated Champion Portal quiz is unaffected) returns each area’s share of answered questions as a rounded percentage, persisted to a new champion_signups.interest_scores jsonb column (default {}) alongside the existing result_role (still the top-scoring area, for backward compatibility). Public flow: the Interests step (role) drops the direct pick-a-role path entirely and becomes quiz-only — if the signup already has answers, it shows the interest spectrum (icon + plain-language area name + percentage bar, no role-title text) with a “Retake the quiz” link; otherwise it prompts to take the quiz or skip for now. The post-quiz reveal (quiz_results) was redesigned around the same shared _interest_spectrum partial (“Where your interests lean”) with a single “Save and continue” CTA back to the profile hub, replacing the old “confirm this role” flow. Orphaned signup_role_options_controller.js (powered the old direct-pick reveal) removed. Plain-language area names: ChampionRoleService.area_name/area_label add “Making Connections,” “Sharing Stories,” “Bringing People Together,” and “Supporting Causes” as the four areas’ public-facing labels; the public UI shows only these (no parenthetical role titles), while the staff filter dropdown still pairs both via area_label. Staff admin: the signup show page gets an “Interest Spectrum” breakdown card (reusing the same partial, with a “leans most toward” icon header) that falls back to computing the spectrum live from answers when interest_scores isn’t stored, so pre-backfill quiz-takers still render a full breakdown; the index gains an Interest Area + Min Interest % filter (COALESCE((interest_scores ->> area)::int, 0) >= min, v2 quiz-takers only). Fixed the staff “Select” assign-alumni link, which used link_to … method: :patch + data-confirm — dead since @rails/ujs was removed in favor of Turbo, silently firing a GET against a PATCH-only route; switched to data: { turbo_method:, turbo_confirm: }. New backfill rake task champion_signups:backfill_interest_scores[dry_run] scores existing v2 signups that have answers but no interest_scores (skips legacy pre-v2 records, whose answers use word-valued "q0" keys rather than quiz letters). Tests: new service tests for interest_spectrum/area_name/area_label, rewritten public-flow controller tests for the quiz-only Interests step and spectrum reveal, new staff controller tests for the interest filter, the computed-fallback breakdown, and the Turbo-PATCH assign link; full suite 4,538 runs, 12,214 assertions, 0 failures, 0 errors, 3 skips.
• Phase 19.7 — Alumni Champions Signup v2.0: Congrats/Profile hub + flow reorder — Reshapes the public signup from a linear wizard into a hub-and-spoke flow where completion happens at step 1. Flow: the belmont_experience step is dropped entirely (we already have education from the alumni record; its belmont_background column is retained for legacy records + staff export/email). Step 1 (who_you_are) now completes the signup — it fires the welcome + admin emails immediately (guarded so later contact-info edits don’t re-send) and redirects to the new profile hub. The three remaining sections (affinities, where_you_are, role/Interests) are optional and each return to the hub. The multi-stage progress bar is removed (_progress_bar.html.erb deleted). Congrats/Profile hub (show.html.erb rewritten): adaptive first-visit “You’re in!” vs. return-visit “update your info” copy, a 3-section progress bar, optional-section cards with done/Add states, a contact-info edit link, and a BUID-gated education-record confidence note (“We have you down as a [College] grad”). Access gating: the hub now requires the signup session or a valid short-lived (:profile_access, 72h) signed token; unauthorized/expired/guessed-ID access redirects to the landing “email me a link” prompt instead of exposing PII — closing the prior /sign-up/:id-by-raw-ID enumeration hole. Return access: the welcome email carries a tokenized profile link, and a new landing-page form + POST /profile-link (request_link) + ChampionSignupMailer.profile_link_email let an existing Champion request a fresh link, always responding generically (?link_sent=1) to prevent email enumeration. Landing copy: “What is an Alumni Champion?” rewritten; the four role cards replaced with the four interest areas as examples (“Ways Champions show up”); role-framed CTAs reworded. Model: profile_token / find_by_profile_token, optional-section predicates (affinities_provided?, professional_info_provided?, interests_provided?, optional_sections_completed_count), and find_active_by_email. Deferred to BACKLOG: the ~3-day nudge email and a manual 4-slider interest-rating path; the role→interests step rename happens in 19.8. No migration. Tests: rewrote public controller suite for hub-and-spoke + access gating + request-link, added mailer + model tests; full suite 4,532 runs, 12,183 assertions, 0 failures, 0 errors, 3 skips.
• Phase 19.5 — Alumni Champions Signup v2.0: Confirmation + Staff Queue Integration — Completes the final planned sub-phase deliverables for the v2 public signup flow while keeping Phase 19 open for a short revision pass before full phase closeout. Public confirmation page: upgraded role branch with full role activity list and explicit next-steps messaging; no-role branch now shows a “Choose your role now” follow-up CTA only when a valid signed signup_token is present. Token hardening: final role completion redirects carry a signed token, and confirmation CTA rendering verifies token ownership against the displayed signup. Staff queue expansion: added filters for role status, BUID link status, affinity data presence, submission recency buckets, contactability, and specific affinity code. Staff show v2 data section: surfaces source, college_code, major_code, industry, job_title, affinity_other, and affinity_codes, with graceful unknown-affinity fallback (raw code when no mapping exists). Tests: expanded coverage in public and staff controller suites; full suite 4,522 runs, 12,126 assertions, 0 failures, 0 errors (3 skips).
• Phase 19.4 — Alumni Champions Signup v2.0: Full Affinities, Submission + Mailer — Replaces the 19.3 light-interest checkboxes on the Interests step with a full affinity browse/search and wires up email delivery on completion. Affinities step (steps/_affinities.html.erb) now reuses the cp-affinity-selector Stimulus controller for searchable, category-filterable affinity selection (Geographic and Post Graduation categories excluded, matching the profile wizard); affinity codes submit as top-level affinity_codes[] hidden inputs and persist to champion_signups.affinity_codes. The step also captures a free-text “other” group (affinity_other) and a belonging reflection (belonging_note, “Where did you feel the most belonging at Belmont?”). Per product direction, this flow intentionally does not capture lifestage_interest or belonging_categories. Source tagging: new signups are stamped source='champion_signup_v2' at step 1 creation. Submission/mailer: completing the final role step (both “confirm a role” and “skip for now” paths) enqueues two emails via deliver_later — a personalized welcome_email to the new Champion (role copy delegated to ChampionRoleService, generic fallback when no role) and an admin_notification to CHAMPION_SIGNUP_ADMIN_EMAILS summarizing all fields, source, BUID match status, and a staff review link. ChampionSignupMailer is restored with per-instance default_url_options (Alumni Champions domain for public links, Lookup Portal domain for the staff link) so its host settings never leak into other mailers. Staff queue: the signup index gains a v2 source badge and a Source filter dropdown. No migration required — all columns shipped in 19.1. Tests: public controller (57 runs) + new mailer + staff filter coverage; full suite 4,514 runs / 0 failures.
• Phase 19.3 follow-up — Role-page UX polish + resilient role submission path — Refined the public role step to better match Champion posture and reduce confusion. The role page now includes clearer relational framing and three explicit options: Take the quiz, I already know, and Skip for now. Role cards are intentionally hidden until “I already know” is clicked. Added signup_role_options_controller.js to reveal role options on demand. Fixed a session edge case where selecting a role could return users to landing by adding a signed signup_token fallback path in the controller when session state is missing. Added regression coverage; public signup controller tests now 44 runs / 0 failures.
• Phase 19.3 — Alumni Champions Signup v2.0: Quiz Flow + Role Selection + Light Interests — Makes the Role stage of the public signup fully interactive and replaces the Interests stub with a real capture step. Role hub (steps/_role.html.erb) is the first interactive page after the profession step: it shows all four role cards (using inner role icons, not full seals), a “Take the quiz” CTA for the unsure, and direct “Choose this role” buttons. After taking the quiz, the recommended role is highlighted with a “Recommended for you” badge and a “Confirm this role” button. Quiz (steps/_quiz_question.html.erb, reused for question1–question7) renders one question per page with options shuffled per render; answers persist to champion_signups.answers (jsonb) and back-navigation returns to the prior question (or the hub from Q1). Quiz results (steps/_quiz_results.html.erb) computes the recommendation via ChampionQuizService.generate_results, persists result_role, shows the role seal + narrative + full blend breakdown, then routes back to the role hub to confirm (“show results, then role”). Light Interests (steps/_affinities.html.erb) replaces the stub with interest-category checkboxes (belonging_categories) plus an optional free-text note (belonging_note); all fields optional. The confirmation/thanks page (show.html.erb) now celebrates the chosen role with its seal, title, and description. Controller adds handle_question, handle_role (finalizes selected_role, clears session, redirects to confirmation), and handle_affinities (light persistence), with the shared quiz partial wired via @partial_step. Reuses existing ChampionQuizService, ChampionRoleService, ChampionSignupsHelper, and role_seal_svg/role_icon_svg. Flow: who_you_are → belmont_experience → affinities (Interests) → where_you_are (Job) → role hub → [optional: question1–7 → quiz_results → role] → confirmation. Tests: public controller 42 runs / 0 failures; full suite 4,499 runs / 0 failures.
• Phase 19.2 follow-up — Flow simplification + ordered testing path (You → Belmont → Interests → Job → Role) — Updated the public signup UX to reduce friction and support phased QA. Step 1 (Who You Are) now captures graduation year(s) as free text and makes ZIP required (server-side enforced), with ZIP placed ahead of optional phone. Step 2 (Belmont Experience) now uses a single free-text belmont_background field for college(s)/major(s), replacing normalized selectors; this better handles renamed schools, older degree paths, and multi-degree alumni. Step 3 (Where You Are) is now profession-only (employment status + company/job/industry) and no longer conflates role selection. Added company column on champion_signups and signup_employment_status_controller.js for conditional field behavior (employed / seeking / not_working). Added affinities and role stub pages so the intended order is navigable while full 19.3/19.4 work continues. Landing and role cards now use inner role icon assets rather than full seal-in-seal rendering. Progress bar duplicate render bug fixed. Tests: public controller 30 runs / 0 failures; full suite 4,487 runs / 0 failures.
• Phase 19.2 — Alumni Champions Signup v2.0: Personal Info Flow (Steps 1–3) — Builds the first three data steps of the public signup wizard at alumnichampions.com/sign-up. Step 1 (Who You Are): name, an optional previous/maiden name behind a toggle-reveal, graduation year (a 1955→current-year dropdown), email, and optional phone + ZIP — this step creates the ChampionSignup record and stores session[:champion_signup_id]. Step 2 (Belmont Experience): a college → major cascade plus an “I never graduated from Belmont” option that clears both fields; majors are embedded in the page as JSON and filtered client-side by a new college_major_filter Stimulus controller (the staff-authenticated GET /api/majors endpoint would 401 in the public flow). Step 3 (Where You Are): industry + job title, then a three-way role path — “I know my role” (pick → role), “Help me decide” (quiz → question1), and “I’ll decide later” (skip → affinities) — implemented as three separate forms with a role_path Stimulus controller mirroring the shared industry/job-title inputs into each form’s hidden fields and handling pick-panel role-card selection. Controller: handle_who_you_are / handle_belmont_experience / handle_where_you_are step handlers with per-step data loaders, plus IMPLEMENTED_STEPS (unbuilt steps fall back to the landing page) and STEPS_REQUIRING_SIGNUP (signup-dependent steps redirect to who_you_are without a session) guards. Shared _error_summary partial renders validation feedback. Email-format and major_code inclusion validations are deferred to 19.4. Tests: 12 new controller tests (27 in file); full suite 4,484 runs, 0 failures.
• Phase 19.1 — Alumni Champions Signup v2.0: Foundation — Lays the scaffolding for a rebuilt public Champion signup flow at alumnichampions.com. New Public::ChampionSignupsController < PublicController lives in the public/ namespace (not the staff champions/ namespace), keeping the audience separation explicit. Domain routing is now properly isolated: a nested constraints block ensures /sign-up routes are only reachable from alumnichampions.com — belmontalum.com/sign-up 404s cleanly. alumnichampions.com/ root overrides the Devise anonymous landing so visitors land on the signup page, not the alumni portal. Schema: 7 new columns on champion_signups — college_code, major_code, industry, job_title, affinity_codes (jsonb, default []), affinity_other, source — plus an index on source for staff filtering in Phase 19.5. Restored config/initializers/champion_signup.rb (admin emails from CHAMPION_SIGNUP_ADMIN_EMAILS env var). Views: Branded _header.html.erb; 4-stage _progress_bar.html.erb; full _landing.html.erb education page with hero, role cards (seals + activity lists), and dual CTAs. Host config: alumnichampions.com, staging.alumnichampions.com, www.alumnichampions.com added to production allowed hosts; alumnichampions.com added to test environment. Tests: 15 runs, 32 assertions, 0 failures.

[1.0.65] - 2026-05-30

Changed

• Phase 18.9 (Group D) — Legacy degree write paths frozen — Degree.writes_frozen? (constant Degree::WRITES_FROZEN = true) now gates every path that created Degree rows. Csv::AlumniImporter.import_degrees is a no-op that returns { created: 0, frozen: true }; Csv::BannerImporter#commit_rows still creates/updates the Alumni record but skips the degree branch (incrementing skipped_degrees); Settings::AlumniController#import_degrees_commit skips both the degree-create and date-repair writes while keeping alumni create/update, and #import_degrees redirects with Degree::FROZEN_MESSAGE. The legacy Degree upload page and Banner import page show amber “frozen” banners pointing to the Educations CRM import. Reads are unaffected — Alumni::EducationProfile still falls back to degrees for alumni without educations rows.
• Phase 18.9 (Groups B + C) — Legacy Degree read path decommissioned; stats and per-record reads frozen onto Education-first sources — The side-by-side ?source=legacy|education stats toggle, the coverage banner, and the aggregate_stats_v2:* cache namespace are all removed. EngagementStats::BaseService, OverviewService, DemographicsService, and ActivityPairsService no longer accept a source: argument — they always read through Education::AggregateScope and cache under engagement_stats_*. StatisticsController and EngagementStatsController dropped @source / education_source? / the legacy branches; EngagementStatsController#calculate_top_alumni_data_optimized now filters college/year via AggregateScope.buid_subquery; the dead fiscal_year_sql helper (referenced degrees.degree_date) was deleted. Both shared/_stats_coverage_banner and shared/_stats_source_toggle partials are deleted. Every per-record alumni.degrees read was migrated to Alumni::EducationProfile or Education::AggregateScope: the engagement-stats alumni tables and alumni/top_engaged (year/degree/college columns), the stats year-filter dropdown, the Champion verification and search-result education snippets, the Champion show page recent-degree block, Cp::CommunityDetectionService (college/major detection + member finders), Cp::Community#eligible_for?, Cp::HomeHelper grad years, Cp::AlumniLikeMeService college/major/year scoring, Csv::AlumniExporter UG/GR classification, Csv::EventRsvpConverter + Tools::EventConverterController enrichment, Champions::CommunitiesController grad year, and LegacyVerificationService#match. The remaining filter joins were also migrated: Alumni.filter_by_name’s year filter, Cp::DirectoryController#load_colleges / #grad_years_by_decade, Cp::CareerConnectService cluster matching, and Cp::CommunityMatchingService.find_matching_champions (college + major) now read through AggregateScope. Data-driven (non-display) reads pass Privacy::NONE to avoid unintended redaction; display reads keep inferred privacy. The EducationProfile→degrees fallback and EducationCoverageService’s raw Degree counts intentionally remain on Degree until the legacy degrees table is dropped under a later cleanup tag (coverage ≥ 99%). Regression test added for find_matching_champions matching an Education-only champion with no Degree row.

Added

• Phase 18.9 — Live progress UI for Education + Areas of Study imports — The Education and Areas of Study CRM import status pages now show a real-time progress bar with running counts, matching the Affinaquest (“Alumni”) import UX, instead of a 5-second <meta refresh> that displayed stale zeroes until the job finished. New education_import_batches.processed_count column tracks rows processed so far. EducationImportBatch#start_scanning!/#start_applying! reset processed_count; new #progress_percent (0–100, capped) and #record_progress! (cheap update_columns write of only the supplied keys) back the poller. Csv::EducationImporter and Csv::EducationAreaOfStudyImporter accept an optional progress: callback threaded through preview and commit_rows, invoked every 200 rows (constant PROGRESS_STRIDE) plus a final exact count. EducationImportScanJob reports scan progress (learns total_rows from the first callback); EducationImportApplyJob sets total_rows to the manifest row count up front and reports created/updated/skipped live. New JSON endpoint GET /settings/alumni/education_import_batches/:id/status (status_education_import_batch) mirrors the Affinaquest status action. A new CSP-safe Stimulus controller (import_progress_controller.js) polls the endpoint (~1.5s), updates the bar/counts, and reloads the page when the batch leaves the in-progress state so the server can render the preview table, results summary, or error. Backed by model tests (progress reset + progress_percent cap + record_progress! selective writes), importer progress-callback tests, and controller status-JSON tests.
• Phase 18.9 — education_areas_of_study.major_code + major filter migrated off Degree — New nullable, indexed major_code column on education_areas_of_study, sourced from the CRM “Area of Study: External Id” field (the program/major code, valid for majors, minors, and concentrations). Csv::EducationAreaOfStudyImporter resolves it by header name (the CRM places “Area of Study: External Id” between the two “Area of Study: Area of Study Name” columns and Contact, so parsing is keyed off header names rather than fixed positions to stay resilient to column ordering), upcases/trims it, surfaces it in the import preview table (new “Major Code” column), persists it on commit, and includes it in the no-op comparison so re-imports stay idempotent. With a stable code now on educations, Alumni.filter_by_major was migrated from the frozen degrees table to match alumni via education_areas_of_study.major_code joined through educations — the alumni search/stats major dropdown (which already passes major_code) now matches directly, no name fuzzing. This was the last read path still on degrees other than the intentional EducationProfile→degrees fallback. Backed by importer tests (External Id → upcased major_code, persistence, no-op re-import, nil when column absent) and filter_by_major model tests (matches major + concentration by code, returns none for unknown code, ignores blank).
• Phase 18.9 (Group A) — Areas of study surfaced on alumni education entries — Alumni::EducationProfile::Entry now carries an areas_of_study collection (new AreaOfStudy value object with name + level) built from each awarded education’s EducationAreaOfStudy rows, plus an areas_of_study_summary helper that renders a grouped, labeled line ordered major → minor → concentration with pluralized labels (e.g. Majors: Music, Marketing • Minor: Spanish • Concentration: Jazz). The summary appears under each education entry on the Lookup alumni profile Degrees card and the Champion Portal directory profile Education card (respecting existing education-privacy redaction). Degree-fallback entries carry no areas of study, so the line only renders for Education-sourced records with area detail. Backed by presenter unit tests covering multi-area grouping, pluralization, level ordering, and the degree-fallback/no-area nil cases.

Added

• Phase 18.8 (deploy 1 of 2) — Per-enrollment student data moved to educations + Csv::CurrentStudentImporter retired — New educations.expected_graduation_year (integer) and educations.student_status (string) columns hold per-enrollment in-progress data so a BS-holder enrolled in an MS shows the MS program independent of the rolled-up alumni.student_status. New Education.in_progress scope (date_issued IS NULL and student_status either NULL or 'pending') is the single source of truth for current enrollment; new Education::ENROLLMENT_COLLEGE_CODE_SQL constant centralizes the COALESCE that resolves an in-progress row’s college code. Alumni#currently_enrolled? (independent of awarded), Alumni#current_student? (currently enrolled AND no awarded degree — the “Almost Alumni” case), and Alumni#current_enrollment_education / current_enrollment_grad_year / current_enrollment_school_code / current_enrollment_program readers all delegate to the new scope. Alumni.currently_enrolled and Alumni.current_students class scopes route through Education.in_progress. The Lookup Portal alumni profile, alumni search results, champion verification page, and Champion Portal profile-wizard “help find you” step all now read from the most recent in-progress education record instead of the denormalized alumni.current_* columns. Csv::EducationImporter now applies the one-way awarded ratchet on alumni.student_status and, when an awarded education row lands, clears the legacy alumni.expected_graduation_year / intended_degree_code / current_program_desc / current_school_code so any lingering readers see a consistent state until those columns are dropped in deploy 2. Csv::CurrentStudentImporter and its entire UI surface (controller, two background jobs, manifest store, batch model, status views, settings nav link, rake task, batch backfill migrations) are deleted in favor of the single CRM-sourced education feed. The alumni.current_school_code / current_program_desc / intended_degree_code / expected_graduation_year columns remain in the schema for this deploy; their drop migration and removal of Csv::AffinaquestContactImporter#clear_enrollment_fields_if_awarded! are deferred to a follow-up deploy after the next CRM import has populated the new educations columns for the live in-progress roster.

Added

• Phase 18.6 — Stats & Engagement Aggregations migration (Education::AggregateScope + side-by-side toggle) — New query object at app/services/education/aggregate_scope.rb is the single source of truth for “Education-first w/ Degree fallback” aggregations. A UNION ALL subquery emits one normalized row per awarded credential (buid, date_issued, degree_code, degree_level derived via CASE in SQL, college_code, major_desc, major_code, source). Per-BUID Education-first wins; Degree branch surfaces only BUIDs with no educations row. Aliased as educations so Education.from(from_clause).where(col: val) qualifies columns correctly. Alumni.with_degrees, without_degrees, filter_by_college, filter_by_fiscal_year, and filter_by_year now all route through AggregateScope.buid_subquery. EngagementStats::BaseService, OverviewService, and DemographicsService accept source: :education | :legacy and switch SQL paths accordingly (legacy uses degrees.degree_date joins; education uses inlined AggregateScope columns). EngagementStatsController and StatisticsController both accept ?source=education|legacy and thread the choice through services, filter forms (hidden field), tab links, and cache eviction. Education path caches under a new aggregate_stats_v2_* namespace; legacy path remains on engagement_stats_* (cache will be collapsed in 18.8). New shared/_stats_coverage_banner and shared/_stats_source_toggle partials render on both /statistics and /engagement_stats for staff parity validation. CP partial sweep: cp/profile_wizard/_step_confirm_education, cp/careers/_career_connect_cards, and the three cp/leadership partials (community, welcome_message, members) now render through Alumni::EducationProfile instead of raw alumni.degrees. Alumni.filter_by_fiscal_year lenient parsing accepts 24, "24", "FY24", and 2024. Backed by 11 parity tests covering UNION shape, per-BUID dedup, college/fiscal-year filters, degree-level buckets, top-major filtering (concentrations/minors excluded), AR-embeddability, and lenient FY parsing.

• Phase 18.5 — Lookup API backwards compatibility + Data Health dashboard — Api::V1::AlumniSearchController#serialize_alumni and the legacy Api::AlumniController#index typeahead now route through Alumni::EducationProfile for all education-derived fields while preserving the V1 response contract (every existing key unchanged). Both endpoints emit a new advisory _source field ("education"

  "degree_fallback"

  "none") so consumers can observe the rollout. New EducationCoverageService exposes education_coverage_pct, legacy_fallback_pct, and a broad unmapped_school_name_count (Education granting schools + Areas-of-Study current institutional units whose code is blank and whose free-text name does not match any colleges.college_name or college_name_short). New internal /api/v1/education_coverage endpoint and admin /settings/data_health dashboard render the same metrics. The dashboard includes an expandable drill-down table of distinct unmapped school names (with occurrence count, source, and a sample BUID/source ID) and a CSV download so the data team can triage them in bulk. Stopgap rake task bin/rails alumni:legacy_fallback_buids prints BUIDs still on legacy degrees (front-end filter for this roster is tracked for Phase 18.7).

• Phase 18.4 — Education read-path compatibility layer (Alumni::EducationProfile) — New presenter at app/services/alumni/education_profile.rb is the single source of truth for derived education data on an Alumni record. Education-first with Degree fallback per alumni: if any Education rows exist, derive from Education + EducationAreaOfStudy; otherwise synthesize from degrees -> majors -> colleges. Exposes value objects (Privacy, Entry, CurrentSchool) and rollup methods (undergraduate, graduate, all_entries, recent, college_codes, major_codes, grad_years, display_summary, to_export_hash). Entry#degree_level is derived at read time via Education.level_for(degree_code) for resilience against fixtures and stale rows. Privacy is auto-inferred from alumni.champion.education_privacy unless an explicit viewer: matches the displayed champion (self-view never redacts). Backed by 23 unit tests + 5 parity tests asserting Degree-sourced vs Education-sourced output is identical for the same data.
• Presenter swap across core paths — Alumni#recent_degree and Alumni#graduation_years now delegate to the presenter; AlumniHelper#generate_checkin_data rewritten to call to_export_hash (single export contract for the event check-in copy button); AlumniHelper#degree_border_color now accepts either a Degree or Entry. Lookup Portal views (alumni/show, alumni/search) and core Champion Portal views (cp/directory/_champion_card, _recommendation_card, cp/directory/show, cp/profile/show) swapped to iterate presenter entries. Matching services (Cp::CommunityMatchingService, Cp::AlumniLikeMeService, Cp::CareerConnectService) read college/major rollups through the presenter. API V1 serializer is unchanged — Entry#as_json preserves the contract ({major_desc, college_name, degree_code, degree_date} with college_name mapped to college_name_short to match the legacy SQL alias). API serializer migration is deferred to Phase 18.5.
• Engagement Breakdown — date ranges, description counts, and progressive disclosure — Each description row on the Engagement Stats Breakdown tab now leads with [YYYY-MM-DD] (or [YYYY-MM-DD – YYYY-MM-DD] when activities span multiple days), pulled from MIN(engagement_date) / MAX(engagement_date). Type headers now include the unique-description count (e.g. Email Click (2,150 alumni • 47 unique descriptions)) so the cardinality of each activity type is visible at a glance. Descriptions are sorted by most-recent date (max_date DESC); the first 25 render inline and a native <details> “Show all N descriptions (X more)” disclosure reveals the rest.

Fixed

• Engagement Breakdown silently truncated description list to 10 rows per activity type — EngagementStats::BreakdownService capped the per-type description list at the top 10 by row count, so for activity types with many distinct descriptions (e.g. event_attended over a full fiscal year) any description beyond the 10th was hidden from the UI. This caused legitimate doubt about whether engagement data was missing from the database. Removed the .limit(10) so all distinct descriptions render. Type-level and level-level unique-alumni counts (which are computed from the full filtered scope, not the descriptions array) were always correct and are unchanged. Added regression test covering 15 distinct descriptions plus min/max date fields and ordering.

[1.0.64] - 2026-05-08

Added

• Phase 18.3 — New CRM education import pipeline (background-job, two-pass) — Two new CSV importers (Csv::EducationImporter, Csv::EducationAreaOfStudyImporter) write to educations and education_areas_of_study with idempotent upserts on (buid, source_education_id) and person_area_of_study_id. Uploads enqueue background jobs (EducationImportScanJob → EducationImportApplyJob) backed by a persistent EducationImportBatch (Zlib-compressed CSV + manifest in DB binary columns, mirroring CurrentStudentImportBatch). The status page polls every 5 seconds while in progress, then shows a preview table and a commit button when scanned. Per-batch gap CSVs are stored on the batch and downloadable for the lifetime of the record. Listed under “Data Imports” (not “Archived Imports”) in the settings sidebar.
• BUID + BQID in education gap CSV exports — Both gap CSV exports (educations and areas of study) now lead with buid, contact_id, … so Advancement Services can cross-reference rows against BruinQuest contact records without a manual lookup. AoS rows resolve BUID/BQID via the parent Education -> Alumni join.
• Soft-school rule for educations — Rows missing a granting school but providing a current school are now allowed (the inverse is also true). Only rows missing both are skipped.
• Skip-reason transparency for areas of study — Skipped AoS rows now surface explicit warnings (filtered out by Degree Includes ≠ 1, missing required field, or missing parent education) instead of being silently dropped.
• Granting-school college seed migration — 20260423090000_seed_granting_school_colleges populates 29 known historical/current college codes so granting-school resolution by alias or colleges.college_name works on first import.
• Concentration-level fallback — EducationAreaOfStudy::CONCENTRATION_LEVELS now includes "unknown". Rows with blank or unrecognized concentrations import as "unknown" and surface in the gap CSV instead of being silently dropped.
• Phase 18.3 tests — 34 new tests (11 educations importer + 5 AoS importer + model + manifest store + scan job + apply job + 12 controller integration) covering create/update/skip mappings, soft-school rule, school resolution, date parsing, idempotency, gap CSV download, batch state transitions, admin-only access, and full async round-trip.
• Phase 18.2 — Education schema foundation — Introduced new educations and education_areas_of_study tables with DB-level foreign key from educations.buid to alumni.buid, idempotency-friendly unique indexes, and Alumni#educations / Alumni#education_areas_of_study associations.
• Education and EducationAreaOfStudy models — Auto-derive degree_level from degree_code and area_of_study_name_normalized from raw text on save; downcase concentration_level; optional College associations for granting/current school codes. 31 model tests added.
• Phase 18 launch guide — docs/planning/qa/PHASE_18_LAUNCH_GUIDE.md with migration checklist, FK behavior notes, sub-phase deployment ordering, and rollback plan.
• Phase 18 sample data placeholder — docs/planning/phases/phase-18/samples/README.md documenting the awarded-degrees and areas-of-study CSV inputs expected before 18.3 import work.

Changed

• Settings alumni nav — upload_degrees page now links out to the new “Educations CRM” and “Areas of Study CRM” import flows alongside the legacy Banner/Degree importers (which remain unchanged in 18.3).
• Test fixture mapping — Added set_fixture_class education_areas_of_study: EducationAreaOfStudy so the unconventional table-name fixture loads correctly.
• Education degree-level taxonomy — Updated Education#degree_level values to use undergraduate, masters, and doctorate (plus unknown fallback), replacing graduate/professional labels.
• Content Security Policy — script_src now allows https://cdn.jsdelivr.net and https://cdnjs.cloudflare.com so importmap-pinned libraries (Flowbite, Chart.js, @kurkle/color, Trix) load without CSP violations. Consolidated duplicate connect_src declaration that was overriding the first.

Fixed

• Engagement Stats refresh button did not actually clear the cache — EngagementStatsController#clear_cache was matching stale glob patterns (engagement_stats_overview_fast_*, breakdown_data_fast_*, etc.) left over from before the EngagementStats::*Service refactor. Current service keys use the prefix engagement_stats_<service>_… (no _fast_ segment), so the button updated the “last updated” timestamp but never evicted any cached data — stale stats stayed live until the 1-hour TTL expired. Replaced the patterns with anchored regexes (/\Aengagement_stats_/ and /\Atop_alumni_data_fast_/) that match the actual service-written and legacy controller-written keys, and added a regression test that writes representative keys, hits the endpoint, and asserts they’re evicted while unrelated keys survive. Also: MemoryStore#delete_matched (used in production) expects a Regexp, not a glob — passing globs silently coerced * to “zero or more underscores”.
• Education import commit page did not auto-refresh — Clicking “Commit Import” enqueued the apply job but redirected to a page still showing the scanned state, so the meta-refresh wasn’t rendered and the Commit button stayed visible. A second click then tripped the “Batch is not ready for commit (status: completed)” guard. The controller now flips the batch to running before enqueueing the apply job (the job’s own start_applying! is idempotent), and an in-progress/completed batch returns a friendly notice instead of an alarming alert.

[1.0.63] - 2026-04-20

Added

• Staff user onboarding password visibility — Settings user edit pages now show a read-only “Initial Temporary Password” field to admins while the account still uses that initial password.

Changed

• User creation onboarding flow — Creating a staff user now stores the initial temporary password for admin reference, sends Devise reset-password instructions automatically, and clears the stored temporary password as soon as the user changes their password.

Fixed

• Settings delete buttons under Turbo — Updated settings index delete links to use Turbo-compatible data-turbo-method and data-turbo-confirm attributes so delete actions consistently execute.

[1.0.62] - 2026-04-20

Added

• “Has Engagement Activity” filter — Alumni search now includes a checkbox to filter alumni who have engagement activity records. Added to controller params, AlumniFilterService, and search view.
• New-grads redirect — /new-grads on all Alumni Portal domains now 301 redirects to belmont.edu/alumni/new-grads.

Changed

• Documentation audit & cleanup — Comprehensive review of all planning docs to reflect current project state (all 17 phases complete):
  • AI Context Bundle (AI_00–AI_08): Updated dates to April 2026; Phase 6 → Complete, Phase 17 → Complete with full sub-phase details; phase count references updated from 15 to 17.
  • STAKEHOLDER-OVERVIEW: Version 5.0; added Phases 16 & 17 to roadmap table; Phase 6 status corrected from “Deferred” to “Complete”; dates and footer updated.
  • JOBS-TO-BE-DONE: Version 5.0; Phase 13 references updated from planned (📋) to delivered (✅) for jobs C5, C10, C11, C12; Phase 6 references updated; remaining opportunity table trimmed to true backlog items only; Phase 13 section rewritten from future to past tense.
  • Phases README: Added Phases 16 & 17; Phase 6 status corrected; phase count updated to 17.
  • Features README & 08-REPORTING: Updated Phase 6 status from “Deferred” to “Partially Complete” (6.1 delivered, 6.2/6.3 in Backlog).
  • BACKLOG: Staff reporting entry updated to reflect what’s already delivered vs. remaining.
  • Champion Portal README: Status line updated to “All 17 phases complete”.
  • Phase 6 README: Status changed from “Deferred” to “Complete” with details on what was delivered vs. moved to Backlog.
  • Roadmap controller: Phase 6 status → :complete; sub-phases 6.2/6.3 → :backlog.

Removed

• Event check-in integration planning docs — Removed docs/planning/event-checkin-integration/ (7 files). These planning docs for the standalone alumni_events app are no longer needed in this repository.

[1.0.61] - 2026-04-03

Added

• PWA back navigation system — Contextual “← Back to X” links now auto-render in all three layouts (Alumni Network, Staff Portal, Champion Admin) via BackNavigationHelper. Maps ~50 controller/action combos to logical parent pages (iOS-style predictable navigation). Replaces 31 hand-coded inline render 'shared/back_link' calls with a single layout-level helper. Public/unauthenticated views suppress the back link via content_for(:hide_back_link). Views can override via content_for(:back_link_path) + content_for(:back_link_text).

Fixed

• CRM changes page excluded import-sourced records — The /settings/affinaquest/crm_changes page was showing records from Affinaquest imports (recency conflicts) alongside app-originated changes. These import records already came from the CRM and shouldn’t be flagged for export back. Added app_originated scope to CrmDataChange; applied to listing, export CSV, mark-exported, action item badge count, and CrmDataExportBatch.export_all_pending!. Import records are still created for field protection tracking — they just no longer appear on the export page.

Changed

• IP ownership resolved — Updated LEGAL_REVIEW.md and Terms of Service draft to reflect agreement reached with Belmont legal team (April 2026): Chip retains IP rights; Belmont has indefinite royalty-free use; future monetization to be discussed with ~50/50 development-time split as starting point. Outstanding Gaps item #7 narrowed to domain ownership only.

[1.0.60] - 2026-03-28

Added

• Phase 17.4: Staff Management & Data Catalog — Verified to_champion_attributes field mapping (9 fields), added legacy data notice to staff signups index, updated CHAMPION_SIGNUP_SYSTEM.md with retirement notice and field mapping table.
• Phase 17.3: Legacy Signup Flow Retirement — Removed public /signups/* multi-step wizard (controller, views, mailer, initializer, rake task, tests). Replaced with 301 redirects to /champions. Preserved: ChampionSignup model, staff management interface, data conversion pipeline in ConfirmationsController, SVG partials used by staff views. 2 redirect tests added.
• Phase 17.2: Generic Landing Page Refresh — Updated / landing page with two-tier messaging. Replaced abstract pillars (Belong/Gather/Inspire) with concrete feature cards (Alumni Directory, Communities, Events, Conversations). Added “For Alumni Who Want to Do More” Champions teaser section linking to /champions. Removed inline footer (layout footer handles it). 10 tests, 22 assertions.
• Phase 17.1: Public Champions Landing Page — New public page at /champions serving as the redirect target for alumnichampions.com. Educates anonymous visitors about the Alumni Champions program with adapted content from the authenticated /champion-info page. Includes hero, three engagement tiers (Member/Champion/Community Leader), four role cards (informational only), benefits, social proof stats, How It Works, and signup/signin CTAs. Social proof counts true Champions (role selected) not just verified portal members. OG meta tags for social sharing. 10 tests, 26 assertions.
  • Cp::ChampionsLandingController — extends ApplicationController (public, no auth), redirects signed-in users to /champion-info
  • GET /champions route in public scope (between policy routes and authenticated routes)
  • Documented Cp::Champion model naming caveat: model represents all portal members, true Champions have primary_role present

[1.0.59] - 2026-03-27

Added

• Import cancel button: Cancel buttons on all scanning and processing pages for both Affinaquest and Current Student imports. Marks batch as “Cancelled by user” and background jobs check at chunk boundaries (every 500 records) and stop cleanly. Guards on scan_complete! and complete! prevent a finishing job from overwriting a cancelled status.

Changed

• Manifest storage moved from Redis to PostgreSQL: Import manifests (Affinaquest and Current Student) are now stored as Zlib-compressed binary in a manifest_data column on the batch tables instead of Redis. Eliminates Redis OOM on large CSV imports — the 50k-row Affinaquest import no longer needs Redis capacity for manifest storage. Redis is now reserved for Sidekiq and Action Cable only.
• CSV content stored in database instead of Sidekiq args: Upload controllers now store the CSV file content (Zlib-compressed) in a csv_content column on the batch record, passing only the batch ID to scan jobs. Previously the full CSV string (~8MB for 49k rows) was passed as a Sidekiq job argument through Redis, causing OOM before the scan even started.
• Chunked apply phase: apply_manifest_to_batch now processes changes in 500-record chunks instead of loading all records and alumni into memory at once. Per-chunk alumni preloads, key transforms, and GC runs keep worker memory under 512MB for 49k-row imports.
• Commit actions no longer load manifest: Both Affinaquest and Current Student commit controller actions now use batch stats from the scan phase instead of loading the full manifest synchronously — eliminates H12 (30-second timeout) errors on large imports.

Fixed

• Current Student processing page double-count: Counters on the processing page showed double values because start! didn’t reset stats from scan preview. Both start! methods now reset all counters to 0 before the apply phase begins.
• Worker memory not released after import: Ruby’s memory allocator holds freed pages after large imports, keeping worker at peak memory (~500MB) indefinitely. Added GC.start(full_mark: true) + GC.compact after all scan/apply jobs complete, and csv_content cleanup in apply jobs. Set MALLOC_ARENA_MAX=2 on both staging and production to reduce glibc arena fragmentation.
• Affinaquest false-positive “To Update” on re-import: Re-importing the same CSV showed thousands of phantom updates with “No field changes.” Rows with only recency conflicts (no actual field changes) were being marked :update instead of :skip. Fixed by checking fields_to_update.empty? only, ignoring recency conflicts for the action decision.
• Current Student false-positive “To Update” on re-import: Same category of bug — rows where all 3 enrollment fields matched were still marked :update with an empty changes hash. Now builds changes hash first, checks if empty, and returns :skip before marking :update.

---

[1.0.58] - 2026-03-24

Fixed

• Redis OOM on large CSV imports: Zlib-compress manifest data before storing in Redis. A 7.8MB CSV was triggering OOM on Heroku Redis Mini (25MB). JSON manifests compress 5-10x, bringing ~20MB manifests down to ~2-3MB. Backward-compatible fetch handles both compressed and legacy data.

---

[1.0.57] - 2026-03-24

Added

• Current Students: Create-if-not-found: Current Student importer now creates new Alumni records for students not found in the database, instead of skipping them
  • New created_count column on current_student_import_batches (migration)
  • create_alumni_from_row builds records with BUID, names, enrollment fields, birthdate, and contact info (zip, phone, emails, maiden name)
  • Preview page shows “New Students to Create” table with green card; results page shows “Created” count
  • Duplicate-safe: existence check at apply time prevents double-creates between scan and apply
  • increment_created!, updated complete!, scan_complete!, total_processed, summary on batch model
• Affinaquest: Birthdate import: Affinaquest Contact importer now maps birthdate, date_of_birth, and dob CSV columns with recency-aware updates and US-format date parsing
• Current Students: Contact field import: Current Student importer now imports maiden name, zip, phone/mobile, email fields, and last modified date — fills in blanks without overwriting existing data on updates; populates fully on creates
• Stats: Population segmentation: Engagement stats dashboard differentiates degreed alumni, non-degreed alumni, and current students with population breakdown card and generation table columns
• Sidebar: Archived imports section: Settings sidebar now separates primary imports (Alumni Contacts, Current Students, Engagement Activities) from archived imports (Alumni Banner) for clearer workflow guidance

Fixed

• Stats: Blank college names: build_alumni_per_college now uses preloaded College.pluck hash instead of .group().count which produced flat hash keys
• Stats: Import count discrepancy: current_students scope updated to include NULL expected_graduation_year records (5,442 → 7,646)
• Birthdate import parsing: Date.parse misinterpreted MM/DD/YYYY as DD/MM/YYYY — now uses Date.strptime("%m/%d/%Y") first with fallback

---

[1.0.56] - 2026-03-17

Added

• Engagement Activity Group Filtering & Bulk Delete: Filter engagement activities by group (Giving, Events, Digital, Leadership, Campus) and description text on the settings page, with bulk delete for filtered results
  • Code-defined ACTIVITY_GROUPS constant on EngagementType — no migration needed
  • Filter bar with group dropdown and description search on Settings > Engagement Activities
  • Bulk delete action with confirmation dialog showing filtered record count
  • New delete_filtered route and controller action
• Population Filter for Engagement Stats: Stats now default to degreed alumni only, with optional inclusion of non-degreed alumni and current students
  • Three-checkbox filter (Degreed Alumni, Non-Degreed Alumni, Current Students) on engagement stats dashboard
  • apply_population_filter in AlumniFilterService using SQL UNION for structurally incompatible scopes
  • Population selection persisted in session across tab navigation
  • Threaded through all 7 stats services (Overview, Analytics, Breakdown, Demographics, Matrix, ActivityPairs, DiscussionBoards) and cache keys
• Batch Engagement API (POST /api/v1/engagements/batch): External systems (e.g., alumni_events) can batch-record engagement activities via API. Idempotent via event_identifier — safe to re-submit.
• EngagementBatchLog model: Tracks processed batch syncs for idempotency, with API key tracking and error detail logging.

---

[1.0.55] - 2026-03-07

Fixed

• Welcome Home Bruin email spacing: Converted feature grid from flex/gap layout to table-based layout for email client compatibility (Gmail, Outlook)
• Auto-verified admin notification CTA: Admin email now links to champion profile instead of verification queue for auto-verified users
• NotifyAdminsJob user query: Fixed query to match can_portal_admin users, not just role: portal_admin

Added

• Auto-verified Welcome Home email: Champions auto-verified via legacy signup or alumni email match now receive the “Welcome Home, Bruin” notification email
• Auto-verified admin notifications: In-app and web push notifications for admins now reflect auto-verified status with distinct title, body, and profile URL

---

[1.0.54] - 2026-03-06

Added

• Phase 16.5 — Security Headers: Comprehensive browser security headers to harden against XSS, clickjacking, and information leakage
  • Content Security Policy in report-only mode: default-src 'self', Google Fonts whitelisted, unsafe_inline for Tailwind CSS, Google OAuth and Apple Sign-In in form_action, nonce generation enabled
  • Permissions-Policy via apply_permissions_policy before_action: camera, microphone, geolocation, payment, USB, gyroscope, magnetometer, accelerometer, MIDI, autoplay, picture-in-picture set to :none; fullscreen to :self
  • Referrer-Policy header (strict-origin-when-cross-origin) added to production environment
  • HSTS already provided by existing config.force_ssl = true
  • 11 new integration tests in test/integration/security_headers_test.rb
• Phase 16.2 — Education Privacy Controls: Three-level education privacy enum (education_show_all, education_hide_year, education_hidden) with privacy enforcement across directory, profile, career connect, and champion card views
  • Directory search excludes education-hidden alumni from college/degree filters and education-hide-year from graduation year filters
  • AlumniLikeMeService skips education scoring for privacy-restricted alumni
  • CareerConnectService excludes deleted and education-hidden alumni from career matches
  • Profile view shows privacy indicator badges for self-view (“Hidden from others” / “Year hidden from others”)
  • Privacy settings radio buttons in Settings > Privacy section
• Phase 16.3 — Account Deletion & Data Export: True account deletion with PII clearing and data export capability
  • AccountDeletionService: Soft-delete workflow — clears 30+ PII fields, anonymizes discussion posts to “Former Member”, nullifies associations, sends confirmation email
  • DataExportService: Generates JSON export of all personal data (profile, education, communities, connections, activity history, privacy settings)
  • Confirmation page requiring user to type “CONFIRM” before deletion
  • Download My Data button with 24-hour rate limiting via activity events
  • Post-deletion confirmation email sent to original address
  • active and deleted scopes on Cp::Champion model
• Phase 16.4 — CAN-SPAM Email Compliance: Full CAN-SPAM compliance across all 27+ email templates
  • Cp::CanSpamHeaders concern adds List-Unsubscribe and List-Unsubscribe-Post headers to 7 non-transactional mailers
  • Shared text footer partial (shared/email/_text_footer.text.erb) with physical address, unsubscribe link, and reason text
  • HTML branded footer updated with “or unsubscribe” link
  • All 27 text email templates updated to use shared footer (transactional emails marked appropriately)
• Phase 16.6 — Age Attestation: Age confirmation checkbox at registration
  • Virtual age_confirmed attribute with acceptance validation on create
  • age_confirmed_at timestamp recorded on successful registration
  • OAuth registrations exempt via existing skip_consent_validation?
• New activity event types: education_privacy_updated, account_deleted, data_exported

Removed

• Deprecated /dashboard in favor of /home: Removed the legacy DashboardController and all its views; /dashboard now redirects to /home
  • Moved 4 shared partials (_community_notifications, _invited_community, _role_card, _role_card_ideas) from cp/dashboard/ to cp/home/
  • Moved refresh_role_ideas action and turbo stream template to HomeController (route: POST /home/refresh_role_ideas, same helper cp_refresh_role_ideas_path)
  • Updated 14 render calls across 5 stage partials to reference new partial locations
  • GET /dashboard now returns 301 redirect to /home (preserves bookmarks)
  • Deleted DashboardController (337 lines) and show.html.erb (878 lines)
  • Removed inert progressive_dashboard feature flag from all 3 environment configs
  • Updated tests: renamed dashboard_role_card_test → home_role_card_test, updated backward-compat tests to assert redirect

Added

• Role Idea CTA Click Tracking: End-to-end click tracking for role idea and contextual prompt CTA buttons on the Champion dashboard
  • track_click_controller.js Stimulus controller fires non-blocking POST via fetch with keepalive: true
  • Cp::RoleIdeaClicksController endpoint records clicked_role_idea_cta and clicked_contextual_cta activity events
  • New clicked_contextual_cta event type in Cp::ActivityEvent
  • Analytics page (champions/insights/role_ideas) updated with tabbed layout (Role Ideas / Contextual Prompts), hide-zeros toggle, role attribution for contextual prompts
  • insights_tabs_controller.js Stimulus controller for tab switching and zero-row filtering

Fixed

• Turbo Drive navigation error on contextual prompts: Changed community.id to community.slug in ContextualPromptGenerator CTA routes to avoid 301 redirects that Turbo couldn’t follow
• OAuth registration bypassing consent checkboxes: Google/Apple/Facebook OAuth registrations now require age confirmation via the re-consent flow. Added needs_age_confirmation? method to Cp::Champion that detects OAuth users without age_confirmed_at, and updated check_policy_consent to redirect these users to the consent page with an age confirmation checkbox.
• Data export crash on communities with no role column: Fixed NoMethodError: undefined method 'role' in DataExportService#community_data by replacing role with membership_type (based on primary flag).
• OAuth sign-in “Invalid wizard step” error: Fixed next_incomplete_wizard_step returning non-existent "privacy" step. Now returns nil when all wizard steps are complete (even if wizard_completed_at not formally set). Updated after_sign_in_path_for in session/OAuth controllers to auto-complete wizard when no steps remain.

Added

• Phase 16.1 — Legal Policy Pages & Consent Flow: Full implementation of in-app legal policy infrastructure covering all four policy pages, versioned consent tracking at registration, and re-consent mechanism for policy updates.
  • Policy pages served publicly at /terms, /privacy, /community-guidelines, /cookies (converted from docs/compliance/drafts/ with internal cross-links resolved to in-app routes)
  • cp_policy_acceptances table: Audit trail recording champion ID, policy type, version, acceptance timestamp, and IP address
  • Cp::PolicyVersion model: Central config with CURRENT_TERMS / CURRENT_PRIVACY version constants; consent_current? and stale_policies class methods drive the re-consent check
  • Cp::PolicyAcceptance model: Immutable audit record with validations; record_for_champion! creates acceptance entries
  • Registration consent checkbox: ToS + Privacy Policy required at registration (virtual terms_accepted attribute validated on create; OAuth registrations exempt via skip_consent_validation?)
  • Consent columns on cp_champions: terms_accepted_at, terms_version, privacy_accepted_at, privacy_version capture last-accepted version and timestamp
  • Re-consent flow (Cp::ConsentController): check_policy_consent before-action in Cp::BaseController redirects stale champions to /consent; acceptance records both policies and resumes intended destination
  • Activity event tracking: policy_consent_updated event type added to Cp::ActivityEvent
  • Footer links: All four policy pages linked in champion portal footer (Terms, Privacy, Community Guidelines, Cookies)
  • Tests: 37 new targeted tests — 8 policies controller, 12 consent controller, 9 policy acceptance model, 8 policy version model — plus 16 consent-related assertions added to existing champion model tests, and updated registration/dashboard/home/boards controller tests to satisfy consent requirements in fixtures

[1.0.53] - 2026-03-05

Added

• Legal Review Document (docs/compliance/LEGAL_REVIEW.md): Comprehensive 26-section pre-launch legal assessment covering data collection, user consent, privacy controls, FERPA/COPPA, CAN-SPAM, third-party services, and 18 outstanding gaps. Updated to reflect Phase 16 implementation status — 6 gaps marked complete.
• IT Security Review Document (docs/compliance/IT_SECURITY_REVIEW.md): Full security assessment covering authentication, encryption, rate limiting, session security, headers, and deployment. CSP (#1) and security headers (#4) recommendations marked implemented via Phase 16.5.
• Terms of Service Draft (docs/compliance/drafts/TERMS_OF_SERVICE.md): Full ToS draft ready for legal review. 18+ age requirement, connection-gated messaging, UGC licensing, governing law (Tennessee). 2 items flagged for legal input.
• Privacy Policy Draft (docs/compliance/drafts/PRIVACY_POLICY.md): Full Privacy Policy draft ready for legal review. Covers data collection, retention, deletion (30-day commitment), user rights, 18+ minimum age. 1 item flagged for legal input.
• Community Guidelines Draft (docs/compliance/drafts/COMMUNITY_GUIDELINES.md): Full Community Guidelines draft with expected behavior, prohibited content, connection-gated messaging rules, moderation process, and appeals.
• Cookie Policy Draft (docs/compliance/drafts/COOKIE_POLICY.md): Cookie Policy documenting single essential session cookie; confirms no analytics/tracking cookies in use.
• Phase 16 Spec (docs/planning/phases/phase-16/README.md): Full implementation spec for 6 compliance sub-phases (16.1 policy pages + consent, 16.2 education privacy, 16.3 account deletion + export, 16.4 CAN-SPAM, 16.5 security headers, 16.6 age attestation). Includes cross-document link table and traceability matrix.

Changed

• Roadmap: Phase 16 Added (app/controllers/champions/roadmap_controller.rb): Phase 16 — Legal & IT Compliance added with all 6 sub-phases; status: planned.
• Messaging System Docs: Corrected all references to reflect connection-gated messaging (Phase 10.3). Removed “Connections only” as a separate enum value (redundant), corrected “Disabled” → “Nobody” in MESSAGING_SYSTEM.md and compliance docs. Privacy levels now correctly documented as anyone / limited / nobody.
• Age Requirement: Updated to 18+ throughout all compliance docs and Phase 16 spec. Eliminates all COPPA concerns by design.
• alumnilookup.com removed from public-facing docs: Internal staff portal domain withheld from ToS and Privacy Policy. Retained in internal IT/Legal review documents.
• Insights Navigation & Naming: Champion Program sidebar now routes to the new Insights overview at /champions/insights; legacy Role Ideas page now redirects into Insights.
• Role Ideas Analytics: Added dedicated Insights role ideas view and associated metrics plumbing for seeded-question and role-idea activity reporting.
• Registration Bot Protection: Alumni registration now records and validates a hidden honeypot field to reduce automated spam signups.

Changed

• Commit Workflow: Documentation Review: Added mandatory pre-commit documentation review checklist to /deploy skill, copilot-instructions.md, and CLAUDE.md. Ensures docs stay current during ad-hoc feature/bugfix work (not just phase wraps).

Fixed

• News Card Routing: Compact news cards now always route through the canonical news post page rather than a stale direct path.
• Seeded Question Preview/Show Stability: Fixed seeded question preview and show flow issues that could surface broken or inconsistent preview behavior.
• Onboarding Metrics Naming: Insights metrics naming now consistently uses “alumni” terminology in place of legacy “champion” labels where appropriate.

[1.0.52] - 2026-03-04

Added

• Profession Step: Employment Status: Profile wizard profession step now collects employment status with a new field; progress bar spacing tightened.

Fixed

• District Sidebar: State in Name: District now displays as “City, ST” format (using display_name) instead of bare city name.
• District Sidebar: “Find Fellow Alumni” Link: Fixed broken directory filter link — was passing district: (slug param) with an ID value; corrected to district_id: so the search actually filters by district.
• Belmont Stories Import Hardened: Import task made more resilient against edge-case failures.
• Safari Add to Home Screen: Fixed Safari PWA shortcut opening /dashboard instead of root; now correctly routes to /home.

Changed

• Docs: Updated STAKEHOLDER-OVERVIEW for Higher Ed context; reconciled phase completion status across all spec docs; marked Phase 15 (Design Consistency Pass) complete.

[1.0.51] - 2026-03-02

Added

• Email Columns in Alumni CSV Export: Added five email columns (email, email_school, email_personal, email_business, email_other) to the alumni search CSV export. The email column uses a best-email fallback: stored email first, then school email (current students only), then personal, business, and other.
• Current Student Filter Checkbox: New standalone checkbox filter on the alumni search page to limit results to current students (previously buried in the champion filter dropdown).
• Has Alumni Network Account Filter Checkbox: New checkbox filter to limit alumni search results to those who have created an Alumni Network (Champion Portal) account.

Changed

• Alumni Champion Filter Dropdown: Removed “Show Current Students” option from the dropdown; it is now a dedicated checkbox above the submit button.

[1.0.50] - 2026-03-02

Added

• Legacy Verification Tool: New staff tool at /tools/legacy_verification for processing Admissions legacy CSV files. Extracts relative names and relationships from free-text “Legacy Details” column, matches against alumni database using multi-strategy search (direct, middle-name maiden fallback, applicant-last-name fallback, geographic, fuzzy), and exports results CSV with confirmation status and matched BUIDs.
• LegacyDetailParser: Service that parses 18+ free-text formats including “Name - Relationship”, reversed “Relationship - Name”, slash/comma/colon/”and” delimiters, parenthetical relationships, multi-dash noisy entries, and free-form sentences.
• Middle-Name Maiden-Name Matching: 3-part names (e.g., “Dawn Nolan Klein”) now try middle components as alternate last names, correctly resolving married-name cases to the alumni’s maiden-name record.
• Connections Education: Empty-state connections card explains request/accept/message flow; dismissable “How Connections Work” banner on the Directory index page for first-time visitors.
• Start Exploring Escape Hatch: Adds ready_to_explore_at milestone and /home/start_exploring action so alumni in profile_building stage can advance when only optional profile items remain.

Changed

• Champion Role Education: Dashboard role discovery card (State A) reworded with clearer educational/invitational copy; role-specific concise descriptions added for all four role paths; CTA language updated.
• Champions Header Spacing: Tightened desktop nav container alignment and reduced horizontal padding on nav links and user menu for cleaner layout consistency.

Fixed

• Email Templates Unified: Overhauled champion and admin mailers with shared branding, dark-mode-safe styles, and correct staff-vs-alumni URL routing (lookup-domain links for admin actions).
• Verification Resend Tools: Portal-admin verification UI adds actions to resend confirmation emails and update email-address-then-resend before champion confirms account.

[1.0.49] - 2026-02-28

Changed

• Role Icons Replace Emoji: Replaced all role emoji across /champion-info, /roles, /roles/:role, quiz results, profile wizard role step, and microsite nav with inline SVG role icons (hexagonal badges) and seals (circular badges with role name). Icons render directly without circle wrappers for proper sizing. Seals used in standalone/hero contexts. Added role_seal_svg helper to ApplicationHelper. Documented icon vs seal usage rules in DESIGN-GUIDELINES.md.
• Connections Preferences Simplified: Replaced the previous multi-option scope matrix with a simpler All Alumni & Almost Alumni vs Limit Who Can Contact Me mode in both profile wizard and settings. Limited mode now uses 3 explicit restriction checkboxes (communities, city, almost alumni).
• Connections UI Interactivity: Added Stimulus contact_mode_controller so mode switching updates card highlighting in real time and disables limited-mode checkboxes when All Alumni is selected.
• Wizard Completion Destination: Profile wizard completion now redirects to home (/home) instead of profile, with tests updated to match.

Fixed

• Canonical Slug Redirects: Fixed canonical slug redirect behavior for slugged routes to avoid incorrect path handling.
• Verification Show Redirect Loop: Prevented no-op 301 redirects in Champions::VerificationsController#show when a champion record still uses numeric to_param, restoring 200 responses for verification detail views while preserving canonical slug redirects for slugged records.

[1.0.48] - 2026-02-28

Added

• Import Review Workflow: Imported Belmont Stories appear in Content Submissions “Imported” tab with count badge, bulk Publish Selected / Publish All actions, and per-item Review page with Publish, Edit & Publish (promote to draft), and Dismiss (soft-decline) actions; 6 new routes, 7 controller actions, 17 new tests
• Belmont Stories Rake Verbose Output: belmont_stories:import task now prints structured per-item results (imported/skipped/backfilled/failed) with quiet mode (QUIET=1) for scheduled runs; 3 rake task tests

Fixed

• Belmont Stories Date Parsing: NBSP and other Unicode whitespace characters in scraped dates no longer break Date.strptime; added normalize_date_text with multi-format fallback and backfill for existing posts missing published_at; 3 new scraper tests

Changed

• Activity Feed Section Limits: items_for_sections method replaces items(limit:) — applies independent per-section max/min (news: 4, discussion: 3, photo_album: 4) for balanced home page content; 2 new service tests
• Home Feed Defaults: News default bumped from 3→4, photo_album from 3→4

[1.0.47] - 2026-02-27

Changed — Phase 13 Completion: Root Route & Dashboard Polish

• Root route switched to /home: Authenticated root now always points to Cp::HomeController#show; removed progressive_dashboard feature flag conditional from config/routes.rb; all cp_dashboard_path references (70+) updated to cp_home_path across 20 controllers, 10 views, 3 layouts, 12 test files; /dashboard route preserved for backward compatibility
• Header/footer/mobile nav: Logo links updated from /dashboard to /home
• Back links: All “Back to Dashboard” → “Back to Home” across help, invites, events, news, submissions, feedback, discussions, photo albums
• Communities card: “N suggested” integrated as body row instead of header badge; plus icon + chevron linking to communities index
• Champion Role card colors: Dynamic role_color (fountainblue, skyblue, belmontblue, belmontred) replaces hardcoded amber for contextual prompt borders, backgrounds, icons, badges, and CTA buttons
• Activity feed thumbnails: Discussion items now show thumbnails when image available (matching news card layout); photo album resolution increased to 320×320
• Discover Communities: Join/X button layout for suggested communities in exploring stage and communities index (Turbo Stream dismiss)
• Find Your Champion Role: State A converted to _primary card partial
• District card: Icon changed from circle to MapPin SVG
• Your Impact card: Changed from _compact to _standard card with bar chart icon

Fixed

• Turbo frame content missing: Added target="_top" to lazy-recommendations turbo-frame elements in engaging, champion, and community_leader stages; added data-turbo-frame: "_top" to career resources link — fixes Career Resources and Alumni You Might Know sections disappearing on click
• News index route error: Fixed NoMethodError for undefined cp_community_news_index_path → cp_community_path(community, anchor: "news")

Added — Phase 13.8: Freshness, Signals & Milestones

• “What’s New” Summary Bar (app/views/cp/home/_whats_new_bar.html.erb): Compact bar below hero showing counts of new content (discussions, articles, events, photo albums) since last dashboard visit; click-through links to each content index; human-friendly “since” labels (earlier today, yesterday, day name, date); hidden on first visit or when nothing new
• Milestone Celebrations (app/services/cp/milestone_service.rb, app/models/cp/milestone.rb): 8 milestone types (first_community, profile_complete, first_connection, first_post, champion_opt_in, one_year_anniversary, ten_connections, community_leader); auto-detection on dashboard load; unique per champion; celebration banner with warm copy; max 1 per visit; auto-dismiss after display; milestone_achieved activity event tracking
• Migration create_cp_milestones: New table with champion_id, milestone_type (integer enum), achieved_at, displayed_at; unique index on (champion_id, milestone_type)
• Connections Sidebar Redesign (app/views/cp/home/sidebar/_connections.html.erb): Shows connected people (photo, name, “View” link to profile) instead of message threads; progress indicator for <3 connections; empty state “Meet a fellow alum” with directory link
• Community Activity Badge Labels (app/views/cp/home/sidebar/_communities.html.erb): Per-community colored badges showing new post counts (blue) and upcoming event counts (amber); tooltips with counts; icons on desktop, hidden labels on mobile; batch-loaded via controller to avoid N+1
• Role Card Visibility Expansion: Champion role card now visible from exploring stage onward (was champion+); added to _exploring.html.erb and _engaging.html.erb stage partials
• 1 new activity event type: milestone_achieved
• 29+ new tests: 5 milestone model tests + 16 milestone service tests + 2 HomeController what’s new tests + 2 connections sidebar view tests + 4 dashboard helper label tests

Added — Phase 13.7: Champion Nudge Engine & Role Microsite

• Champion Discovery Page (/champion-info): Educational “What & Why” page with warm, zero-pressure tone; 3 sections (What is a Champion, Three Engagement Tiers, What Changes When You Opt In); conditional CTA (has role: summary card → role detail; no role: Explore Roles + quiz link); canonical source language from identity statement
• Champion Role Microsite — 3-page cohesive experience with shared navigation:
  • /champion-info — Educational overview (What & Why), no inline role management
  • /roles — Explore & Choose page with rich role cards, direct “Choose this role” selection, quiz CTA
  • /roles/:role — Role detail + management (retake quiz, change role, remove role with confirmation)
  • Shared tab navigation partial (_champion_microsite_nav.html.erb) across all 3 pages
  • Consistent max-w-3xl container with standardized padding across all pages
• Route consolidation: Removed duplicate champion-info/select-role and champion-info/remove-role endpoints; added DELETE /roles/remove to RolesController; all entry points updated (dashboard role card → /roles/:role, profile show → /roles/:role, wizard referrers → role detail, nudge “Learn More” → /roles)
• ChampionNudgeEngine service (app/services/cp/champion_nudge_engine.rb): 5 trigger definitions (content_submitted ≥1, active_discussant ≥3 comments, active_connector ≥5 connections, profile_complete ≥100%, community_active ≥2 posts); JSONB-based impression tracking via seen_tooltips; max 3 impressions before auto-suppression; permanent opt-out after 3 dismissals
• Dashboard nudge card (app/views/cp/home/_champion_nudge.html.erb): Amber-accented inline card on engaged_member stage with dual CTAs (Find Your Role → quiz, Learn More → roles page) and session dismiss; turbo-frame wrapped for clean removal
• Post-action inline nudges: Flash-style amber bar in champions layout after news submissions, event submissions, and 3+ discussion comments; set_champion_nudge_flash helper in base controller; only shown to Tier 1 Members (not Champions or CLs)
• Nudge dismiss controller (app/controllers/cp/nudges_controller.rb): Session dismiss and permanent suppress actions with activity tracking
• 7 new activity event types: viewed_champion_info, nudge_shown, nudge_dismissed, nudge_clicked_quiz, nudge_clicked_learn_more, role_changed, role_removed
• 34+ new tests: 14 service tests (nudge engine) + 12 champion info controller tests + 9 roles controller tests (remove_role, management, nav)

Added — Phase 13.5: Tier 2 — Champion Experience

• ContextualPromptGenerator service (app/services/cp/contextual_prompt_generator.rb): Role-aware, data-driven prompt generation from live community data; 8 generator methods (new members, unconnected alumni, quiet communities, albums needing photos, unanswered discussions, quiet led communities, upcoming events, low-visibility events); dismissal tracking via seen_tooltips JSONB
• Contextual prompt rendering: Role card ideas partial accepts contextual prompts, renders with amber “Now” pulse badge; fills remaining slots with static ideas (total 3)
• resolve_contextual_cta_route helper: Resolves string-format route references (e.g., "cp_community_path:123") to actual URLs
• Alumni Champion SVG icon badge: Inline hexagonal champion icon rendered next to names in directory cards, discussion posts, discussion comments, and profile pages; tooltip shows specific role title; sizes: sm (16px) and md (20px)
• Role ideas in digest emails: Daily and weekly digest templates include “Your Idea for Today” / “Your Champion Idea” section with emoji, title, body, and CTA button; loaded via RoleIdeaPackService

Added — Phase 13.6: Tier 3 — Community Leader Experience

• New Members to Welcome (app/views/cp/home/stages/_new_members_to_welcome.html.erb): CL-specific partial showing recent members (14 days) who haven’t been welcomed yet; avatar, name, community, “Say Hello” CTA; welcome tracking via cl_welcome_sent activity events
• Community Leader stage integration: New members section rendered in _community_leader.html.erb after community health card

Fixed

• Discussion badges: Added champion icon badge to community board post views (boards/show.html.erb, boards/_comment.html.erb) — previously only added to global discussion views
• Tailwind JIT purging: Replaced dynamic Tailwind class interpolation (bg-#{color}/10) with explicit ROLE_BADGE_CLASSES class map to prevent build-time purging
• Weekly digest test: Fixed timing-sensitive fixture collision where 30.days.ago event fixture coincided with travel_to date, causing false positive email sends
• Digest email padding: Added horizontal margin to role idea section for proper alignment within email container

Added — Phase 13.4: Tier 1 — Member Experience

• Onboarding stage (_stages/onboarding.html.erb): “What to Do Next” checklist with per-item routing to specific wizard steps/profile sections; smart hero CTA path (@next_wizard_step → @next_profile_section → fallback)
• Exploring stage (_stages/exploring.html.erb): Community type grid (4 types explained), “Recommended for You” suggestions with type labels + member counts, Browse Communities CTA
• Engaging stage (_stages/engaging.html.erb): Activity feed, suggested communities with type labels + member counts + descriptions, dismissable career resources card (Turbo Frame, JSONB tracked)
• Language updates: “Champions You Might Know” → “Alumni You Might Know”, hope-oriented empty states, stage-specific headings, “Fellow Alumni” district language
• Connections UX: Wizard step reworded to emphasize restriction (“Only people in my communities/city”), matching language in Settings
• Sidebar profile completion: Extended visibility through engaged_member stage; shows “X% complete · Edit →” or “Profile complete ✓”
• Edit Profile cross-link: “Connection settings →” link in profile sidebar (mobile + desktop)
• Wizard reorder: Connections moved to final wizard step
• Dev debug bar: Stage override selector for testing all 8 journey stages
• Industry field: Added to profession wizard step and completion logic

Added — Phase 13.1: Journey Engine & Tier Detection

• Cp::Tierable concern (app/models/concerns/cp/tierable.rb): engagement_tier (:member/:champion/:community_leader), compute_journey_stage (8 stages: new_arrival → community_leader), recompute_journey_stage! (persists to DB), has_contributions? (board posts, news, events, comments, 5+ reactions), tier predicates
• Migration add_journey_stage_to_cp_champions: integer column with index on cp_champions.journey_stage, default 0, not null
• Cp::DashboardVisibility service: maps journey stage → visible main/sidebar sections; tier-aware sidebar ordering; feature-flagged selective data loading
• Rake task journey_stage:recompute_all: backfill all existing champions’ cached journey_stage

Added — Phase 13.2: Progressive Dashboard Layout

• Cp::HomeController: parallel to existing DashboardController; feature-flagged root; selective data loading (13 categories, only queries what the stage needs); activity recording + journey recomputation on load
• Route GET /home → cp_home_path; feature flag config.x.features.progressive_dashboard (all envs set to false — gradual rollout)
• 17 view files under app/views/cp/home/: show.html.erb orchestrator, _hero.html.erb (8 stage variants), 3 card tier partials (Primary/Standard/Compact), 7 sidebar partials, 5 stage partials (onboarding, exploring, engaging, champion, community_leader)
• Cp::HomeHelper (app/helpers/cp/home_helper.rb): thread_other_champion(thread, champion) with multi-API fallback to shield views from model API changes
• 58 new tests: 25 Tierable, 24 DashboardVisibility, 9 HomeController, 2 HomeHelper, 1 connections partial render test

---

[1.0.46] - 2026-02-19

Added — Career Page Overhaul & Career Connect

• Career page redesign: New hero, Handshake as primary tool, three resource boxes (Career Resources, Career Fair Events, Career Guidance Events), simplified OCPD section
• Career Connect section: Personalized alumni matching based on career clusters — shows career-open alumni who share your field of study
• Major-level cluster mapping: 5 career clusters with ~120 major-specific overrides from OCPD data, handling cross-college majors correctly
• Cluster selector: Active cluster pill with “Looking for another career cluster?” reveal toggle
• Load more pagination: Turbo Stream-powered “Show More Alumni” button
• Blurred teaser for unauthenticated visitors with sign-in CTA

Improved — Career Connect Cards

• City/state location shown under name (respects address privacy settings)
• Connect button as primary CTA (60/40 split with View Profile)
• All degrees displayed with graduation years (not just cluster-matching degree)
• Connection request modal available directly from career page

Fixed

• View Profile link inside turbo frame caused “Content missing” — added turbo_frame: "_top"
• Alumni-only filter excludes students and faculty/staff from Career Connect
• .preload instead of .includes prevents SQL WHERE from filtering eager-loaded degrees

---

[1.0.45] - 2026-02-18

Fixed — Duplicate Daily Digest Emails

• Root cause: deliver_later created EmailLog dedup records asynchronously via Sidekiq; if digest job ran multiple times before delivery, dedup check found nothing and re-sent
• Changed deliver_later → deliver_now in Cp::NotificationDigestJob for both daily and weekly digests
• Dedup via Cp::EmailLog now works reliably since interceptor writes log synchronously
• Backlog item added for async delivery at scale (>300 recipients)

Added — Phase 14: Alumni Content Submissions

14.1 — Data Model & Backend Foundation

• submitted: -1 and declined: -2 status enums on Cp::NewsPost and Cp::Event
• Submission fields: submitted_by_champion_id, decline_reason, submitted_at, declined_at
• Cp::ContentSubmissionThread model (polymorphic content, open/resolved status)
• Cp::ContentSubmissionMessage model (polymorphic sender, body, read_at tracking)
• Public-facing scopes exclude submitted/declined content

14.2 — Champion Submission Forms & UX

• News submission form at /news/submit (Cp::NewsSubmissionsController)
• Event submission form at /events/submit (Cp::EventSubmissionsController)
• CTAs on news index, events index, and community content sections
• Community pre-selection via ?community_id= parameter
• Submission history at /my-submissions (Cp::SubmissionsController)
• Thread detail view with conversation history

14.3 — Admin Submissions Queue & Review

• Admin queue at /champions/content_submissions with tab-filtered index
• Tabs: Pending / In Conversation / Promoted / Declined with count badges
• Promote to Draft, Publish Directly, and Decline with reason actions
• Reply functionality on conversation threads
• Admin sidebar link with pending badge

14.4 — Notifications & Attribution

• 4 notification types: submission_reply, submission_promoted, submission_published, submission_declined
• Cp::ContentSubmissionMailer with 3 email flows (new submission, champion reply, published)
• Attribution display on published news (card + detail) and events (card + list + detail)

Changed — iMessage-Style Chat Bubbles

• Unified chat bubble styling across all 5 thread views (support × 2, submission × 2, connections)
• bg-skyblue/30 for sender’s bubbles, bg-white border for recipient’s
• Contrast-safe text colors (text-gray-700/text-gray-800)
• “Engagement Team” as sender name on champion-facing thread views

Tests: 3,582 runs, 9,178 assertions, 0 failures

---

[1.0.44] - 2026-02-17

Added — Email Notification Logging

• cp_email_logs table with automatic logging via EmailLoggingInterceptor
• Admin interface at /champions/email_logs (index, show, stats, CSV export)
• Email type, recipient, subject, metadata (JSONB), and status tracking
• Cp::EmailLog model with scopes and analytics methods

Added — Notification Frequency Guardrails

• Digest cooling-off: digest_mention_count on thread participants; threads become “stale” after 2 mentions, shown only when fresh content exists
• Digest deduplication: Daily/weekly digests check cp_email_logs to prevent duplicate sends (scheduler double-fire protection)
• Weekly stats accuracy: Exclude already-emailed notifications from weekly digest stats
• Stale thread section: Gentle “Still waiting for you” section in digest emails with softer styling
• mark_read! and new message callbacks reset digest_mention_count to 0
• Connection-based stats (Phase 10.5) replacing deprecated contacts

Fixed

• CI database setup: db:prepare replaces db:create + db:schema:load
• Seeds data: Use correct engagement level values (0-4)
• Digest job: Use .deliver_later directly (Rails 7.1 mail header restriction)

Documentation

• Email logging quick start guide and feature docs
• Notification frequency guardrails implementation docs

Tests: 3436 runs, 0 failures

---

[1.0.43] - 2026-02-17

Added — Fuzzy Search Improvements

• Lookup Portal fuzzy fallback: When exact ILIKE search returns 0 results, automatically falls back to trigram + soundex + levenshtein matching with amber “closest spelling matches” indicator
• API offset pagination: offset parameter, total_count, and has_more fields in API response envelope
• fuzzystrmatch extension: soundex() and levenshtein() for phonetic/edit-distance matching on short names (e.g., “taegan die” → “teagan dye”)
• 5 new fuzzy fallback tests (service + controller), 8 new pagination tests

Fixed

• Banner import Tempfile GC race condition: replaced Ruby Tempfile with regular file in tmp/banner_uploads/ to prevent garbage collection between preview and commit requests

Tests: 3389 runs, 0 failures

---

[1.0.42] - 2026-02-17

Added — Alumni Search REST API

• GET /api/v1/alumni/search endpoint with Bearer token API key authentication
• ApiKey model with key generation, authentication, per-minute rate limiting (100/min default), and revocation
• pg_trgm extension + GIN trigram indexes on alumni name columns for fuzzy matching
• filter_by_fuzzy_name and filter_by_fuzzy_full_name scopes on Alumni model
• Fuzzy fallback in AlumniMatcher (exact search first, pg_trgm fallback on no results)
• Search by full name, first/last name, email, or BUID; response matches Copy blob format
• Rake tasks: api_keys:create, api_keys:list, api_keys:revoke, api_keys:stats
• API documentation: docs/features/ALUMNI_SEARCH_API.md
• Tests: ApiKey model (14), AlumniSearchController (26) — 3377 total, 0 failures

Added — CL Welcome via Connections

• New cl_welcome connection type for Community Leader welcome messages
• Migration: community_id column on cp_connection_requests for CL context
• CL welcome flow on Leadership page sends connection request (not direct message)
• Batch eligibility checks: connected/pending/privacy status shown on member lists
• Gold-styled CL welcome request cards with community context and star icon
• CL pill on connections listing: ⭐ CL · CommunityName +N (desktop), ⭐ CL (mobile)
• “Show only CLs” filter toggle on connections page
• “Your Community Leaders” sidebar card on community show page
• Bidirectional CL↔Member privacy bypass in allows_contact_from?
• cl_welcome_sent activity event type
• USER_CONNECTION_TYPES constant (excludes system-only types from user settings)
• Expandable message preview on request cards (click to expand, gradient fade)
• Accepted sent requests hidden by default with “Show N accepted” toggle
• expandable_text_controller.js Stimulus controller for click-to-expand text
• Tests: ConnectionRequest model (6), Champion model (3), Service (3), Leadership controller (4), Connections controller (1)

---

[1.0.41] - 2026-02-17

Changed — Terminology Consistency

• Replaced “Champion Portal” with “Alumni Portal” across 30+ documentation files
• User-facing copy updated: “Champions” → “alumni” per Language Style Guide
• Fixed importmap pin for push notification helpers
• Updated Mailgun DNS documentation to match current domain

Tests: 3319 runs, 0 failures

---

[1.0.40] - 2026-02-17

Changed — “Belmont Alum” Rebrand

• FROM address: All mailers now default to Belmont Alumni <alumni@mail.belmontalum.com> (was Belmont Alumni Champions <champions@mail.alumnichampions.com>)
• Email subjects: “Champion Portal Weekly Summary” → “Belmont Alumni Weekly Summary”, invite → “invites you to join Belmont Alumni”, admin signup → “New Alumni Signup”
• Email headers: All <h1> text updated from “Belmont Alumni Champions” / “Alumni Champions” to “Belmont Alumni”
• Email alt text: All alt="Alumni Champions" → alt="Belmont Alumni" on header images
• Email body copy: ~30 replacements removing “Champion Portal” and “Alumni Champions” as portal name (e.g., “your Champion Portal account” → “your account”, “signed up for Alumni Champions” → “signed up”)
• Email footers: “Belmont Alumni Champions • alumnichampions.com” → “Belmont Alumni • alumnichampions.com”
• Digest emails: “Your Daily Champions Update” → “Your Daily Alumni Update”, “Your Weekly Belmont Champions Update” → “Your Weekly Belmont Alumni Update”
• PWA manifest: name/short_name → “Belmont Alum”, description → “Belmont University Alumni Community”
• Meta tags: Page title suffix → “Belmont Alum”, descriptions use natural phrasing instead of portal name
• Page titles: 20+ Champion Portal views updated from “Champion Portal” / “Alumni Champions” suffix to “Belmont Alum”
• Body copy: Landing page, directory, communities, help, feedback, settings, profile wizard, public CTA — all use natural phrasing (“your alumni community”, “your experience”) instead of portal proper name
• Staff admin views: “for the Champion Portal” → “for the alumni portal” in photo albums, events, news posts, stats, career resources, roadmap
• Welcome email: “Welcome to Alumni Champions!” → “Welcome to Belmont Alumni!”
• Admin notifications: “Champions quiz” → “alumni quiz”, kicker labels → “Belmont Alumni”

Preserved (identity language)

• “Alumni Champion” as identity/role recognition kept in signup flow, welcome email, invite, FAQ
• “You’re officially an Alumni Champion!” subject line kept
• Staff-facing “Alumni Champions” program references kept

Tests: 3318 runs, 0 failures, 0 errors

---

[1.0.39] - 2026-02-16

Added

• *.belmontalum.com as alternate Champion Portal domain (routing, host allowlists, verification)
• Supported subdomains: belmontalum.com, www.belmontalum.com, beta.belmontalum.com, staging.belmontalum.com, dev.belmontalum.com

Changed

• Updated route constraint to recognize belmontalum in hostname
• Updated production, staging, development, and test host allowlists
• Updated post-cutover verification rake task

Tests: 3318 runs, 0 errors

---

[1.0.38] - 2026-02-16

Changed — Phase 12: Source-Alignment Review

Full audit of Champion Portal user-facing text against 20 canonical source documents. 20 of 25 findings implemented across 7 waves; 5 explicitly deferred.

Inclusivity Framing (Project-Wide)

• Identity principle established: External-facing surfaces lead with “alumni” and “Bruins” (inclusive, welcoming). Internal/post-login surfaces celebrate members as “Champions” (recognition of showing up, not a gated title).
• Platform naming dissolved: No proper noun for the platform. “Alumni Champions” = the people, not the product. UI says “your community” / “your alumni community.”
• Updated Language Style Guide, AGENTS.md, and copilot-instructions.md with inclusivity framing.

Tier 1 — Quick Wins (9 findings, 15 files)

• “Sign Up — It’s Free” → “You’re Invited — Join Your Fellow Bruins” (landing, careers)
• “Become a Champion” → “Welcome Home, Bruin” (registration page)
• “recruitment district” → “local Bruin community” (profile)
• “You don’t currently qualify” → warm, explanatory alternative (communities)
• “the … system” → “your … community” (4 support email templates)
• “User” → “Champion” / “person” / “member” (feedback, boards, moderation)
• “New to Champion Portal?” → “First time here?” (sign-in page)
• “Welcome to the Champion Portal!” → “Welcome Home, Bruin! 💙” (notification email)
• “alumni network” → “alumni community” (welcome packs config)

Tier 2 — Email Overhaul (3 templates)

• Confirmation email (O-02): Rewritten from task-list to belonging-first tone
• Verification approved email (O-03): Rewritten to affirm identity at peak emotional moment
• Invite email (O-04): Rewritten with community-first, relationship language

Tier 3 — Copy & UX Improvements

• Wave A: FAQ “portal” → “community” (8 replacements), “manage” links → “your” links, gatekeeping flash messages softened (4 messages)
• Wave B: 15 empty states rewritten with warmth and CTAs across dashboard, boards, news, events, messages, photo albums, and leadership
• Wave C: 8 flash messages warmed (sign-in/out, boards, communities)
• Wave D: Landing page pillars renamed: Connect/Host Events/Share Stories → Belong / Gather / Inspire. Hero subtitle: “Every Bruin who shows up is already a Champion.”
• Wave E: Wizard header subtitle and connections step copy refined

Deferred

• F-01: Roles woven into experience (Phase 11 scope)
• F-03: Generosity-as-formation language (future content work)
• F-04: Source guardrail phrases (partially addressed via other findings)
• F-06: i18n infrastructure (explicitly deferred by user)
• L-08: Careers networking vocabulary (kept as-is per user decision)

---

[1.0.37] - 2026-02-15

Added — Phase 11: Champion Role Dashboard Card

• Role Dashboard Card — Dashboard card with two states: State A (no role → “Discover Your Role” quiz CTA) and State B (role selected → daily idea pack with refresh). Card appears for email_verified and champion_verified Champions only.
• Daily Role Idea Packs — Cp::RoleIdeaPackService generates 3 role-aligned action suggestions daily per Champion. Features: weighted random selection by priority, 30-day anti-repeat window, timezone-aware date rollover, Community Leader variant (mixed pool of role + CL-specific ideas).
• Roles Landing Page — /roles page showing all 4 Champion roles (Community Builder, Digital Ambassador, Connection Advisor, Giving Advocate) with descriptions from canonical source documents. Includes “Discover Your Role” quiz CTA.
• Admin Role Ideas CRUD — Staff management at Champions > Role Ideas. Create/edit/activate/deactivate/archive ideas with role/target filtering, search, status toggle, priority control. Sidebar link with active count badge.
• 115 Seed Ideas — YAML seed data with ideas across all roles (25 each for CB/DA/CA/GA, 15 CL), authored from canonical source documents. Rake tasks: role_ideas:seed, role_ideas:stats, role_ideas:cleanup_old_packs.
• Turbo Stream Refresh — “Try different ideas” button replaces idea pack via Turbo Stream without full page reload. Records refreshed_role_ideas activity event.

Models Added

• Cp::RoleIdea — Content model with role, target, status enum (draft/active/paused/archived), priority weighting, template variable interpolation (, , )
• Cp::RoleIdeaPack — Daily pack per champion per date with refresh_count tracking
• Cp::RoleIdeaPackItem — Join model with position ordering (primary at 0, secondary at 1+)

Activity Events Added

• viewed_role_card, clicked_take_quiz, clicked_learn_more_roles, refreshed_role_ideas, clicked_role_idea_cta, role_selected

---

[1.0.36] - 2026-02-15

Added — Phase 10: Connections

• Connection Request System — Champions request connections by choosing a type (Say Hi / Career Advice / Networking) and writing an initial message. Requestees can accept, ignore, or let requests expire. Rate limiting: 10 requests/day for requestors, configurable cap for requestees.
• Connection Settings — Per-champion JSONB preferences: open-to types, daily cap, pause mode, almost-alumni toggle, community/district restrictions. Managed via Settings > Connection Preferences.
• Connections Hub — Two-tab layout replacing the old Messages nav: “Connections” tab (active conversation threads sorted by last message) + “Requests” tab (incoming/sent/past sub-tabs). Compose modal lists connected champions only.
• Connection-Gated Messaging — Must have an active Connection to message (except support threads). Disconnect archives the thread; reconnection requires a new request.
• Directory & Profile Integration — “Open to” type pills on directory cards and profiles. Connect button with modal on profiles. Filter directory by connection type. Button states reflect connection/request status.
• Contacts → Connections Migration — Mutual contacts auto-converted to Connections with linked message threads. One-way contacts removed. ChampionContact model deleted. FAQ and UI updated.
• Admin Connection Metrics — Staff dashboard with connection stats, request rates, super-connector identification, acceptance metrics. Available at Champions > Stats > Connections.
• Engagement Score Hardening — Guard for blank event_type in EngagementScoreService#point_value to prevent NoMethodError on nil.

Models Added

• Cp::Connection — Canonical pair ordering (champion_a_id < champion_b_id), required message_thread, connected_at/disconnected_at timestamps, disconnect! method
• Cp::ConnectionRequest — Statuses: pending/accepted/ignored/cancelled. Types: say_hi/career_advice/networking. Rate limiting via sent_today_by/received_today_by scopes

Models Removed

• Cp::ChampionContact — Replaced entirely by Cp::Connection

Changed

• Nav: Messages → Connections — Main navigation renamed; badge shows unread connection messages
• MessageThread — Added thread_type column (connection/support) with corresponding scopes and methods
• Champion — Replaced contact_preference enum with connection_preferences JSONB. Added connection associations, preference methods, and connected_champion_ids cache

Post-Deployment Tasks

# Run AFTER deployment (idempotent — safe to re-run)
heroku run bin/rake connections:migrate_contacts --app alumni-lookup

---

[1.0.35] - 2026-02-10

Fixed

• Community Deactivation — Pending community suggestions are now removed when a community is deactivated, preventing champions from seeing recommendations for inactive communities
• Event Timezone Select — Timezone dropdown now correctly defaults to Central Time; option values changed from Rails friendly names (tz.name) to IANA identifiers (tz.tzinfo.identifier) to match stored DB values
• Sidebar & Community Index Pills — Added whitespace-nowrap flex-shrink-0 to count badge pills to prevent awkward line wraps
• Welcome Dismiss Idempotency — dismiss_welcome! now preserves original timestamp on repeated calls (fixes flaky CI test)

Changed

• Message Notification Default — Default email frequency for new messages changed from "daily" to "immediate" so new champions receive prompt email notifications for unread messages

Added

• Belmont Campus Location Shortcut — “On Belmont Campus” button on event form auto-fills Belmont University address (1900 Belmont Blvd, Nashville, TN 37212) and changes venue name field to prompt for building/room

---

[1.0.34] - 2026-02-10

Added - Phase 7: Career Center (Complete)

• Career Center Hub (/careers) — Public landing page with self-serve-first career resources
  • Hero section: “Your Career Partner for Life” with CTA
  • Quick Links grid (Handshake, LinkedIn Learning, Indeed, Glassdoor) from YAML config
  • Career Events section showing events tagged career_event: true
  • Networking Resources grouped by 6 categories with download buttons
  • OCPD Partnership section with consultation booking, contact info
  • Sign-up CTA for unauthenticated visitors
  • Career Center link in top-level navigation (desktop + mobile)
• Resource Downloads — Authenticated PDF downloads with counter tracking
  • resource_downloaded activity event with resource_id and category metadata
  • Login redirect for unauthenticated users
• Staff Resource Management — Full CRUD in Champion Admin (/champions/career_resources)
  • PDF drag/drop upload via pdf_dropzone_controller.js Stimulus controller
  • Search, category filter, status filter
  • Toggle active/inactive (soft remove)
  • Stats: total resources, active count, total downloads
• Career Events Integration — career_event boolean on cp_events table
  • Admin checkbox on event form
  • Cp::Event.career_events scope
  • Career events displayed on Career Center and standard events pages
• Career Center Analytics — Staff dashboard at /champions/stats/career_center
  • Views, downloads, unique champions, daily trends
  • Period filtering (7d/30d/90d/All Time)
• Activity Events — career_center_view and resource_downloaded tracked
• Data Model — cp_career_resources table with Active Storage PDF attachment
  • 6 resource categories: Getting Started, Resume Building, Interview Preparation, Career Advice Conversations, Networking & Job Seeking, Follow-Up & Relationship Building
• Tests — Model tests + 3 controller test files (careers, downloads, admin CRUD)

Fixed

• Career resource CATEGORIES test assertion updated from 4 to 6 to match expanded model categories

---

[1.0.33] - 2026-02-07

Added - Seeded Discussions Auto-Creation

• Community after_create Callback — New communities automatically receive 2 seeded discussion posts:
  • Selects from global seeded questions using SeededQuestionSelector with deduplication
  • Publishes via SeededQuestionPublisher with community-aware interpolation
  • Skips custom communities and communities with discussion boards disabled
  • Logs creation count via Rails.logger.info
• Tests — 14 tests in community_seeded_discussions_test.rb covering callback conditions, method behavior, and integration

Fixed

• BoardPost dependent: :destroy — Changed has_one :seeded_question_exposure from dependent: :nullify to dependent: :destroy to fix NotNullViolation crash when deleting board posts (the board_post_id column has a NOT NULL constraint)

Added - Community Welcome Content (Phase 9.5 Complete)

• WelcomeContentGenerator Service — Auto-generates welcome content for community boards:
  • Template-based content from config/welcome_packs.yml with 15 community types
  • Markdown-to-HTML conversion using Redcarpet gem with extensions (hard_wrap, autolink, tables, fenced_code_blocks, strikethrough)
  • Variable interpolation (,) for personalization
  • Deterministic template rotation based on community ID
• Welcome Panel UI (_welcome_panel.html.erb):
  • Gradient-accented dismissible panel shown on community pages
  • Renders ActionText rich content with proper prose styling
  • Stimulus-powered smooth AJAX dismissal via dismiss_welcome_controller.js
  • Auto-dismisses after configurable number of views (default 5)
• Member Tracking — Added to cp_champion_communities join table:
  • welcome_dismissed_at (datetime) — When member dismissed the panel
  • community_view_count (integer) — Tracks visits for auto-dismissal
  • dismiss_welcome controller action with activity event tracking
• Rake Tasks — 7 management tasks in lib/tasks/welcome_content.rake:
  • welcome_content:generate_all — Generate for all communities
  • welcome_content:generate[community_id] — Generate for specific community
  • welcome_content:preview[community_type] — Preview templates (supports HTML=1 flag)
  • welcome_content:status — Show generation status across all communities
  • welcome_content:clear[community_id] — Clear welcome content
  • welcome_content:reset_dismissals[community_id] — Reset member dismissals
  • welcome_content:generate_type[type] — Generate for all of a community type
• Tests — Comprehensive coverage (26 tests):
  • welcome_content_generator_test.rb — Service generation and template selection
  • welcome_content_rake_test.rb — All rake task functionality
  • Controller and helper tests for dismissal and display logic

Added - Trust-First Community Access (Phase 9.7 Complete)

• Unverified Champion Community Access — Champions can view and join communities during verification:
  • View all public community pages, boards, discussions without verification
  • Join communities immediately after signup (stored in community_memberships)
  • Browse discussion boards and read all posts and comments
  • Only contribution features (reactions, comments, posting) gated by verification
• Verification-Gated UI with Contextual Messaging:
  • boards/show.html.erb: Reactions and comment forms gated with verification teaser
  • discussions/show.html.erb: Comment forms, reactions, editing gated with contextual messages
  • discussions/index.html.erb: “New Post” button gated for unverified members
  • communities/index.html.erb: “Join Now” button shows verification message when appropriate
  • Consistent teaser pattern: Gray-50 box with lock icon explaining what verification unlocks
• Trust-First Philosophy Implementation:
  • Verification unlocks CONTRIBUTION, not BELONGING
  • Unverified champions feel welcomed, not excluded
  • Clear messaging about what becomes available after verification
  • No “wall” blocking community exploration

Added - Onboarding Metrics & Analytics (Phase 9.4 Complete)

• Cp::OnboardingEvent Model — Tracks all onboarding journey events:
  • Event types: signup_email_submitted, signup_email_verified, signup_password_created, signup_oauth_started, signup_oauth_completed, wizard_started, step_viewed, step_completed, step_skipped, wizard_completed, community_accepted, community_declined
  • Class methods for recording each event type with appropriate metadata
  • Scopes for period filtering: last_7_days, last_30_days, last_90_days
• OnboardingInsights::OnboardingMetricsService — Signup funnel and wizard metrics:
  • Signup funnel: email_submitted → email_verified → password_created
  • OAuth funnel: oauth_started → oauth_completed
  • Wizard funnel: started → completed with step-by-step breakdown
  • Period filtering (7d, 30d, 90d, all time)
• OnboardingInsights::SeededQuestionMetricsService — Community suggestion metrics:
  • Accept/decline counts and rates by community type
  • Sorted tables with champions-joined ranking
  • Period filtering
• InsightsController — Admin dashboard for metrics:
  • /champions/insights/onboarding — Signup funnel and wizard completion
  • /champions/insights/seeded_questions — Community suggestion performance
  • Requires portal_admin+ role
• Event Instrumentation — Added to 5 controllers:
  • RegistrationsController: signup_email_submitted
  • ConfirmationsController: signup_email_verified, signup_password_created
  • OmniauthCallbacksController: signup_oauth_started, signup_oauth_completed
  • ProfileWizardController: wizard_started, step_viewed, step_completed, step_skipped, wizard_completed
  • CommunitySuggestionsController: community_accepted, community_declined
• Tests — Comprehensive coverage:
  • onboarding_metrics_service_test.rb: 432 lines, covers period filtering, funnel metrics, edge cases
  • seeded_question_metrics_service_test.rb: 341 lines, covers accept/decline counts, community type breakdown
  • insights_controller_test.rb: 158 lines, covers auth, authorization, period params
  • All tests passing: 45 runs, 136 assertions, 0 failures

Added - Seeded Questions Scheduler & Bug Fixes (Phase 9.3)

• Scheduler Documentation — Added seeded_questions:create to SCHEDULERS.md:
  • Daily schedule (runs at 6am CT for evening question posting)
  • Test commands and validation instructions
  • Integration with Heroku Scheduler
• Rake Task Tests (test/tasks/seeded_questions_rake_test.rb):
  • 4 tests covering seeded_questions:create and seeded_questions:stats
  • Validates task execution and output formatting

Fixed - Seeded Questions Rake Task Bugs

• seeded_questions:stats task — Fixed NoMethodError: undefined method 'active':
  • Changed Cp::SeededQuestion.active to Cp::SeededQuestion.status_active
  • The status enum uses prefix: true, so scopes are status_active, not active
• seeded_questions:preview task — Fixed wrong column name:
  • Changed cp_community_id to community_id (BoardPost schema uses community_id)
• seeded_questions:create task — Fixed wrong column name (previous session):
  • Changed cp_community_id to community_id at line 26

Added - Seeded Discussion Questions (Phase 9.2)

• Cp::SeededQuestion Model — Staff-authored discussion prompts with:
  • Template variables for interpolation ({community_name}, {community_type}, {member_count}, etc.)
  • Targeting: global (all communities), community_type (district/college/etc.), affinity_category
  • Status workflow: draft → active → paused → archived
  • Priority weighting (1-10) for selection algorithm
• Cp::SeededQuestionExposure Model — Tracks when questions are posted:
  • Links seeded_question, community, and resulting board_post
  • Supports 30-day rotation cooldown per question/community pair
  • Scopes: recent, for_question, for_community, within_cooldown
• Cp::SeededQuestionSelector Service — Selection algorithm with:
  • Community eligibility checks (organic activity, member count, max active questions)
  • Weighted random selection favoring priority and freshness
  • Constants: ROTATION_DAYS=30, MAX_ACTIVE_PER_COMMUNITY=2, ORGANIC_ACTIVITY_DAYS=7
• Cp::SeededQuestionPublisher Service — Publishing logic with:
  • Transaction-wrapped BoardPost creation with author_type: ‘Staff’
  • Template interpolation via Cp::QuestionInterpolator
  • Exposure record creation with posted_at timestamp
• Cp::QuestionInterpolator Service — Template variable interpolation:
  • Variables: {community_name}, {community_type}, {member_count}, {current_month}, {current_season}, {current_year}
  • Season mapping (Winter: Dec-Feb, Spring: Mar-May, Summer: Jun-Aug, Fall: Sep-Nov)

Added - Admin Seeded Question Interface (Phase 9.3)

• Champions::SeededQuestionsController — Full CRUD with:
  • Index with filtering (status, target_type) and search (title, body_template)
  • Sorting by title, priority, exposures_count, created_at
  • Preview action with live template interpolation
  • Activate/deactivate actions for status management
• Admin Views (7 files in app/views/champions/seeded_questions/):
  • Index with filter tabs, search, sortable columns
  • Show page with exposure history, performance metrics placeholder
  • New/Edit forms with template variable reference
  • Preview panel showing interpolated output
  • Status badge partial with color-coded states
• Routes — Resourceful routes with member actions:
  • resources :seeded_questions with preview, activate, deactivate
• Controller Tests — 36 tests, 89 assertions covering:
  • Index filtering and sorting
  • CRUD operations with authorization
  • Preview interpolation
  • Activate/deactivate state transitions

Added - Enhanced Onboarding Flow (Phase 9.1)

• join_communities Wizard Step — New step in profile wizard suggesting communities based on:
  • Alumni degrees (college and major communities)
  • Location (district communities)
  • Affinities (organization/club communities)
• Community Suggestion Cards — Display suggested communities with:
  • Community icon by type (district, college, major, affinity, industry)
  • Name, member count, and personalized reason
  • “Join” and “Not for me” action buttons
• AJAX Integration — Turbo Stream removes cards smoothly on accept/decline
• Step Logic — Step only shows if champion has pending suggestions (skipped otherwise)
• Bug Fixes:
  • Fixed college_desc → college_name attribute name in CommunityDetectionService
  • Fixed for_wizard scope to use integer enum values (0, 1, 2) not string names

Added - Mobile Optimization (Champion Admin)

• DESIGN-GUIDELINES.md v2.3 — Major documentation update:
  • Section 8.11: Admin Portal Mobile Patterns (table→card conversion, status badges, action buttons)
  • Section 8.12: Admin Card & Container Standards (responsive rounding, inner padding)
  • Section 8.13: Mobile Optimization Checklist (comprehensive 10-category audit framework)
• New Admin Show Pages:
  • champions/events/show.html.erb — Full event detail view with breadcrumbs, status, cover image, date/location cards
  • champions/news_posts/show.html.erb — News post detail with hero, content cards, featured champions, engagement stats
• Mobile Card Views — Added sm:hidden mobile cards + hidden sm:block desktop tables:
  • News Posts index
  • Photo Albums index
  • Verification Queue
• Filter Pills Pattern — Replaced underline tabs with touch-friendly pills:
  • Support Threads (status filter)
  • Feedbacks (status/type filters)

Changed - Mobile Optimization (Champion Admin)

• Card Rounding Standardized — All 50+ admin cards now use rounded-md sm:rounded-lg (8px mobile → 12px desktop)
• Container Wrappers Removed — Eliminated redundant px-4 sm:px-6 lg:px-8 wrappers from ~14 view files (layout provides these)
• Button Stacking — Action buttons now use flex-col sm:flex-row for mobile-friendly vertical stacking
• Header Layout — Admin header title now links to Champion Admin root
• Text Truncation — Standardized line-clamp-2 with proper flex container constraints

Fixed

• Routes updated to include show action for news_posts and events (was except: [:show])
• Test assertions updated for new UI patterns (button text, filter selectors)

---

[1.0.32] - 2026-02-01

Added - Current Student Data Integration

• Current Student Import System (Settings → Data Imports → Current Students):
  • Two-pass CSV import: Preview first, then commit
  • Redis-based manifest storage for import state
  • Duplicate BUID detection and warnings
  • Detailed import summary with statistics
• Student Status Display:
  • “Current Student” badge on alumni profiles
  • Student info in search results and profile views
  • Major/classification/enrollment year display
• Current Student Model (current_students table):
  • Links to alumni via BUID
  • Stores major, classification, enrollment year, expected graduation
  • active flag for current enrollment status

Fixed - Bug Fixes

• Redis SSL handling: Fixed SSL certificate verification error for Heroku Redis in CurrentStudentManifestStore (matches pattern in ManifestStore and Sidekiq)

---

[1.0.31] - 2026-01-31

Added - Security & Rate Limiting

• Rack::Attack rate limiting (config/initializers/rack_attack.rb):
  • General rate limit: 300 requests per 5 minutes per IP
  • Asset throttle: 500 requests per minute per IP
  • Login protection: 5 attempts per 20 seconds per IP/email
  • API rate limit: 60 requests per minute per IP
  • Password reset throttle: 3 per 30 minutes per IP
• Blocklists:
  • WordPress vulnerability scanner paths (/wp-admin, /xmlrpc.php, etc.)
  • Screenshot services with ?screenshotCacheBust= parameter
  • Fail2ban: 10 throttle violations in 10 minutes → 1 hour IP block
• Request logging middleware (lib/middleware/request_logger.rb):
  • Logs slow requests (>5 seconds) with [SLOW REQUEST] tag
  • Detects screenshot service requests with [SCREENSHOT SERVICE] tag
  • Detects vulnerability scanners with [SCANNER DETECTED] tag
• Security rake tasks (lib/tasks/security.rake):
  • security:status — Show Rack::Attack configuration status
  • security:rules — List all security rules
  • security:analyze_tips — Heroku log analysis commands

Added - Performance Optimizations

• Recommendation caching: Directory recommendations now cached per champion (4 hour expiry)
• Counter caches: unread_messages_count and unread_notifications_count on champions
• Redis caching: Production uses Redis for caching when available

Fixed - Bug Fixes

• Memory leak: Fixed event converter memory leak in background jobs
• Screenshot feature: Various screenshot-related fixes

---

[1.0.30] - 2026-01-31

Added - Feedback Screenshot Feature

• Screenshot attachment: Feedback form now supports optional screenshot upload
• Mobile-friendly capture: File input includes camera capture for mobile devices
• Preview functionality: Selected screenshots display with preview before submission
• Admin display: Screenshots visible in Champion Admin feedback view

Fixed - Bug Fixes

• Mutual contact notification: When adding a contact who already has you as a contact, notification now correctly shows “You’re now mutual contacts with [Name]!” instead of the generic add message
• Community email template: Fixed undefined method 'build_full_url' error in join_request_approved.html.erb by adding the helper method to CommunityMailer
• Mobile contact button overlap: Profile page contact button no longer overlaps with photo on mobile — moved to inline position below photo on small screens
• Bell notification filtering: new_message notifications now excluded from bell dropdown entirely (they have their own indicator in the Messages nav item)

---

[1.0.29] - 2026-01-29

Changed - Custom Communities UX Improvements

• Removed “custom” pill: Custom communities no longer display a blue “custom” pill on community cards and headers, creating a cleaner look
• Public join requests: Custom communities now allow join requests from any verified champion (previously only matched by slug)
• Membership prompt: Non-members see an inviting “Request to Join” card instead of a restricted access message

Added - Web Push for Community Notifications

• CommunityNotification web push: Champions now receive web push notifications when a community they’re interested in reaches its member threshold
• Complete notification coverage: All three notification systems (StaffNotification, Cp::Notification, CommunityNotification) now support web push

---

[1.0.28] - 2026-01-29

Changed - Champion Portal Subdomain Restriction

• Portal availability: Champion Portal now only enabled on specific subdomains:
  • beta.alumnichampions.com — Production beta (live data)
  • staging.alumnichampions.com — Staging environment
  • dev.* and localhost — Development
• Marketing site redirect: alumnichampions.com and www.alumnichampions.com now redirect to the legacy signup flow (Squarespace marketing site)
• CI updates: GitHub Actions smoke tests updated to use staging URLs

---

[1.0.27] - 2026-01-29

Changed - Beta vs Staging Environment Distinction

• Environment detection: Split Champion Portal environment detection into three tiers:
  • Beta (beta.alumnichampions.com) — Blue banner, production app with live data
  • Staging (staging.alumnichampions.com) — Amber banner, staging app with test data
  • Development (dev.*, localhost) — Development indicator
• New helper method: Added beta_environment? alongside existing staging_environment?
• Color-coded banners: Environment banners now visually distinguish Beta (blue) from Staging (amber)
• Impersonation: Both Beta and Staging environments allow champion impersonation for testing

---

[1.0.26] - 2026-01-29

Fixed - Rails 7.1+ Compatibility

• db:snapshot task: Fixed compatibility with Rails 7.1+ by using schema_migration.versions instead of querying ActiveRecord::SchemaMigration directly

Added - Champion Portal Data Migration Tooling

• lib/tasks/migrate_cp_data.rake: New rake tasks for staging-to-production CP data migration
  • migrate:export_cp — Exports all Champion Portal tables as SQL INSERT statements
  • migrate:export_cp_summary — Preview record counts before migration
  • Handles PostgreSQL reserved words (e.g., primary column) with proper quoting
  • Silenced Rails logging for clean SQL output

---

[1.0.25] - 2026-01-29

Added - Environment & Domain Migration Tooling

• lib/tasks/verify.rake: Environment verification tasks
  • verify:environment_comparison — Compare hosts, mailer config, env vars, table stats
  • verify:db_schema_comparison — Compare migration versions between environments
  • verify:post_cutover — Automated health checks after domain cutover
• lib/tasks/db_snapshot.rake: Database comparison tool
  • db:snapshot — Outputs table counts, max IDs, latest timestamps by category
  • Categories: Champion Portal (cp_), Engagement (engagement_), Core (alumni, degrees, users)
• docs/operations/DOMAIN_ENV_CUTOVER_RUNBOOK.md: Comprehensive cutover runbook
  • Squarespace-specific DNS instructions
  • Database sync strategies (full copy vs cp_* tables only)
  • Before/During/After checklists
  • Rollback procedures
• docs/operations/ENVIRONMENTS_CURRENT.md: Updated with staging environment details
  • Domain mapping summary table
  • App name references

Changed - Production Host Configuration

• config/environments/production.rb: Updated allowed hosts
  • Added staging.alumnilookup.com and staging.alumnichampions.com
  • Removed alumnichampions.com and www.alumnichampions.com (Squarespace marketing site)
  • Added documentation comments explaining domain mapping

---

[1.0.24] - Previous Release

Changed - Event Photo Gallery Enhancement

• Per-album grouping: Event show page now displays photos grouped by album (each album as separate section) instead of flattening all photos into one grid
• Album sections: Each album shows: title with photo count → photo grid → “View all from [Album]” link
• Clearer navigation: Users can now easily see which photos belong to which album

Added - Test Coverage (Session 5.5 Audit)

• Push subscriptions controller tests: 5 tests covering Web Push subscription CRUD
• Support messages controller tests: 3 tests for CL support message creation
• Support threads fixtures: Test fixtures for support message testing

Fixed - Photo Albums Bug Fixes

• Cover photo ordering: Fixed featured_photo method to respect position order — dragging a featured photo before another featured photo now correctly makes it the new cover
• JS Cover badge update: Sortable controller now updates Cover badge immediately after drag-drop reorder (no page refresh needed)
• Help text accuracy: Updated admin UI text from misleading “First photo will be used as cover if no cover is set” to accurate “The first featured photo becomes the cover, or the first photo if none are featured”

Added - Phase 5.5: Photo Albums (Complete)

Database & Models

• cp_photo_albums table: Photo album records with slug, title, description, status (draft/published), event linkage
• cp_photo_album_communities table: Join table for community targeting
• cp_photos table: Individual photos with position, featured flag, caption, photographer_credit, metadata (JSONB)
• Cp::PhotoAlbum model: Full associations with communities, photos, event, and has_many_attached :cover_image
• Cp::Photo model: Active Storage attachment with position/featured/caption management

Champion Admin (Lookup Portal)

• Photo Albums CRUD: Full index/new/edit/show/destroy actions in Champions::PhotoAlbumsController
• Drag-and-drop uploads: Multi-file photo upload with Stimulus controller and progress bars
• Photo management: Reordering via drag handles, caption/credit editing, featured toggle
• Photo deletion: Individual photo removal with confirmation
• Event integration: “Create Photo Album” button on Events index for past events
• Pre-population: Albums created from events inherit title, description, and communities

Champion Portal

• /photo-albums index: Gallery listing all published albums with cover images
• /photo-albums/:slug detail: Album detail page with responsive photo grid
• Lightbox component: Full-screen photo viewer with swipe/keyboard navigation (←/→/Esc)
• Photo preloading: Next/previous photos preloaded for smooth navigation
• Direct sharing: Album detail pages shareable via URL

Dashboard Integration

• “From the Community” carousel: Featured photos from published albums
• Touch-friendly scrolling: CSS scroll snap for mobile carousel experience
• Empty state handling: Section hidden when no featured photos exist

Activity Tracking

• photo_album_viewed: Tracked when champions view album detail pages

Tests

• Dashboard controller tests: 8 tests covering carousel integration scenarios
• Photo Albums controller tests: 25 tests covering CRUD, nested routes, and photo management

Added - Phase 8: Notification System Enhancements (8.1-8.4 Complete)

Phase 8.1: Settings UI Updates

• Discussions notification group: Added new “Discussions” section to Settings with post_reply, comment_reply, post_reaction, and comment_reaction types
• CL-only visibility: Join Requests and Community Leadership notification rows now only visible to Community Leaders
• Explanatory note: Added clarification that account notifications (verification, support) are always immediate

Phase 8.2: Discussion Notifications

• Discussion notifications in digests: Post replies, comment replies, and reactions now included in daily/weekly digest emails
• Aggregated activity: Discussion activity grouped by board/post for better readability

Phase 8.3: Scheduler Activation

• Monday guard fix: Added return unless Time.zone.today.monday? guard to Cp::WeeklyDigestJob — Heroku Scheduler only supports 10-min/hourly/daily
• SCHEDULERS.md updated: Documented scheduler limitation and workaround pattern
• Activation commands: Added Heroku Scheduler commands for champion daily/weekly digests

Phase 8.4: Immediate Templates (Dedicated Templates)

• 8 new branded email templates (HTML + text versions) for account notifications:
  • verification_pending_notification — When champion signs up, awaiting staff verification
  • verification_approved_notification — When champion is verified by staff
  • support_reply_notification — When staff replies to support thread
  • community_leader_assigned_notification — When champion is assigned as CL
• Branded confirmation email: Updated Devise confirmation_instructions to match Champion Portal branding
• ChampionMailer helper: Added build_full_url method for consistent asset URLs

Bug Fixes

• BUID unique constraint fix: Added normalize_buid callback to convert empty strings to nil before save, preventing PG::UniqueViolation on faculty/staff signup without BUID

Added

• Notification Digest Rake Tasks: Created lib/tasks/notification_digests.rake with convenient tasks for QA testing:
  • bin/rake notifications:digest_recipients — List champions with digest notifications configured
  • bin/rake notifications:digests:preview_daily[email] — Preview daily digest without sending
  • bin/rake notifications:digests:preview_weekly[email] — Preview weekly digest without sending
  • bin/rake notifications:digests:send_daily_to[email] — Send daily digest to specific champion
  • bin/rake notifications:digests:send_weekly_to[email] — Send weekly digest to specific champion
  • bin/rake notifications:digests:send_daily — Send daily digests to all eligible champions
  • bin/rake notifications:digests:send_weekly — Send weekly digests to all eligible (bypasses Monday check)
• QA Email Testing Guide: Created docs/qa/EMAIL_TESTING_GUIDE.md with comprehensive documentation for testing all 10 mailer classes and 23+ email types in development

Fixed

• Admin Weekly Digest sends on Mondays only: Fixed bug where admin weekly digest was sending daily instead of weekly. Added Monday guard to Cp::WeeklyDigestJob since Heroku Scheduler doesn’t support weekly scheduling (only 10-min, hourly, daily). Job now runs daily but only sends emails on Mondays.

Added - Phase 5.4: Alumni Like Me (Recommendations) (Complete)

Recommendation Service

• Cp::AlumniLikeMeService: Multi-factor scoring algorithm for Champion recommendations
• Scoring factors: College (+20), Major (+25), Grad Year (+15/10/5), Industry (+15), Affinities (+10 each, max 3), District (+10)
• Minimum threshold: 15 points required to appear in recommendations
• Exclusion logic: Excludes self, unverified Champions, blocked users, existing contacts

Directory Integration

• “Champions Like You” section: Appears on Directory when no search/filters active (first page only)
• Recommendation cards: Compact cards with match reason badges showing why each Champion is recommended
• Visual polish: Gradient accent bars, sparkle icons, “Because you share…” header

Dashboard Integration

• “Champions You Might Know” carousel: Touch-compatible horizontal scroll section on dashboard
• CSS scroll snap: Native mobile-friendly scrolling with 2 cards visible at a time
• Profile threshold: Shows “Complete your profile” prompt if profile <50% complete
• View All link: Links to Directory for full recommendations

Activity Tracking

• recommendation_viewed: Tracked when recommendations are displayed on Directory
• recommendation_clicked: Event type added for future click tracking integration

Model Enhancement

• Champion#affinity_codes: Helper method for efficient affinity matching with automatic cache clearing

Added - Phase 5.3: Contacts System (Complete)

Contacts Model & Storage

• cp_champion_contacts table: Champion-to-Champion contact relationships
• Mutual tracking: Automatically tracks when both Champions add each other
• Privacy integration: Location and messaging privacy with “Contacts Only” option

Contact Button & Directory

• Contact button: Icon-only button on profiles and directory cards
• Visual states: Filled user icon = contact, outline = non-contact, amber = mutual
• Hover transitions: Shows “Add” or “Remove” action on hover
• Directory contacts view: /directory/contacts route for contacts-only listing
• Filter toggle: “My Contacts Only” filter in main directory

New Message Composer

• Modal interface: Instagram-style “New Message” composer
• Contact search: Search contacts and all Champions in single interface
• Direct initiation: Start conversations from directory, profile, or modal

Notifications

• In-app notification: “X added you as a contact” with link to profile
• Email notification: Respects notification preferences (new_contact setting)
• Notification preferences: Toggle for contact-related notifications

Privacy Settings Enhancements

• Location privacy: “Contacts Only” option for city/state visibility
• Messaging privacy: “Contacts Only” option for who can message you
• One-way privacy: Your contacts see your info; adding someone doesn’t grant you access to theirs

Activity Tracking

• New event types: contact_added, contact_removed tracked in activity events

Performance Improvements

• Counter cache columns: unread_messages_count, unread_notifications_count on cp_champions
• Header badge optimization: Badges use cached counts instead of live queries
• Login drift correction: Counters recalculated on login to prevent drift

UI Polish (included with 5.3)

• Membership badges: “Student” and “Faculty/Staff” badges moved under profile photos consistently
• Messages privacy UI: Simplified one-way conversation warning (precomputed in controller)
• Contact button positioning: Consistent top-right corner placement on cards and profiles

---

Added - Phase 5.2: Almost Alumni + Faculty/Staff Support (Complete)

New Membership Types

• Membership type enum: alumni, almost_alumni, faculty_staff on cp_champions
• Almost Alumni fields: anticipated_program, anticipated_college_code, anticipated_graduation_date
• Faculty/Staff fields: work_email, profession, affiliated_college_code, affiliated_program

Signup & Verification

• Signup wizard education step: Displays appropriate fields based on membership type selection
• Verification queue: Supports verification of Almost Alumni and Faculty/Staff with membership-type-specific display

Directory & Profile Display

• Directory filters: Alumni (default), Almost Alumni, and Faculty/Staff membership type options
• Directory cards: Display anticipated education for Almost Alumni, profession/affiliation for Faculty/Staff
• Profile badges: “Almost Alumni” and “Faculty/Staff” badges on profiles
• Profile hero: Shows anticipated program and graduation year for Almost Alumni
• Profile sidebar: Displays anticipated education in Education section for Almost Alumni

Wizard & Admin Enhancements

• Bio step in wizard: New step for champions to add their bio during onboarding
• Major autocomplete: Anticipated program field uses autocomplete searching Major model
• Graduation date picker: Month/year selects instead of full date field for anticipated graduation
• Admin membership type change: Dropdown in champion admin show page to change membership type

Deferred to Future Phase

• Degree import hook for automatic Almost Alumni → Alumni upgrade
• Admin “Recheck Education” action
• Almost Alumni upgrade email notification

Fixed

• Champion Admin discussions: editing a post now clears community_id when switched to Global visibility and clears author fields when set to Engagement Team, preventing stale data from lingering after edits.
• Champion Portal dashboard now includes global (non-community) discussions so announcements surface everywhere.
• Hidden discussions no longer appear on the discussions index; hiding in admin fully removes them from listing.

Added

• Champion Admin discussions: edit support (including Engagement Team-authored posts) and image upload in the admin CRUD flow.

---

[1.0.24] - 2026-01-21

Added - Phase 5.6: Beta Feedback System (Complete)

Database-Backed Feedback Management

• Cp::Feedback model: Full CRUD with status tracking (new, read, in_progress, resolved, closed)
• Admin interface: Lookup Portal > Champion Admin > Feedback with filtering and pagination
• Sidebar integration: “Feedback” link with unread count badge (below CL Support)
• Staff notifications: Email sent to staff with can_support_respond permission when feedback submitted
• Permission gating: Mirrors CL Support pattern — requires portal_admin role AND can_support_respond permission

Files Created

• app/models/cp/feedback.rb — Model with validations, scopes, helpers
• app/controllers/champions/feedbacks_controller.rb — Admin CRUD controller
• app/views/champions/feedbacks/index.html.erb — Filterable list view
• app/views/champions/feedbacks/show.html.erb — Detail view with status management
• db/migrate/*_create_cp_feedbacks.rb — Database schema
• test/models/cp/feedback_test.rb — 24 model tests
• test/controllers/champions/feedbacks_controller_test.rb — 14 controller tests

---

Added - Phase 5.1: User State Experience Alignment (Complete)

5.1a: Anonymous Landing Page

• Landing controller: Cp::LandingController with champion/city stats
• Landing page view: Full-featured public page with:
  • Hero section with Bell Tower background and Belmont logo
  • “Your people are waiting.” headline with Sign In / Sign Up CTAs
  • “What is an Alumni Champion?” section with 3 pillars (Community Builders, Connectors, Ambassadors)
  • Social proof section with live champion count, city count, top cities
  • Final CTA section
• Routing: unauthenticated :cp_champion root now shows landing page

5.1b: Bug Fixes

• Community suggestions: Protected from email-verified (unverified) users
• Navigation access controls: Updated for “browse vs act” strategy
• Controller guards: All controllers verified for proper require_champion_verified! guards

5.1c: Community Show Page Messaging

• Eligibility messaging: Overhauled with 5 distinct states (eligible, member, pending, ineligible, error)
• “What you’ll find here” section: Replaces “Why join?” with value-focused copy
• Helper methods: community_connection_copy, community_private_copy for standardized messaging
• Language guide: Standardized copy patterns added to LANGUAGE_STYLE_GUIDE.md

---

Added - Phase 4: Mobile-First Interface Cleanup (Complete)

Mobile Consistency (4.1)

• Bottom nav overlap: Fixed globally with pb-20 sm:pb-0 padding pattern
• Profile wizard buttons: Fixed visibility on steps 3-6 that were hidden behind bottom nav
• Quick Actions: Moved from Dashboard to hamburger menu
• Header logo: Stacked layout until 1024px breakpoint for better mobile display

Design Alignment (4.2)

• Card margins: Standardized horizontal margins across all views
• Back links: Created _back_link.html.erb shared partial with consistent chevron pattern
• Pill navigation: Replaced dropdowns with scrollable pills for profile edit and settings
• Auto-scroll pills: Created scroll_to_selected_controller.js for selected pill visibility
• Save buttons: Applied w-full sm:w-auto pattern for mobile-first buttons
• Directory filters: Collapsible on mobile with “Filters (X)” toggle button

UX Polish & Image Optimization (4.3)

• Event list card redesign: Mobile: full-width 8:5 image on top; Desktop: w-48 thumbnail on right
• Dashboard column ordering: Events/District column shows first on mobile
• Image variant sizing audit: Fixed 7 files with variant/display size mismatches
  • _champion_card.html.erb: 64×64 → 56×56 (matches w-14)
  • directory/show.html.erb: 128×128 → 112×112 (matches sm:w-28)
  • events/show.html.erb: 800×500 → 800×450 (matches aspect-video 16:9)
  • _step_photo.html.erb: 200×200 → 160×160 (matches w-40)
  • _discussion_card_compact.html.erb: Square → rectangular variants
  • _event_card_compact.html.erb: Square → rectangular variants
  • _news_card_compact.html.erb: Square → rectangular variants
• Hero sections: Reduced heights to acceptable levels
• Message bubbles: Capped width at reasonable limit
• Long text truncation: Fixed awkward line breaks

Documentation

• DESIGN-GUIDELINES.md: Added §10 “Image Variant Sizing (Critical for Sharp Images)” with size reference table
• AGENTS.md: Added variant sizing principle with Tailwind reference sizes

---

Added - Phase 3: Discussion Boards (Complete)

Phase 3.6: National Alumni Champions Board

• National community: “Alumni Champions” with national: true flag for special behavior
• Auto-join membership: All verified Champions auto-join on verification, cannot leave
• Notification muting: Per-community notification muting in Settings → Notifications
• Community visibility: Hidden from non-verified Champions, visible in nav for verified
• Dashboard integration: Popular national board posts surfaced on dashboard
• Content defaults: News/events without community assignment default to National Board
• Staff pinning: Community Leaders can pin posts to national board

Phase 3.7: Discussion Notifications

• Notification triggers: Replies to posts, replies to comments, reactions added, community posts (for CL)
• In-app notifications: Discussion activity in dropdown with unread badge
• Email digests: Daily/weekly digest emails (configurable in Settings → Notifications)
• Notification types: discussion_reply, discussion_reaction, community_post
• User preferences: Email frequency (immediate, daily, weekly, off) per channel
• Blocked user filtering: Notifications from blocked users excluded from counts/display
• Digest background job: Heroku Scheduler integration for automated digest generation

Phase 3.8: Admin Discussion Analytics

• Admin dashboard: /insights/discussion_boards with comprehensive metrics
• Key metrics: Total posts, comments, active discussers, pending flags
• Trends: Posts/comments per week with sparkline charts
• Community breakdown: Top 5 communities by activity (posts + comments)
• Moderation stats: Flags by status (pending/resolved/dismissed) and action counts
• Period selector: This Week, This Month, This Quarter, All Time views
• Quick actions: Pending flags count links to moderation queue
• Service layer: EngagementStats::DiscussionBoardsService for metrics calculation (45+ tests)

Added - Phase 3.10 & 3.11: Index Page Reorganization & Dashboard Redesign

Index Page Redesign (3.10)

• News Index: Google News-style layout with featured + compact cards
• Events Index: Upcoming events with Google News layout, Past Events page with Load More
• Discussions Index: Cross-community “All Discussions” page (/discussions route)
• Compact card partials: _news_card_compact, _event_card_compact, _discussion_card_compact
• Event row partial: _event_row with date badge styling

Dashboard Redesign (3.11)

• “From Your Communities” section: Google News layouts for Discussions and News (1 featured + 3 compact)
• Events section: Date badge rows with community pills (using _event_row)
• Communities card: Combined with CL indicator (⭐), Leadership Dashboard button for CLs
• Community show page: Restructured to match dashboard (Google News layouts), width aligned to max-w-7xl
• Community index (“Community Select”): Complete redesign with My Communities grid, warm welcome box, You’re Invited section

Layout & Styling

• Background opacity: Increased to 0.8 for campus image visibility
• Footer visibility: Fixed with gradient overlay adjustments
• Consistent widths: All community pages now use max-w-7xl

Tests

• Updated tests for new page structure (h1/h2/h3 selectors)
• New Cp::DiscussionsController tests
• Full suite: 2267 tests, 0 failures

---

Added - Phase 3.9: Public Landing Pages

Public Access for Link Sharing

• Public event pages: Global events and events in public communities viewable without login
• Public discussion pages: Posts in public communities viewable without login
• Public community landing: Non-members see “What’s Happening Here” and “Why Join” sections
• Activity metrics: Public community view shows member count, posts, events (no personal details)

Conversion Features

• Reusable CTA component: _public_cta_box.html.erb with content-type-aware copy
  • Events: “🎉 Want to RSVP?”
  • Discussions: “💬 Join the conversation!”
  • Communities: “🏠 Find your Belmont home in {City}”
• Return path storage: Visitors redirected to original content after signup/login
• Consistent CTA width: All CTAs render at max-w-4xl (896px) regardless of page container

Helpers & Models

• MetaTagsHelper: Dynamic Open Graph and Twitter Card meta tags for rich link previews
• public_display_name: Champion model method returns “FirstName L.” format for privacy

UI Changes

• Help page moved to footer: Removed from main nav, now publicly accessible
• Event CTA icon: Changed from calendar to party popper emoji
• Public view conditionals: Hide RSVP buttons, comments, reactions for non-members

Tests

• 89 controller tests for public access (events, boards, communities, help)
• Full suite: 2263 tests, 0 failures

---

Added - Phase 3.4 & 3.5: User Safety & Moderation

User Safety Controls (3.4)

• Flag content: Report posts/comments with reason (spam, inappropriate, harassment, off-topic, other)
• Hide content: Hide specific posts/comments from personal view
• Block users: Hide all content from blocked users, prevent messaging
• Blocked notification filter: Notifications from blocked users excluded from count and dropdown

CLC Moderation (3.5)

• Moderation actions: Hide/unhide content, lock/unlock posts, pin/unpin posts
• Escalate to staff: Flag content for Engagement Team review
• Moderation queue: Shows only pending flags (resolved/dismissed excluded)
• Moderation counts synced: Leadership index, community dashboard, and queue all use consistent counting

Staff Moderation (3.5)

• Discussions admin: New /champions/discussions interface for staff
• Escalated tab: View content escalated by CLCs (unresolved only)
• All content tab: Browse all posts and comments
• Hidden/Deleted tabs: View moderated content
• Resolve escalations: Mark escalated content as handled
• Action items integration: Flagged + Escalated counts in navbar dropdown
• Sidebar badge: Shows unresolved escalation count

Documentation

• DISCUSSION_MODERATION.md: Comprehensive moderation system documentation
  • All models and data structures
  • Count calculation logic with code examples
  • All 7 UI touchpoints documented
  • Testing locations and workflow diagrams

Bug Fixes

• Fixed escalated count to exclude resolved escalations
• Fixed hidden filter to include posts with hidden comments
• Fixed CLC moderation queue to only show pending flags
• Fixed champion notification red dot to exclude blocked user messages

Tests

• All 2243 tests passing (0 failures, 0 errors)

---

Added - Phase 3.3: Engagement & Reactions

Reactions System

• Emoji reactions: 6 emoji options (👍 🎉 ❤️ 😂 🤔 👏) on posts and comments
• Horizontal bar UI: Messages-style emoji bar with reaction counts
• AJAX toggle: Turbo Streams for real-time reaction updates
• Activity tracking: reaction_added event for analytics

Popularity Sorting

• Popularity score: (reactions × 2) + (comments × 3) + (time_factor × 10) with 14-day decay
• Hot Discussions: Max 2 hot posts shown at top of discussion index (excluding pinned)
• Popular Discussions: Sorted by popularity on dashboard, community index, community show

New Files

• app/views/cp/boards/_reactions.html.erb — Reusable reaction bar partial
• app/views/cp/boards/_post_card.html.erb — Reusable post card with hot badge
• app/javascript/controllers/board_reactions_controller.js — Stimulus controller

Tests

• All 2173 tests passing (0 failures, 0 errors)

---

Added - Phase 3.2: Posting & Commenting

Posting Features

• New post form: Create discussions with title (100 char max), rich text body (40K), optional cover image
• Post editing: Edit within 30-minute window, “Edited” indicator shown after save
• Post deletion: Soft-delete within 30-minute window with confirmation
• Post truncation: Long posts show “See more” link on listing pages
• Community Guidelines reminder: Shown in post composer

Commenting Features

• Threaded replies: Comments with depth up to 2 levels (reply to reply)
• Comment editing: Edit within 30-minute window, “Edited” indicator shown
• Comment deletion: Soft-delete within 30-minute window with confirmation
• Character limit: 2,000 characters per comment

UI/UX Improvements

• Discussions in community cards: Featured discussions section in community index
• Discussion listing: Posts sorted by last activity with pagination
• Author identification: Photo, name, role badge, and relative timestamps

Help & FAQ

• 9 new FAQ entries added to Discussions category covering:
  • What are discussion boards?
  • Starting new discussions
  • Replying to posts and comments
  • Editing and deleting content
  • Locked and pinned posts
  • Emoji reactions
  • Content guidelines

Tests

• 20 new controller tests for BoardCommentsController
• Updated model tests for 100-character title limit
• All tests passing (2161 total, 0 failures)

---

Added - Phase 3.1: Discussion Boards Infrastructure

Database & Models

• 8 new database tables: cp_board_posts, cp_board_comments, cp_board_reactions, cp_post_flags, cp_user_blocks, cp_hidden_contents, cp_moderation_actions
• 7 new models: Cp::BoardPost, Cp::BoardComment, Cp::BoardReaction, Cp::PostFlag, Cp::UserBlock, Cp::HiddenContent, Cp::ModerationAction
• ActionText integration: Rich text for posts (40K character limit) and comments (2K limit)
• National communities: Added national boolean to cp_communities for auto-join behavior
• Community discussion toggle: Added discussion_board_enabled boolean to cp_communities

Controller & Views

• BoardsController: Read-only index and show actions for viewing discussions
• Board index view: Paginated post list sorted by last activity
• Post detail view: Threaded comments with depth indicators
• Community show enhancement: Discussions section with recent posts preview (Option C navigation)

Features

• National “Alumni Champions” community: Created via rake task (ID: 47) for cross-community discussions
• Activity tracking: New event types board_view and post_view for analytics
• Comment threading: Unlimited nesting with MAX_DEPTH = 2 for display
• Emoji reactions: 6 emoji options (❤️ 😂 😮 😢 😠 👍) with toggle functionality
• Content moderation infrastructure: Flag reasons, moderation actions with audit trail
• User safety controls: Block users, hide content (infrastructure ready for 3.2 UI)

Tests

• 112 new tests: 96 model tests + 16 controller tests
• All tests passing (2140 total, 0 failures)

---

Added - Phase 2.4 Enhancement: CL Assignment Improvements

Engagement Score Visibility in CL Assignment

• CL assignment page (/champions/community_leaders/new) now shows engagement scores for each champion
• Helps portal admins identify engaged members when selecting new Community Leaders
• Score badge displayed before CL badge using existing color-coded format

Community Leader Assignment Notification

• New notification type: community_leader_assigned
• When a champion is assigned as a Community Leader, they receive:
  • In-app notification: “You’re now a Community Leader! 🎉”
  • Immediate email: Sent right away (not batched in digest)
• Notification body: Includes welcome message and brief description of CL responsibilities (welcoming new members, fostering belonging)
• URL: Links to the community page
• Added to Cp::Notification::NOTIFICATION_TYPES and DEFAULT_EMAIL_FREQUENCIES
• New notify_community_leader_assigned(assignment:) method in Cp::NotificationService
• Test added for new notification type

---

Added - Phase 2.1 & 2.2: Community Leadership Foundation

Phase 2.1: Model Refactor

• ClcAssignment now links to Community instead of Region
• Migration: Added community_id column to cp_clc_assignments
• Migration: Removed region_id column (previously unused)
• Added unique constraint on [cp_champion_id, community_id] to prevent duplicate assignments
• Added assigned_at (auto-set) and assigned_by_id tracking columns
• Updated model associations and validations
• Updated all test fixtures

Phase 2.2: Admin CL Assignment Interface

• New route: /champions/community_leaders — List all CL assignments
• Filtering: By community type, specific community, or search by champion name/email
• Sorting: By champion name, community name, or assigned date
• Assign CL: From champion detail page or community detail page
• Remove CL: With confirmation dialog, redirects back to origin page
• Visual indicator: CL count shown in Members column on community index
• Authorization: Requires portal_admin or admin role

Improved - Contextual CL Assignment (Phase 2.2 Enhancement)

CL Assignment Now Requires Context

• Removed standalone “Assign Community Leader” button from CL index page
• CL assignments must now originate from either:
  1. Champion Detail → Assign as CL: Shows only communities the champion is already a member of
  2. Community Detail → Members List: Shows “Assign as CL” link next to each verified member

Multi-Select Capability

• CL assignment form now supports batch assignments via checkboxes
• From Champion context: Select multiple communities to assign champion as CL
• From Community context: Select multiple verified members to assign as CLs

Membership Enforcement

• Champions can only become CLs of communities they belong to
• Assignment form filters to show only eligible communities/members
• Clear messaging when no eligible assignments are available

Visual Improvements to Community Member List

• Added purple “Community Leader” badge for members who are already CLs
• Added “Assign as CL” link for verified members who aren’t yet CLs
• Links pass context to assignment form for seamless UX

Added - Profile Completion Visibility

Champion Show Page: Profile Completion Checklist

• New sidebar card: Shows which profile fields are complete/incomplete
• Weighted display: Shows field weights (Champion Role 25%, Location 20%, etc.)
• Visual indicators: Green checkmarks for complete, gray circles for incomplete
• Actionable: Incomplete items link to profile edit

Detailed Stats Page: Aggregate Profile Completion

• New section: Collective profile completion statistics for all verified Champions
• Per-field breakdown: Shows completion rate for each weighted field
• Progress bars: Color-coded (green 80%+, yellow 50-79%, red <50%)
• Average score: Overall average profile completion percentage

Bug Fix: Profile Completion Percentage Consistency

• Issue: List view showed different % than detail view for same champion
• Root cause: Two calculation methods existed (helper vs model)
• Fix: Consolidated on model method Cp::Champion#profile_completion_percentage
• Weights: Champion Role (25%), Location (20%), Work (20%), Affinities (15%), Photo (10%), Bio (10%)

Improved - Test Infrastructure

New bin/test Wrapper Script

• Stale process cleanup: Kills test processes running >5 minutes before starting new tests
• Database cleanup: Terminates idle PostgreSQL connections >5 minutes old
• Controlled parallelism: Uses 4 workers by default (was 8 with :number_of_processors)
• Environment variables: PARALLEL_WORKERS, TEST_TIMEOUT, SKIP_CLEANUP, MAX_STALE_MINUTES

Test Timeout Protection

• 30-second per-test timeout: Prevents indefinite hanging
• Configurable: Set TEST_TIMEOUT=60 for slower tests
• Clear failure message: Tells you to optimize or increase timeout

Database Pool Sizing

• Test pool now dynamic: PARALLEL_WORKERS + 2 connections
• Default: 6 connections for 4 workers (prevents connection exhaustion)

Technical Details

• Rewrote community_leaders_controller.rb new/create actions for multi-select
• Updated communities/show.html.erb member list with CL badges and assign links
• Added @existing_cl_champion_ids to communities controller show action
• Updated community_leaders/new.html.erb with dual-form structure (champion or community context)
• Removed “Assign Community Leader” button from community_leaders/index.html.erb
• Added calculate_profile_completion_stats to Stats controller
• Updated champions_helper.rb to delegate to model method
• Updated test_helper.rb with timeout and parallel worker configuration
• Created bin/test wrapper script with cleanup logic
• 21 controller tests, full test suite: 1962 tests, 0 failures, 0 errors

---

[1.0.23] - 2026-01-13

Fixed - OAuth “Remember Me” Layout Issue

Layout Bug in oauth_remember_choice View

• Issue: The “Remember Me for 30 days?” dialog was rendering with the Alumni Lookup layout instead of Champion Portal layout
• Symptom: JavaScript error “Missing target element ‘iconOpen’ for ‘navbar’ controller”
• Cause: OmniauthCallbacksController didn’t specify a layout, defaulting to application.html.erb (Alumni Lookup)
• Fix: Added layout 'champions' to OmniauthCallbacksController
• Result: Dialog now renders with correct Champion Portal styling and no JS errors

Files Changed

• app/controllers/cp/omniauth_callbacks_controller.rb: Added layout declaration

---

[1.0.22] - 2026-01-13

Added - Post-OAuth “Remember Me” Dialog

Session Timeout Improvements

• Increased default session timeout from 30 minutes to 2 hours of inactivity
  • Applies to all authentication methods (email/password and OAuth)
• Added “Remember Me” flow specifically for OAuth logins

Google OAuth “Stay Logged In?” Dialog

• After successful Google OAuth, Champions now see a friendly dialog asking if they want to “Remember Me for 30 days”
• Two options:
  • “Yes, Remember Me” → Sets 30-day persistent session (via remember_me cookie)
  • “Not Now” → Session expires after 2 hours of inactivity
• Solves UX issue where “Remember Me” checkbox was hard to see on OAuth flow
• Includes security note: “Only use Remember Me on private devices”

Technical Implementation

• Modified Cp::OmniauthCallbacksController:
  • handle_oauth() now stores champion ID in session and redirects to remember choice
  • New oauth_remember_choice() action shows the dialog (GET /oauth/remember-choice)
  • New oauth_confirm_signin() action completes signin with remember_me flag (POST /oauth/confirm-signin)
  • Uses session variables to carry authentication state between OAuth and signin
• Added routes for the new remember choice workflow
• New view: app/views/cp/omniauth_callbacks/oauth_remember_choice.html.erb
  • Warm, welcoming design with clear button options
  • Explanation of each choice’s implications

Files Modified:

• app/controllers/cp/omniauth_callbacks_controller.rb
• config/routes.rb
• config/initializers/devise.rb (timeout increase)
• New: app/views/cp/omniauth_callbacks/oauth_remember_choice.html.erb

Addresses: OAuth session timeout too short, unclear “Remember Me” UX for OAuth logins

---

[1.0.21] - 2026-01-12

Fixed - Notification Email URLs

NotificationMailer Improvements

• Added default_url_options method that reads CHAMPION_PORTAL_HOST from environment
• Added build_full_url helper to convert relative paths (stored in DB) to full URLs
• Fixes broken email links like http://dashboard/ → https://beta.alumnichampions.com/dashboard
• Fixes community links like http://communities/... → https://beta.alumnichampions.com/communities/...

Duplicate Email Prevention

• Added TYPES_WITH_DEDICATED_MAILERS constant to NotificationService
• Skip immediate NotificationMailer emails for join_request_approved and join_request_denied
• These types already have dedicated templates in CommunityMailer with better formatting
• Prevents duplicate emails when join requests are approved/denied

Files Modified:

• app/mailers/cp/notification_mailer.rb
• app/services/cp/notification_service.rb

---

[1.0.20] - 2026-01-10

Changed - Domain Migration (Jan 2026)

Domain Structure Migration

• Lookup Portal: *.bualum.co → alumnilookup.com (dev/beta/prod: dev.alumnilookup.com, beta.alumnilookup.com, alumnilookup.com)
• Champion Portal: *.bualum.co → alumnichampions.com (dev/beta/prod: dev.alumnichampions.com, beta.alumnichampions.com, alumnichampions.com)
• Email Domain: email.bualum.co → mail.alumnichampions.com

Files Updated

• Routing constraint in config/routes.rb — Now matches alumnichampions in host, champions.* prefix, or champions subdomain
• Test environment config config/environments/test.rb — Added host authorization for all test domains
• All configuration files, mailers, helpers, views, and documentation updated with new domain references
• GitHub Actions workflows updated for staging/production health checks

Migration Documentation

• Created docs/operations/DOMAIN_MIGRATION.md with complete migration checklist
• External services requiring updates: DNS, Heroku domains, Google OAuth, Mailgun

Added - Phase 1.16 Notifications System (Jan 2026)

Database & Models

• cp_notifications table with aggregation support (count, last_aggregated_at)
• cp_notification_preferences table for per-type settings (in_app_enabled, email_frequency)
• Cp::Notification model with scopes (unread, for_champion, recent_first)
• Cp::NotificationPreference model with DEFAULT_PREFERENCES for 9 notification types
• Champion model notification_preference_for(type) method

Notification Types

• new_message — New messages in threads (aggregates per thread)
• new_member — New members in your communities (aggregates per community)
• new_event — New events in your district
• community_suggestion — Suggested communities to join
• join_request_received — Someone requested to join your community (CLC only)
• join_request_approved — Your join request was approved (immediate email)
• join_request_denied — Your join request was denied (immediate email)
• verification_pending — Account verification in progress (immediate email)
• verification_approved — Account verified (immediate email)

Services & Jobs

• Cp::NotificationService with smart aggregation for high-volume types
• Cp::NotificationJob for async notification creation
• Cp::NotificationDigestJob for daily (7am) and weekly (Monday 7am) email digests
• Cp::NotificationCleanupJob for removing read notifications older than 30 days

Email System

• Cp::NotificationMailer with immediate_notification, daily_digest, weekly_digest
• HTML and text email templates for all digest types
• Immediate emails for critical notifications (join requests, verification)

Navbar UI

• Bell icon in header with unread dot indicator
• Dropdown panel showing recent notifications (10 max)
• Mark as read, mark all read, clear all actions
• notifications_controller.js Stimulus controller
• Cp::NotificationsHelper for icon/styling helpers

Settings Integration

• Per-type notification preferences in Settings → Notifications
• In-app toggle and email frequency dropdown per type
• 4 groups: Messages, Community, Join Requests, Account

Integration Updates

• MessagingService creates new_message notifications
• MessageNotificationJob updated to use new preferences model
• Updated settings controller and views for new preference system

Tests

• 1931 tests, 0 failures
• New tests for all notification components

Added - Phase 1.15.4 Message Link Previews & Sharing (Jan 2026)

Community Link Detection

• Cp::MessagesHelper with link detection and extraction methods
• contains_community_links? detects community URLs in message text
• extract_community_slugs extracts community slugs from URLs
• strip_community_urls removes URLs for clean display
• Supports production, dev, and path-only URLs

Community Cards in Messages

• _community_card.html.erb partial renders preview cards
• Cards show community name, type badge, member count, and thumbnail
• Automatic rendering for messages containing community links
• Visual indication of linked communities without cluttering message text

Share Community Feature

• “Invite a Champion” button on community pages
• “Copy Link” button with clipboard integration
• clipboard_controller.js Stimulus controller for copy functionality
• Share flow pre-fills message composer with community link
• community_share_message helper generates friendly share text

Invited Community Dashboard Prompt

• invited_community_id and invited_by_id columns on cp_champions
• Dashboard shows prompt when champion was invited to a community
• “Check out [Community]” card with inviter attribution
• Clears after champion visits the community

Tests

• 20 new helper tests in Cp::MessagesHelperTest
• All 1841 tests passing

Added - Phase 1.15.3 Expanded Membership Management (Jan 2026)

Terminology Update

• Replaced “CLC” with “Community Leader Council” throughout documentation and UI

Request to Join Infrastructure

• New cp_join_requests table for tracking join requests to private/custom communities
• Cp::JoinRequest model with pending/approved/denied status enum
• approve!(admin, note:) creates membership and sends approval email
• deny!(admin, note:) requires explanation and sends denial email
• Validation ensures admin_note required when denying requests

Membership Tracking

• Added source column to cp_champion_communities: self_joined, approved, auto_matched, admin_added, invitation
• Added added_by_id foreign key to track who added members
• Added soft-delete columns: removed_at, removed_by_id, removal_reason

Community Visibility

• Added visibility enum to communities (visibility_public, visibility_private)
• Added invite_token for private community invite links

Champion Portal

• “Request to Join” button for private/custom communities
• Pending request status display
• Cancel request functionality

Admin Portal

• Members tab: Full member list with add/remove functionality
• Join Requests tab: Queue with approve/deny actions
• Add member modal with champion autocomplete
• Deny request modal with required explanation field

Mailers

• Cp::CommunityMailer#join_request_submitted — Notifies Engagement Team
• Cp::CommunityMailer#join_request_approved — Notifies champion
• Cp::CommunityMailer#join_request_denied — Notifies champion with explanation

Tests

• 19 new JoinRequest model tests
• All 1779 tests passing

Added - Post-1.14 Dashboard & UI Enhancements (Jan 9, 2026)

Dashboard Restructure

• Sectioned feed with News, Events, and Discussions tabs
• Event cards show time with timezone, city/state in location, short descriptions
• Event thumbnails moved to right side with larger sizing
• Dashboard helper extract_city_state for parsing addresses
• Dashboard helper formatted_event_date_time using event’s formatted_time method

Site-Wide Background Image

• Added /public/bg-campus.jpg background image to Champion Portal layout
• Fixed position with z-index layering (z-0 background, z-10 content)
• 8% opacity, grayscale filter with gradient fade overlay
• Applies to all Champion Portal pages

Event Address Field Split

• New database columns: venue_street, venue_city, venue_state, venue_zip
• New Cp::Event methods: city_state, city_state_zip, full_address
• Updated admin event form with separate address fields
• Updated event show page to use full_address for display and Google Maps links

Community Pills Fix

• Fixed “Your Community” generic text in news/events views
• Now shows actual community names when communities.any?
• Shows “All Champions” badge when globally_visible? is true

Footer Branding Update

• Replaced text “Alumni Champions” with /public/logo-horizontal-reversed.svg logo
• Updated Alumni Champion icon SVG

Bug Fixes

• Fixed /directory?district=xxx parameter mismatch (now uses district_id)

Added - Phase 1.14 Dynamic Community Creation (Jan 9, 2026)

CommunityDetectionService (1.14.1)

• Automatic detection when 3+ verified Champions share an attribute
• Type-specific lookup using district_id, college_code, major_code, affinity_code, industry
• Automatic community creation with proper naming and slug generation
• Automatic member assignment for all qualifying Champions
• Notification generation for all members of new communities

CommunityCreationJob (1.14.2)

• Background job triggered after verification and profile edits
• Filters to specified community types for targeted detection
• Only processes verified Champions (status_champion_verified?)

CommunityNotification Model (1.14.3)

• cp_community_notifications table with Champion and Community references
• notification_type enum (currently threshold_reached)
• Read/unread tracking with timestamps
• Scopes: unread, recent, for_dashboard
• Class methods: create_threshold_notification!, notify_community_members!

Dashboard Integration (1.14.4)

• Notification banner when new communities are created
• Shows community name with link to landing page
• Dismiss and dismiss-all functionality via Turbo
• Activity tracking on dismiss (notification_dismissed event)

Hybrid Triggers (1.14.5)

• ChampionVerificationService → triggers college/major detection
• ProfileWizardController → triggers on location, profession, affinities steps
• ProfileController → triggers on location, profession, affinities section edits

Testing

• 55 new tests for Phase 1.14 features
• Full test suite: 1716 tests, 0 failures, 0 errors

Added - Phase 1.13 Community Landing Pages (Jan 8, 2026)

Community Show Page (1.13.1)

• Community landing pages at /communities/:slug
• Members grid with Turbo Stream pagination (12 per page)
• News section showing community-scoped posts
• Events section showing community-scoped events
• Activity tracking (community_view event)

Communities Index (1.13.2)

• Main communities page at /communities
• “My Communities” flat list (not grouped by type)
• “Suggested for You” section with suggestions
• “Explore All Communities” link to browse all
• Explore view grouped by community type

Dashboard Widget (1.13.3)

• Replaced “Community Snapshot” with “My Communities” widget
• Shows champion’s communities with quick links
• Suggestion teaser when no communities joined
• Empty state with “Explore Communities” CTA

Navigation Updates (1.13.4)

• New nav order: Communities

  Directory

  Messages

  [Name]

• Removed Dashboard from nav (logo links to Dashboard)
• Removed Events from main nav (accessed via communities)
• Updated desktop header and mobile bottom nav

Testing (1.13.5)

• Full test suite: 1661 tests, 0 failures, 0 errors
• Community controller: 21 tests
• Dashboard controller: 8 tests

Added - Phase 1.12 Community Foundation (Jan 8-9, 2026)

Database & Models (1.12.1-1.12.4)

• cp_communities table: 6 community types (district, college, major, affinity, industry, custom)
• cp_champion_communities join table: With counter cache for member counts
• cp_community_suggestions table: Suggestion-based community discovery model
• Cp::Community model: Type-specific validations, scopes, factory methods
• Cp::ChampionCommunity model: Counter cache pattern for member counts
• Cp::CommunitySuggestion model: accept!/decline! methods
• Cp::CommunityMatchingService: Profile-based community suggestion generation

Profile Hooks (1.12.4)

• Champion profile updates trigger community matching
• Affinity changes trigger community matching

News/Events Community Targeting (1.12.5)

• Community ID added to posts and events for targeting

Admin Communities UI (1.12.6)

• Lookup Portal admin index at /champion_admin/communities
• Community show page with members list and statistics
• Edit page for custom names, descriptions, thresholds, featured status

Champion Community UI (1.12.7)

• Champion-facing “My Communities” page at /communities
• Community show page with member list (members only)
• Join and leave community actions
• Accept/decline community suggestions
• Full test coverage: 29 tests, 74 assertions

Added - Phase 1.11 Admin Events (Jan 7-8, 2026)

Events System

• Database: cp_events table with full event support
  • Title, slug, dates (starts_at, ends_at), timezone
  • Location (venue_name, venue_address, is_virtual, virtual_url)
  • External RSVP link with customizable button text
  • Status workflow (draft → published → archived)
  • View counting and RSVP click tracking
• District Targeting: cp_event_districts join table (mirrors News pattern)
  • Events can be global (all Champions) or district-targeted
  • Consistent targeting model for future Phase 1.12 unification

Admin Interface (Lookup Portal)

• Champions::EventsController: Full CRUD for event management
• Index View: Filterable by status (all/draft/published/archived) and scope (global/targeted)
• Form: Rich text description, cover image upload, district autocomplete
• Stimulus Controllers: event_form, event_scope, event_districts for interactive form

Champion Portal

• Cp::EventsController: Index, show, rsvp_click actions
• Index View: Upcoming/past tabs, district filtering, responsive card layout
• Show View: Cover image with date badge, location info, RSVP tracking
• Activity Tracking: event_viewed and event_rsvp_clicked event types
• Navigation: Events link added to header (desktop + mobile) and Lookup Portal sidebar

Tests

• 37 model tests for Cp::Event
• 4 model tests for Cp::EventDistrict
• 19 controller tests for Cp::EventsController
• 7 event fixtures, 2 event_district fixtures

Files Created:

• db/migrate/*_create_cp_events.rb
• db/migrate/*_create_cp_event_districts.rb
• app/models/cp/event.rb
• app/models/cp/event_district.rb
• app/controllers/champions/events_controller.rb
• app/views/champions/events/*
• app/controllers/cp/events_controller.rb
• app/views/cp/events/*
• app/javascript/controllers/event_*.js (3 controllers)
• test/models/cp/event_test.rb
• test/models/cp/event_district_test.rb
• test/controllers/cp/events_controller_test.rb
• test/fixtures/cp/events.yml
• test/fixtures/cp/event_districts.yml

Fixed - Email Deliverability & Admin Notifications (Jan 6, 2026)

Email Domain Configuration

• From Addresses: Changed all mailers to use @mail.alumnichampions.com domain
  • Cp::ChampionMailer: champions@mail.alumnichampions.com
  • MessageMailer: champions@mail.alumnichampions.com
  • ApplicationMailer: noreply@mail.alumnichampions.com
  • Uses existing Mailgun configuration already set up in Squarespace DNS
  • Avoids CNAME conflict with alumnichampions.com (reserved for Heroku app)
• Environment Variable: Set MAILGUN_DOMAIN=mail.alumnichampions.com in Heroku

Admin Notifications Fix

• AdminNotificationMailer: Fixed admin_recipients query to properly find portal_admin and admin users
  • Changed from incorrect symbol array %i[portal_admin admin] to string array ['portal_admin', 'admin']
  • Now correctly matches User model’s enum role column
  • Ensures admins receive notifications for all new Champion signups (auto-verified or pending)

Added - Phase 1.10.3 News Display Enhancements (Jan 5, 2026)

Image Carousel

• Stimulus Controller: image_carousel_controller.js for multi-image posts
  • Previous/next arrow navigation
  • Dot indicators to jump to specific images
  • Image counter (e.g., “1 / 3”)
  • Touch/swipe support for mobile
  • Keyboard navigation (arrow keys)
• Show Page: Full carousel for posts with multiple images
  • Single image posts display without carousel UI
  • “Ghost image” technique for height stability
• Post Cards: Image count badge when multiple images exist

Admin Form Fixes

• Image Upload: Fixed drag-drop/paste/file-picker with multipart form
• District Autocomplete: Replaced checkboxes with searchable autocomplete
• Pin Icon: Fixed pin icon (was showing scales icon)
• Card Aspect Ratio: Changed from 16:9 to 4:3 for better image display

Files Created:

• app/javascript/controllers/image_carousel_controller.js

Files Modified:

• app/views/cp/news/show.html.erb — Added carousel for multiple images
• app/views/cp/news/_post_card.html.erb — Image count badge, aspect ratio, pin icon
• app/views/champions/news_posts/_form.html.erb — District autocomplete, multipart form
• app/javascript/controllers/news_post_images_controller.js — Drag-drop/paste support

---

Added - Phase 1.10.3 Champion Portal News Display (Jan 5, 2026)

Champion-Facing News System

• Controller: Cp::NewsController with index and show actions
• Views: News index (/news) and show pages (/news/:slug)
  • Post card partial for reuse on dashboard and index
  • Hero image display from hero_image method
  • Full content display via ActionText
  • External link button (opens new tab)
  • Pinned and regional scope badges
  • Empty state when no posts available
  • Paginated index (12 per page)
• Dashboard Integration: Real Cp::NewsPost records replace sample data
  • load_news_posts method using visible_to(champion) scope
  • “View all →” link to news index
• Analytics: View tracking with news_viewed activity event
  • Session-based deduplication prevents count inflation
  • Increments views_count counter cache
• Tests: 15 controller tests (1454 total project tests pass)

Files: app/controllers/cp/news_controller.rb, views in app/views/cp/news/

---

Added - Phase 1.10.2 Admin UI for News Posts (Jan 5, 2026)

Lookup Portal Admin Interface

• Controller: Settings::NewsPostsController with full CRUD + publish/unpublish
• Views: Index, new, edit pages with comprehensive form
  • Stats cards (total, published, drafts, archived)
  • Filters by status and scope
  • Search by title
  • ActionText/Trix editors for excerpt and full content
  • Region multi-select for regional posts
  • Publish/unpublish actions with confirmation dialogs
• Navigation: “Champion Portal” section in Settings sidebar
• Authorization: portal_admin and admin access via ensure_portal_admin!
• Tests: 19 controller tests (1439 total project tests pass)

Key fixes during implementation:

• Added inverse_of to news_post_regions association for proper nested builds
• Controller finds by slug (model overrides to_param)
• Form URL explicitly set to handle namespaced model class

Files: app/controllers/settings/news_posts_controller.rb, views in app/views/settings/news_posts/

---

Added - Phase 1.10.1 Database & Models (Jan 5, 2026)

News Post System Database Layer

• Migrations: 5 new tables for news posts system
  • cp_news_posts — Main posts table with ActionText, polymorphic author, counter caches
  • cp_news_post_regions — Join table for regional targeting
  • cp_news_post_likes — Champion likes with counter cache
  • cp_news_post_views — View tracking with source/referrer/duration
  • cp_clc_assignments — CLC role assignments to regions
• Models: Full implementation with associations, validations, scopes
  • Cp::NewsPost — Scopes: published, draft, global, regional, visible_to, for_region, pinned_first
  • Cp::NewsPostLike — Counter cache updates
  • Cp::NewsPostView — Source tracking (dashboard, email, search, etc.)
  • Cp::NewsPostRegion — Join model
  • Cp::ClcAssignment — CLC role management with Champion helper methods

• Champion CLC Methods: is_clc?, clc_for_region?(region), clc_region_names, clc_regions

• Tests: 55 new model tests (1420 total project tests pass)

Deferred (schema-ready, UI deferred): Image carousel, college/major/affinity tags, featured champions

---

Added - Phase 1.10 Planning Document (Jan 4, 2026)

Community News & Announcements Planning

Complete planning specification for admin-managed news/posts system with dashboard integration.

• Created: docs/planning/phases/phase-1/1.10-community-news.md
  • Full content model: posts, images, regional targeting, college/major/affinity tags
  • Admin architecture: Staff in Lookup Portal (global), CLCs in Champion Portal (regional)
  • Champion features: likes, view tracking, featured champions tagging
  • Dashboard integration with 3-card preview and regional badge
  • 6 implementation sub-phases (1.10.1-1.10.6)
  • Friendly URLs: /news/:id/:slug
  • “Your Community” hub vision for future regional content consolidation

Deferred to future phases (schema ready):

• Major/Affinity tag filtering UI
• Scheduled post publishing
• RSS feed for Belmont Stories
• Instagram API integration

Cross-references updated:

• app/controllers/champions/roadmap_controller.rb — Added 1.10 sub-phase
• docs/planning/phases/phase-1/README.md — Added 1.10 to table
• docs/planning/BACKLOG.md — Added 1.10 deferrals
• docs/planning/phases/phase-1/1.9-pre-beta-polish.md — Updated Phase 3.3 refs to 1.10
• docs/planning/development/DESIGN-GUIDELINES.md — Updated Phase 3.3 ref to 1.10

---

Added - Phase 1.9.5: Language & Messaging Audit (Jan 2026)

Language Style Guide

Comprehensive voice and tone guide for Champion Portal copy based on the Alumni Champions Verbal Style Guide.

• Created: docs/planning/development/LANGUAGE_STYLE_GUIDE.md
  • Thesis statement and tone pillars (invitational, illustrative, empowering, invested, informative, inspiring)
  • Messaging pillars (belonging, action, accessibility, celebration)
  • Key terms definitions (Champion, Bruin, Alumni Champions, Champion Portal)
  • Context-specific guidelines for UI elements, empty states, notifications
  • Words and phrases to avoid

Language Fixes

• Mailer Templates: Fixed “prospective students” in 4 templates
  • new_message_notification.html.erb → “Connect with fellow Bruins and grow our Champion community”
  • new_message_notification.text.erb → Same update
  • champion_mailer/invite.html.erb → “Share stories and celebrate wins”
  • champion_mailer/invite.text.erb → Same update
• Directory Empty State: “No champions found” → “No Champions match your search” with encouraging CTA
• Settings Flash Messages: Warmed up password and notification preference confirmations

Fixed

• Profile wizard completion now redirects to profile view instead of edit page

Files Created:

• docs/planning/development/LANGUAGE_STYLE_GUIDE.md

Files Modified:

• app/views/message_mailer/new_message_notification.html.erb
• app/views/message_mailer/new_message_notification.text.erb
• app/views/cp/champion_mailer/invite.html.erb
• app/views/cp/champion_mailer/invite.text.erb
• app/views/cp/directory/index.html.erb
• app/controllers/cp/settings_controller.rb
• app/controllers/cp/profile_wizard_controller.rb

---

Added - Phase 1.9.3: Profile Visual Refresh (Jan 1, 2026)

Directory Card Refresh

Simplified, scannable directory cards focused on connection.

• Card Design:
  • Belmont Blue accent bar on left edge
  • Large centered photo with role badge overlay
  • Prominent name and role display
  • Education with college SVG icons: [icon] degree_code Major (YYYY)
  • Truncated major text with tooltip, year always visible
  • Mobile-first responsive layout
• Education Display:
  • College icons from DirectoryHelper#college_icon_svg
  • SVG stroke-style icons matching site consistency
  • Format: [college icon] degree_code Major (YYYY)
  • Proper eager loading: includes(degrees: { major: :college })
• Profile Updates:
  • Contact info (email/phone) moved to Settings page
  • Profile header shows champion name, not “My Profile”
  • Synced My Profile and Public Profile education format
  • Removed industry/role filters from directory

Files Modified:

• app/views/cp/directory/_champion_card.html.erb
• app/views/cp/directory/index.html.erb
• app/views/cp/profile/show.html.erb
• app/views/cp/directory/show.html.erb
• app/helpers/cp/directory_helper.rb

---

Added - Phase 1.9.2: Help & FAQ with Onboarding Tooltips (Dec 25, 2025)

Help Center & FAQ

Self-service help resources for Champions to find answers without contacting support.

• Help Page:
  • /help route with comprehensive FAQ
  • 6 organized categories:
    • Getting Started (verification, Champion role)
    • Your Profile (privacy, photo uploads)
    • Finding Alumni (directory search, filters)
    • Messaging (conversations, notifications)
    • Account & Settings (email, password, connections)
    • Community Guidelines (rules, reporting)
  • Expandable accordion UI (accordion_controller.js)
  • Real-time FAQ search (faq_search_controller.js)
  • “Still need help?” link to alumni@belmont.edu
  • All FAQ content in config/faq.yml

Onboarding Tooltips

Context-sensitive tooltips guide new Champions through key features.

• Tooltip System:
  • seen_tooltips JSONB column tracks dismissed tooltips per Champion
  • Champion model methods: tooltip_seen?, mark_tooltip_seen!, pending_tooltips, tooltip_for
  • Cp::TooltipsController with dismiss endpoint (POST /tooltips/:key/dismiss)
  • Activity tracking: tooltip_dismissed events for analytics
  • 29 tests covering tooltip behavior and persistence
• Tooltip Infrastructure:
  • onboarding_tooltip_controller.js — Stimulus controller for display/dismiss
  • Auto-display after 500ms delay
  • Position support (top/bottom/left/right)
  • Smooth fade-in/out animations
  • Action button navigation
  • AJAX persistence on dismiss
  • Cp::TooltipsHelper for easy view integration
• Initial Tooltips:
  • Dashboard: “Complete your profile” (on incomplete profiles)
  • Directory: “Find Champions in your city” (first search)
  • Profile Edit: “Control who sees your contact info” (privacy settings)
  • Messages: “Your message was sent!” (messaging intro)

Files Added:

• config/faq.yml — FAQ content and tooltip definitions
• app/controllers/cp/help_controller.rb
• app/views/cp/help/index.html.erb
• app/javascript/controllers/accordion_controller.js
• app/javascript/controllers/faq_search_controller.js
• app/javascript/controllers/onboarding_tooltip_controller.js
• app/controllers/cp/tooltips_controller.rb
• app/helpers/cp/tooltips_helper.rb
• db/migrate/20251225172229_add_seen_tooltips_to_cp_champions.rb
• test/controllers/cp/help_controller_test.rb
• test/models/cp/champion_tooltip_test.rb
• test/controllers/cp/tooltips_controller_test.rb

---

[1.0.18] - 2025-12-23

Added - Phase 1.8: Admin Dashboard & Engagement Scoring (Dec 23, 2025)

Champions Admin Dashboard

Complete admin interface for managing the Champion program with visibility into Champion activity and engagement.

• Champion Management:
  • /champions — Staff dashboard listing all Champions
  • /champions/:id — Detailed Champion profile view with complete activity timeline
  • Search Champions by name or email
  • Filter by verification status, primary role, or district
  • Sort by signup date or last name
  • Searchable/filterable Champions list with pagination (25 per page)
• Admin Features:
  • Impersonation: “Log in as [Champion]” for testing/support (secure token-based)
  • Environment banners (dev/staging/impersonation) for context
  • Domain-specific routing (admin portal ↔ champion portal)
  • One-click link to verification queue for unverified Champions

Engagement Scoring System

New activity-based scoring to measure Champion engagement and identify active community members.

• Scoring Service:
  • Cp::EngagementScoreService — Reusable service for score calculation
  • Point values for 8 activity types:
    • 5 pts: Logins, Conversations Started, Invites Sent
    • 3 pts: Profile Edits, Messages Sent
    • 1 pt: Profile Views, Message Reactions
    • 0.5 pts: Directory Searches
  • Support for date-range filtering (“score since 1 month ago”)
  • Activity breakdown by type with counts and points
• Admin Visibility:
  • Engagement column in Champions list (color-coded badge)
  • Engagement Score card on Champion detail view
  • Engagement levels: Highly Engaged (100+), Engaged (50-99), Active (10-49), New/Inactive (<10)
  • Human-readable score formatting (e.g., “245.5 pts”, “1.2k pts”)
• Extensibility:
  • Simple pattern for adding new activities (3 steps: define event, add points, record activity)
  • Comprehensive documentation: docs/features/champion_portal/ENGAGEMENT_SCORING.md
  • Service-based architecture allows future enhancements (trending, percentiles, leaderboards)
• Testing:
  • 8 comprehensive service tests covering all scenarios
  • Tests for zero scores, date filtering, breakdown calculations
  • Point value verification for all activity types

Dashboard Features

• Stats Cards (Top of Dashboard):
  • Total Champions (verified)
  • Total Engagement (aggregate score across all Champions)
  • New Champions this month
  • Messages exchanged
• Recent Activity (Timeline):
  • Last 10 activities across all Champions
  • Activity types: signups, logins, verifications, messages, profile updates
  • Timestamps and actor names

Visual/UX Improvements

• Profile completion percentage calculation (10 core fields)
• Progress bar + color-coded completion badges (green/blue/yellow/red)
• Verification status badges for each Champion
• Color-coded engagement badges based on score ranges
• Responsive table design for mobile/tablet viewing

Changed

• Champions namespace routes reorganized for admin access
• ensure_portal_admin! guard for dashboard access (staff, portal_admin, admin roles)
• Environment-aware routing helpers for cross-domain links

Documentation

• Created docs/features/champion_portal/ENGAGEMENT_SCORING.md — Complete guide to engagement system
  • Current point values and philosophy
  • How to add new activities (3-step pattern)
  • Usage examples and testing
  • Architecture and caching opportunities

---

[1.0.17] - 2025-12-22

Added - Phase 1.7: In-App Messaging (Dec 22, 2025)

Messaging System

Complete 1:1 messaging system for Champions to communicate within the portal.

• Database Tables:
  • cp_message_threads — Conversation containers with message count tracking
  • cp_message_thread_participants — Per-user thread state (read, muted, archived)
  • cp_messages — Individual messages with soft delete support
  • cp_message_reactions — Emoji reactions on messages
• Controllers & Views:
  • Cp::MessagesController — Full CRUD for messaging (index, show, new, create, reactions)
  • Inbox view with unread badges and conversation previews
  • Thread view with emoji reactions (❤️ 😂 😮 😢 😠 👍)
  • Compose modal accessible from directory profiles
• Services:
  • Cp::MessagingService — Thread management, message sending, reactions
  • MessageNotificationJob — Background job for 5-minute delayed email notifications
  • MessageMailer — Email templates for message notifications
• Features:
  • Start conversation from Champion directory profile cards
  • Emoji reactions with optimistic UI updates
  • Unread message count in header badge
  • Auto-mark-as-read when viewing thread
  • Mute and archive thread controls
  • Smart notifications (email only if unread after 5 minutes)
• Analytics:
  • Activity event tracking for message_thread_started and message_sent

Champion Profile Enhancements

• Timezone Support: Champions can set timezone for message timestamp display
• International Location: Champions outside US can enter country/city text
• Profile Wizard: Added location step with domestic/international toggle

Changed

• Header navigation now includes Messages link with unread badge
• Directory profile cards include “Send Message” button for verified champions
• Activity events now include messaging types

---

Added

• Champion dashboard now uses a unified community snapshot with verified-only counts.
• District preview cards now show degree/class year with smart fallbacks.
• District preview includes a ZIP prompt, verification messaging, and pre-filtered directory link.
• Own-profile banner on public profile view with an Edit Profile shortcut.
• Champion directory filters now include graduation year multi-select (decade toggles), college, district autocomplete, and affinity typeahead.
• Champion directory now supports sorting by recently joined.
• Affinity API now supports query-based typeahead for directory filtering.

Changed

• Dashboard copy now uses alumni-first language instead of repeating “Champion.”
• Profile view now emphasizes the editable profile with section edit links, and the public view banner links back to the editable profile.
• District-based lists and filters now exclude alumni who hide location details.
• Privacy “district only” visibility now matches on district for email, location, and contact preferences.
• Privacy settings no longer include a phone visibility option.
• Directory “recent” sort now uses verified_at, and region/city filters have been removed.
• District autocomplete can submit district IDs as well as legacy codes.

Fixed

• Public profile header now hides district/city when location privacy is set to hidden.
• Directory region and district filters now exclude hidden-location alumni and respect district-only visibility.

Fixed

• Champion Role wizard quiz links now navigate to the quiz flow.
• Champion Role wizard step now persists selected roles on continue.
• Confirmation password form now shows inline validation errors for mismatched/invalid passwords.
• Changing a champion ZIP now updates city/state from the ZIP lookup.
• ZIP changes now clear stale district/city/state when no ZIP lookup is found.

Added - Phase 1.5: Admin Verification & District Management (Dec 19, 2025)

Champions Namespace (/champions)

New Portal Admin section for Champion Program management with dedicated layout and navigation.

• Champions::BaseController — Base controller with ensure_portal_admin! guard
• Champions::ChampionsController — Dashboard with quick stats, verification funnel, regional breakdown
• Champions::VerificationsController — Queue for verifying champions by linking to alumni BUID
  • Index shows pending champions (with/without suggested matches)
  • Show displays champion details + pending alumni match
  • Approve: Links pending_buid and sets champion_verified status
  • Reject: Clears pending_buid, keeps champion in queue for manual search
  • Search alumni: AJAX search by name, email, or BUID (Turbo Frame)
  • Link BUID: Manual verification by selecting alumni record
• Champions::StatsController — Placeholder for detailed statistics (Phase 1B/6)
• layouts/champion_admin.html.erb — Dedicated layout with sidebar navigation
• champions/_sidebar.html.erb — Navigation with pending count badge

Routes Added:

• GET /champions → Dashboard
• GET /champions/verifications → Verification queue
• GET /champions/verifications/:id → Review champion
• POST /champions/verifications/:id/approve → Approve pending match
• POST /champions/verifications/:id/reject → Reject pending match
• GET /champions/verifications/:id/search_alumni → AJAX search
• POST /champions/verifications/:id/link_buid → Manual BUID link
• GET /champions/stats → Statistics page

District Management (Settings > Reference Data)

Admin-only interface for managing geographic districts.

• Settings::DistrictsController — Index, edit, update, toggle_highlighted, load_more
• Features:
  • View all 820 districts grouped by region (default) or flat list
  • Filter by region, highlighted status, search by name
  • Sort by name, alumni count, or champions count
  • Edit district display name (preserves original csv_name for imports)
  • Toggle highlighted status (star icon)
  • Pagination with “Load more” button using Turbo Stream
  • Real-time alumni/champions counts per district
• Performance: Single optimized SQL query for alumni counts instead of N+1

Routes Added:

• GET /settings/districts → District list
• GET /settings/districts/load_more → Paginated load (Turbo Stream)
• GET /settings/districts/:id/edit → Edit form
• PATCH /settings/districts/:id → Update district
• PATCH /settings/districts/:id/toggle_highlighted → Toggle highlight

Files Created:

• app/controllers/champions/base_controller.rb
• app/controllers/champions/champions_controller.rb
• app/controllers/champions/verifications_controller.rb
• app/controllers/champions/stats_controller.rb
• app/controllers/settings/districts_controller.rb
• app/views/champions/_sidebar.html.erb
• app/views/champions/champions/index.html.erb
• app/views/champions/verifications/index.html.erb
• app/views/champions/verifications/show.html.erb
• app/views/champions/verifications/search_alumni.html.erb
• app/views/champions/verifications/_search_results.html.erb
• app/views/champions/stats/index.html.erb
• app/views/layouts/champion_admin.html.erb
• app/views/settings/districts/index.html.erb
• app/views/settings/districts/edit.html.erb
• app/views/settings/districts/_district_rows.html.erb
• app/views/settings/districts/_empty_state.html.erb
• app/views/settings/districts/load_more.turbo_stream.erb
• app/javascript/controllers/champion_admin_sidebar_controller.js
• test/controllers/champions/verifications_controller_test.rb (18 tests)
• test/controllers/settings/districts_controller_test.rb (23 tests)

Lessons Learned:

• Turbo Stream vs Turbo Frame: For “Load more” functionality, use data: { turbo_stream: true } on links (not data: { turbo_frame: "..." }) to ensure proper Accept: text/vnd.turbo-stream.html header
• Pagination > Lazy Loading: When sorting depends on counts, pre-calculate all counts and paginate rather than lazy-loading counts per row
• SQL Optimization: Single JOIN query for counts is faster than N+1 queries per district

---

[1.0.16] - 2025-12-18

Changed - Settings Navigation Order & Batch Search Enhancements (Dec 18, 2025)

Settings Navigation Reorganization

• Swapped “Data Imports” and “Reference Data” sections in Settings
• Data Imports now appears first, aligning with typical workflow (import first, then manage reference data)
• Updated both desktop and sidebar navigation
• Files Changed:
  • app/views/settings/settings/index.html.erb — Reordered sections
  • app/views/settings/_sidebar.html.erb — Reordered sections

Batch Search Enhancement Ideas Added to Backlog

• Documented 6 potential enhancements for future phases
• Includes features like advanced filters, saved searches, export functionality
• See docs/planning/BACKLOG.md for full details

---

Changed - Tools Namespace & Profile Layout Fix (Dec 18, 2025)

New Tools Namespace

Created /tools namespace for staff-accessible utilities, separating them from admin-only Settings:

• Tools::BaseController — Base controller with ensure_staff! authorization
• /tools — Landing page with tool cards
• /tools/batch_search — Moved from /batch_search
• /tools/event_converter — Moved from /settings/event_converter

Why: Staff could access Event Converter in Settings but saw admin-only sidebar items (Settings, Users, Data Imports) which they couldn’t access. Now Tools has its own layout with staff-appropriate navigation.

Profile Layout Fix

• Non-admin users editing their profile (/profile/edit) now see the regular application layout
• Admins editing users in Settings (/settings/users/:id/edit) still see the settings layout
• Implemented via determine_layout method in Settings::UsersController

Navbar Update

• Consolidated “Search” section into “Tools” dropdown
• Tools dropdown now contains: Batch Search, Event Converter

Files Changed

• app/controllers/tools/base_controller.rb — NEW
• app/controllers/tools/tools_controller.rb — NEW
• app/controllers/tools/batch_search_controller.rb — Moved from batch_search_controller.rb
• app/controllers/tools/event_converter_controller.rb — Moved from settings/event_converter_controller.rb
• app/views/layouts/tools.html.erb — NEW (tools layout with sidebar)
• app/views/tools/_sidebar.html.erb — NEW
• app/views/tools/tools/index.html.erb — NEW (landing page)
• app/views/tools/batch_search/* — Moved from batch_search/
• app/views/tools/event_converter/* — Moved from settings/event_converter/
• app/controllers/settings/users_controller.rb — Added determine_layout method
• app/views/layouts/_navbar.html.erb — Updated Tools dropdown
• app/views/settings/_sidebar.html.erb — Removed Tools section
• app/views/settings/settings/index.html.erb — Added “Go to Tools” link
• config/routes.rb — Added tools namespace routes

Route Changes

| Old Route | New Route | |———–|———–| | /batch_search | /tools/batch_search | | /settings/event_converter/new | /tools/event_converter/new | | N/A | /tools (landing page) |

---

Changed - Settings UI Modernization & Users Namespace (Dec 17, 2025)

Users Controller Moved to Settings Namespace

• Moved UsersController to Settings::UsersController
• Users management now at /settings/users (consistent with other settings pages)
• Updated all path helpers: users_path → settings_users_path, etc.
• Profile edit still accessible via /profile/edit

Modern UI Design for Settings Pages

Applied consistent modern design across all Settings pages:

• Rounded-xl cards with ring-1 ring-gray-900/5 shadows
• Gradient icon backgrounds for visual hierarchy
• Hover states and transitions throughout
• Section headers with colored icon badges

Pages Updated

• Settings Dashboard (/settings) — Redesigned with sectioned card layout
• Users Index (/settings/users) — Added avatars, role badges (Admin/Portal Admin/Staff), Google auth indicators
• User Form — Card-based form with sections, modern input styling
• Engagement Activities — Level-grouped breakdown with activity counts

Development Environment

• Added wildcard SSL certificate generation for *.alumnilookup.com
• Updated Procfile.dev to use wildcard certificate (fixes SSL errors for both subdomains)

Files Changed

• app/controllers/settings/users_controller.rb — NEW (moved from app/controllers/users_controller.rb)
• app/views/settings/users/ — Moved from app/views/users/
• config/routes.rb — Added resources :users to settings namespace
• app/views/settings/settings/index.html.erb — Modern card design
• app/views/settings/users/index.html.erb — Modern table with avatars, badges
• app/views/settings/users/_form.html.erb — Card-based form design
• app/views/settings/engagement_activities/index.html.erb — Level-grouped breakdown
• Procfile.dev — Updated SSL certificate paths

Documentation Updated

• docs/development/AUTHENTICATION.md — Updated UsersController references
• docs/development/PERMISSIONS_MATRIX.md — Updated controller names
• docs/development/TESTING_GUIDE.md — Updated path helper examples
• docs/features/AUTH_AND_ROLES_SYSTEM.md — Updated file references

---

Added - Portal Admin Role & Navigation Reorganization (Dec 16, 2025)

New Portal Admin Role

• Added portal_admin role to User model (between staff and admin)
• Added portal_admin? helper method for authorization checks
• Added ensure_portal_admin! guard in ApplicationController
• Role hierarchy: staff → portal_admin → admin

Role Permissions

| Role | Capabilities | |——|————-| | staff | Search, Insights, Tools, Champion Signups (view/edit) | | portal_admin | Staff + delete/merge signups, Champion Verification (future), Champion Metrics (future) | | admin | Full access including Settings, User Management, Data Imports |

Navigation Menu Reorganization

Reorganized Lookup Portal hamburger menu with clear sections:

• Search: Search Alumni, Batch Search
• Insights: Engagement Stats, Degree Stats, Top Engaged Alumni
• Tools: Event Converter
• Champion Program: Champion Signups, Verification (Coming Soon), Metrics (Coming Soon)
• Admin: Users, Engagement Activities, Alumni Degrees, Affinaquest Import, Colleges, Majors, Affinities
• Account: Your Profile, Sign Out

Controller Changes

• ChampionSignupsController: Delete/merge actions now use ensure_portal_admin! (was ensure_admin!)
• EngagementStatsController: Cache clearing now available to all staff (was admin-only)

Files Modified

• app/models/user.rb — Added portal_admin role and portal_admin? helper
• app/controllers/application_controller.rb — Added ensure_portal_admin! guard
• app/controllers/champion_signups_controller.rb — Changed to ensure_portal_admin!
• app/controllers/engagement_stats_controller.rb — Removed admin restriction on cache clearing
• app/views/layouts/_navbar.html.erb — Reorganized menu structure

Documentation Updated

• docs/development/PERMISSIONS_MATRIX.md — Added portal_admin role documentation
• docs/features/AUTH_AND_ROLES_SYSTEM.md — Added Phase 7: Portal Admin Role
• docs/planning/phases/PHASE-1.md — Updated Sub-Phase 1.5 prerequisites
• .github/copilot-instructions.md — Added role hierarchy, pause point instructions

---

[1.0.15] - 2025-12-16

Added - Banner CSV Importer (Dec 16, 2025)

New Banner Import Feature

• New import workflow for Banner JH-0026c (SHRDGMR) and Commencement Regalia CSV files
• Supports preview/commit pattern - review changes before importing
• Creates both Alumni and Degree records in a single import

Column Mappings

• Alumni fields: BUID, First/FirstName, Last/LastName, PrefName
• Degree fields: DegreeCode/Degree1, Major1Code/Major1Deg1, GradDate
• Email fields:
  • CAMP_Email → email_school
  • PERS_Email → email_personal
• Phone: Combines CP_Area_Code + CP_Phone_Number (ignores PR_* fields)
• Location: City, State from various column formats

Grad Date Override Option

• Optional date picker on upload form for Commencement CSVs that lack graduation dates
• Override applies to all rows in the import

Non-Destructive Updates

• Existing alumni: Only fills blank fields, never overwrites existing data
• Duplicate degree detection: Skips degrees that already exist (buid + degree_code + major_code)

Files Added

• app/services/csv/banner_importer.rb - Import service with column mapping
• app/views/settings/alumni/upload_banner.html.erb - Upload form
• app/views/settings/alumni/import_banner_preview.html.erb - Preview page
• test/services/csv/banner_importer_test.rb - 24 service tests
• test/controllers/settings/alumni_controller_banner_test.rb - 9 controller tests

Routes Added

• GET /settings/upload_banner - Upload form
• POST /settings/import_banner_preview - Preview import
• POST /settings/import_banner_commit - Commit import

---

Security - Alumni Match Verification Fix (Dec 16, 2025)

Problem Fixed

• Critical Security Issue: Name-based alumni matches were auto-linking BUID and auto-verifying champions, allowing potential identity spoofing
• A bad actor could verify their email, then claim to be a different alumnus by selecting their name match

New Behavior

• Email matches: Auto-link BUID + auto-verify (high confidence, unchanged)
• Name matches: Store as pending_buid for staff review, do NOT auto-link or auto-verify
• Alumni location data from pending matches still used for ZIP code suggestion (convenience without security risk)

Database Changes

• Added pending_buid column to cp_champions - stores BUID selected by champion awaiting staff verification
• Added pending_buid_match_type column - stores how match was found (‘email’ or ‘name’)
• Added index on pending_buid for finding champions needing verification

Model Changes

• Added pending_alumni method to Cp::Champion - returns Alumni record for pending_buid

Tests Added

• Email match auto-links BUID and auto-verifies
• Name match stores pending_buid but does not auto-link
• Location step uses pending_alumni for ZIP suggestion
• pending_alumni method tests

---

Added - Profile Completion Weighted Scoring (Dec 16, 2025)

Weighted Profile Completion

• Replaced simple percentage (5 areas × 20%) with weighted scoring system
• Weights reflect importance: Champion Role (25), Location (20), Work (20), Affinities (15), Photo (10), Bio (10)
• 80 points threshold for “complete” status
• New model methods:
  • profile_completion_percentage - returns 0-100 weighted score
  • profile_completion_details - returns hash with status per area
  • incomplete_profile_areas - returns array of missing areas sorted by priority
  • Individual checks: has_champion_role?, has_work_info?, has_affinities?, has_bio?

Smart Redirect Logic

• After wizard completion, redirects based on score:
  • 80+ pts → Dashboard with “complete” message
  • 60-79 pts → Profile edit with encouraging message
  • < 60 pts → Profile edit with progress message
• Sign-in flow uses same three-way logic

Site-Wide Profile Completion Prompt

• New dismissable banner for incomplete profiles (< 80 pts)
• Shows on all pages except profile/wizard pages
• Displays highest-priority missing area with contextual message
• Uses dismissable_controller.js Stimulus controller
• Dismisses for current day (sessionStorage)

Profile Completion Banner Updates

• Uses weighted scoring to determine what to display
• Shows priority-ordered missing areas
• Updated messaging to match new areas

---

Added - Champion Portal Name Field UX & Alumni Matching (Dec 15, 2025)

Legal First Name Field

• Added legal_first_name column to cp_champions table
• Checkbox-driven UX: “My legal first name is different” reveals field
• Field only stored when different from first_name
• normalize_names callback clears legal_first_name if matches first_name

Help Us Find You Wizard Step

• New conditional step shown FIRST when no alumni match found
• Collects legal_first_name and college_last_name to improve matching
• After submission, re-checks for alumni matches with all name fields
• Redirects to confirm_education if match now found

Enhanced Alumni Matching Algorithm

• find_potential_alumni_matches now uses ALL name fields:
  • first_name OR legal_first_name matched against alumni first_name/pref_name
  • last_name OR college_last_name matched against alumni last_name/maiden_name
• Generates OR conditions for all first name × last name combinations

Champion-to-Alumni Sync Service

• New Cp::SyncChampionToAlumni service for syncing data to Alumni records
• Name sync rules: if legal_first_name present → alumni.first_name=legal, alumni.pref_name=first
• All changes logged to CrmDataChange for Affinaquest export

New Files

• app/javascript/controllers/name_checkbox_controller.js - Stimulus controller for checkbox toggle
• app/views/cp/profile_wizard/_step_help_find_you.html.erb - Help find you step view
• app/services/cp/sync_champion_to_alumni.rb - Champion-to-Alumni sync service
• docs/features/champion_portal/NAME_FIELDS_AND_EXPORT_MAPPING.md - Field mapping documentation

Bug Fixes

• Fixed CrmDataChange#cp_champion association missing class_name: "Cp::Champion"

---

Fixed - Profile Wizard Bug Fixes (Dec 15, 2025)

Education Confirmation Security

• Only show alumni names when email is verified (match_type == :email)
• Name-based matches show degrees only to prevent information disclosure

Location Step Interactive Confirmation

• Added “Is this still your location?” yes/no UI when alumni record exists
• Uses ZipCode lookup as fallback when alumni city/state fields are blank
• New location_confirm_controller.js Stimulus controller

Affinities Step Fixes

• Fixed missing closing </div> tags causing broken navigation
• Added missing continue/skip buttons
• Clear search field when affinity is selected
• Fixed JS error: filterAffinities() now accepts optional event parameter

Progress Indicator Fixes

• Added Champion Role step to progress indicator (was missing from array)
• Added :sparkles icon case for Champion Role step

Wizard Completion Redirect

• Email confirmation now redirects to wizard instead of dashboard when wizard_completed_at.blank?

Champion Role Step

• Added @roles = champion_roles to load_step_data (was returning nil)

Name Normalization

• Added before_save :normalize_names callback to Champion model
• Syncs first_name ↔ pref_first_name when one is blank

Misc Fixes

• Removed “Already completed? Continue to dashboard” link from wizard
• Removed name preview box from basic info step
• Moved About Me field to dedicated profile edit tab

---

Added - Profile Wizard & Edit Profile Refactoring

New Wizard Flow (7 Steps)

• Step 1: Confirm Education — Only shown if alumni match exists
  • Displays matched alumni record for confirmation
  • Skip button if match is incorrect
• Step 2: Location — New dedicated location step
  • Street address, city, state, ZIP code fields
  • Removed ZIP from signup form (now part of wizard)
• Step 3: Profession — Renamed from “professional”
  • Industry dropdown (20+ options)
  • Job title and company fields
  • LinkedIn URL field
• Step 4: Photo — Profile photo upload
  • Drag-and-drop or click to upload
  • File size and type validation
• Step 5: Affinities — Enhanced searchable affinity selector
  • Type-to-search filtering
  • Category dropdown for browsing by type
  • Visual checkmarks for selected affinities
  • Selected items display as removable chips
  • “Suggest a new affinity” modal with AJAX POST
• Step 6: Privacy — New final step
  • Email visibility toggle (Public, Alumni Only, Hidden)
  • Location display toggle
  • Career info visibility toggle
  • Clear explanations for each setting

Champion Portal Auth Flow Updates

• Removed ZIP from signup — Cleaner initial registration
• Updated redirect logic — Uses needs_profile_wizard? instead of zip_code.blank?
• Wizard completion tracking — New wizard_completed_at timestamp column

Affinity Suggestions

• New cp_affinity_suggestions table — Stores champion-submitted suggestions
  • Fields: champion_id, suggested_name, category, reviewed, approved_at
• New Cp::AffinitySuggestion model — Validates and stores suggestions
• New suggest-affinity endpoint — POST /profile/wizard/suggest-affinity

Edit Profile Updates

• New section structure — Matches wizard steps
  • Sections: basic_info, champion_role, location, profession, affinities, photo, privacy
• Section aliases — Backward compatibility for old URLs
  • location_contact → location
  • professional → profession
• Updated sidebar — New icons and sections including Privacy

Test Updates

• 914 tests passing (0 failures, 0 errors)
• Updated fixtures with wizard_completed_at values
• New tests for privacy step and wizard flow
• Updated controller tests for new section names

---

Added - Champion Portal Phase 1C (Champion Role Selection & Quiz)

SubPhase 1C.1: Service Extraction

• ChampionRoleService — Single source of truth for 4 champion roles
  • Connection Advisor (🤝), Digital Ambassador (🙌), Community Builder (👋), Giving Advocate (🙏)
  • Metadata includes title, description, detailed activities, colors
  • narrative_for generates personalized role descriptions
• ChampionQuizService — 7-question role discovery quiz
  • Answer scoring algorithm maps responses to role recommendations
  • calculate_primary_role finds most frequent match
  • generate_results returns primary role, all roles with percentages, narrative
• Test Coverage — 42 new tests (24 role service + 18 quiz service)

SubPhase 1C.2: Profile Wizard Integration

• Champion Role Selection in Profile Wizard — Integrated role discovery into onboarding
  • Added champion_role step as 2nd step in wizard (after basic_info)
  • Role selection page with 4 role cards showing emoji, title, and description
  • “Take the Quiz” option to discover role through 7-question assessment
  • Manual role selection option for champions who already know their role
  • Updated wizard progress indicator to 6-step icon-only design
• Champion Role Quiz Flow — Interactive 7-question assessment
  • Full-screen quiz interface with progress indicator (Question X of 7)
  • Randomized answer order (letters a-d maintained for scoring)
  • Session-based answer storage during quiz
  • Previous/Next navigation through quiz questions
  • Exit quiz option returns to role selection page
• Quiz Results Page — Personalized role recommendation
  • Primary role recommendation with emoji, title, and description
  • Personalized narrative explaining role match based on quiz responses
  • Complete role breakdown showing all roles with percentages
  • “Select This Role” button to confirm and continue wizard
  • Options to retake quiz or manually choose different role
• Test Coverage — 7 new controller tests for quiz flow

SubPhase 1C.3: Profile Edit Integration

• Champion Role in Profile Edit — Manage role after signup
  • Added champion_role section to profile edit sidebar
  • Current role displayed in colored card with emoji when set
  • “Choose a different role” expandable section with role cards
  • “Retake the Quiz” link for role rediscovery
• Context-Aware Quiz Navigation — Quiz remembers where you came from
  • Session-based referrer tracking (session[:quiz_referrer])
  • quiz_return_path helper determines correct return destination
  • Exit Quiz returns to Profile Edit when started from Profile Edit
  • Exit Quiz returns to Wizard when started from Wizard
  • “Choose a different role” on results page respects referrer
• Wizard Completion Logic — Updated profile sequencing
  • next_incomplete_wizard_step includes champion_role after basic_info
  • Dashboard/profile links guide champions through role selection
• Test Coverage — Updated profile controller tests + model tests

UX Improvements

• Simplified Name Fields — Less bureaucratic onboarding flow
  • Primary fields: First Name and Last Name (cleaner layout)
  • Collapsible “Add additional name details” section for optional fields:
    • Legal First Name (if different from preferred name)
    • Last Name at Belmont (maiden name for searchability)
  • Data Architecture: Clean validation requiring at least one name field
    • Custom validation at_least_one_name_present (pref_first_name OR first_name)
    • No data duplication: doesn’t store same value in both fields
    • display_first_name method falls back from pref_first_name to first_name
    • Backward compatible with existing data that only has first_name
  • Stimulus controller toggle-legal-name handles expand/collapse with animated icon
• Redesigned Role Selection UI — Clear state-based display
  • When role IS set: Shows current role prominently in colored card
  • When role NOT set: Shows quiz CTA prominently with hidden manual selection
  • Stimulus controller toggle-role-selection for expandable role options
• Bio/About Me Field — Added to basic_info step and profile edit
  • Optional textarea for champions to introduce themselves
  • Helps other champions connect and find common interests
• Profile Photo Management — Enhanced photo editing
  • “Edit Photo” link overlays profile photo on hover in profile header
  • “Remove Photo” button on edit page (only shown when photo exists)
  • Removed photo from sidebar navigation (accessible via header)

Changed

• Wizard Flow — Expanded from 5 to 6 steps with champion_role as step 2
• Progress Indicator — Changed to icon-only circles (removed step text for space)
• Tailwind v4 Compatibility — Used CSS variable syntax for custom colors throughout
• Name Validation — Changed from validates :first_name to validates :pref_first_name
• Quiz Display — Questions render with HTML entities, answers in randomized order without letter labels
  • “Continue as [Role]” button to select role and advance wizard
  • “Retake Quiz” and “Choose a different role” secondary actions
  • “What’s Next?” informational section

Changed - Champion Portal SubPhase 1C.2

• ProfileWizardController — Updated for 6-step flow
  • STEPS constant now includes champion_role (6 steps instead of 5)
  • Added 4 quiz-related actions: quiz, save_quiz_answer, quiz_results, select_quiz_role
  • Quiz answers stored in session during multi-question flow
  • Session cleared after role selection
• Routes — Quiz routes added before wildcard :step route
  • Added GET /profile/wizard/quiz/:question for quiz questions
  • Added POST /profile/wizard/quiz/:question for answer submission
  • Added GET /profile/wizard/quiz-results for results display
  • Added POST /profile/wizard/select-role for role selection
  • Critical: Quiz routes placed before profile/wizard/:step to prevent route conflict
• Tests — 7 new integration tests for quiz flow
  • Test quiz question display and navigation
  • Test answer submission and advancement
  • Test redirect to results after final question
  • Test results page display
  • Test role selection and wizard advancement
  • Test session clearing after role selection
  • Test quiz retake from beginning
  • Updated existing tests for 6-step wizard flow

Technical

• All 912 tests passing (added 7 tests, updated 2 tests)
• Views created: _step_champion_role.html.erb, quiz.html.erb, quiz_results.html.erb
• Route ordering critical: specific quiz routes must come before wildcard :step route

---

Added - Champion Portal SubPhase 1.4

• Profile Wizard — Linear onboarding flow for new champions
  • 5-step wizard: Basic Info → Location & Contact → Professional → Affinities → Photo
  • Progress indicator showing current step and completion
  • Auto-advances to next step on successful save
  • “Back” and “Skip” navigation options
  • Redirects to dashboard when complete
• Profile Edit (Section-Based) — Tabbed editing for returning users
  • Sidebar navigation with 5 sections matching wizard steps
  • Stays on current section after save (no auto-advance)
  • Completion checkmarks on sidebar for finished sections
  • Accessible via “Edit Profile” from profile show page
• Profile Show (“How Others See You”) — Directory-style preview
  • Shows champion’s profile as it appears to other champions
  • Privacy indicators (“Hidden” badges) on private fields
  • Education section from linked alumni record (degrees)
  • District shown in header
  • Contact section hidden entirely if all items are private
• Affinities Selection — Multi-select affinity picker
  • Searchable dropdown with all available affinities
  • Shows selected affinities with remove buttons
  • Syncs to cp_affinities join table
• Photo Upload — Profile photo with cropping preview
  • Drag-and-drop or click to upload
  • Client-side preview before save
  • Stored via ActiveStorage
  • Displayed in directory cards and profile
• OAuth BUID Conflict Resolution — Fixed duplicate account creation
  • When OAuth email matches alumni with existing champion account (by BUID)
  • Now links OAuth to existing account instead of failing with unique constraint error
  • Added 5 tests covering all OAuth scenarios

Changed

• Profile Controller — Enhanced with section-based editing
  • SECTIONS constant defines available sections
  • section_params method scopes permitted params per section
  • Added bio to professional section params (was missing)
• Routes — Added section parameter for profile edit
  • GET /profile/edit(/:section) for section-based navigation

Fixed

• Contact section visibility — No longer reveals hidden information exists
  • If all contact items are private, section is completely hidden
  • Previously showed “Some information is hidden” message

---

[1.0.13] - 2025-12-11

Added

• Background scan with preview approval - Large file imports no longer timeout
  • Upload triggers AffinaquestScanJob running in background worker
  • Shows “Scanning” progress page with auto-refresh polling
  • When complete, redirects to full preview of ALL changes
  • User reviews and clicks “Commit Import” to apply
  • AffinaquestApplyJob applies changes in background
• Redis manifest storage - Manifests shared across Heroku dynos
  • New ManifestStore service stores manifests in Redis with 1-hour TTL
  • Solves ephemeral filesystem issue (worker saves, web reads)
  • Auto-expires, no database bloat for large manifests
• Worker detection - Warning appears after 2 minutes if scan stuck
  • Shows Heroku command to enable worker dyno
  • possibly_stuck? method on batch model
• Import change audit trail - All field updates logged to crm_data_changes
  • Each field change records old value, new value, and batch ID
  • Batch detail page shows all field updates made during import
• New importer methods:
  • Csv::AffinaquestContactImporter.scan(file) - Read-only analysis, returns manifest
  • Csv::AffinaquestContactImporter.apply_manifest(manifest, imported_by:) - Targeted updates
• Redis added to CI workflow - ManifestStore tests now pass on GitHub Actions

Changed

• Two-pass import architecture - Complete rewrite of import workflow
  • Pass 1 (Scan): Background job streams through file, builds change manifest
  • Pass 2 (Apply): Background job processes only records that need changes
  • Preview shows ALL changes for entire file, not just a sample
  • Manifest stored in Redis (shared across dynos) between preview and commit
• New batch statuses: scanning, scanned added to workflow
  • Flow: pending → scanning → scanned → running → completed/failed
• Routes restructured for batch-based flow:
  • POST /settings/affinaquest/upload - Starts scan job
  • GET /settings/affinaquest/batches/:id/scanning - Progress page
  • GET /settings/affinaquest/batches/:id/preview - Shows manifest
  • POST /settings/affinaquest/batches/:id/commit - Starts apply job

Fixed

• Critical performance fix for Affinaquest import - Import was timing out on production
  • Before: N+1 queries - each field for each row queried database for protection status
  • After: Single query preloads all protections into hash for O(1) lookup
  • Added CrmDataChange.preload_protections(buids) for bulk loading
  • Chunked processing (500 rows) with GC between chunks
• Preview accuracy - Previous version showed “No records to import” when first 50 rows had no changes
  • Now scans entire file so preview reflects actual import results
• Heroku memory/timeout issues - 48K row files were causing R14 (793MB) and H12 (timeout)
  • Background jobs run on worker dyno, not web dyno
  • Chunked processing minimizes memory usage

Migration

• Added manifest_path column to affinaquest_import_batches (stores Redis key)

---

[1.0.12] - 2025-12-10

Added

• CRM Field Protection System - Prevents Affinaquest import from overwriting staff edits
  • Tracks changes via crm_data_changes table with “staff_edit” source
  • Protected fields: pref_name, last_name, email, phone, address fields
  • Alumni controller logs staff edits before saving
  • New scopes: protecting, for_buid, for_field
  • CrmDataChange.field_protected? method for import checks
• School Email Routing - @bruins.belmont.edu emails now go to email_school field
  • SCHOOL_EMAIL_DOMAINS constant: bruins.belmont.edu, belmont.edu
  • Prevents school emails from overwriting personal emails during import

• Maiden Name Protection - Importer preserves existing last names when they differ

• CRM Data Changes Export - New page at /settings/affinaquest/crm_changes
  • View pending changes for Advancement Services export
  • Quick links added to Affinaquest index page
• Rake tasks for data governance:
  • bin/rake crm:create_restored_protections - Create protection records for manually restored data
  • bin/rake crm:fix_school_emails - Fix school emails placed in wrong field

Fixed

• SSO-generated passwords now meet complexity requirements
• Enhanced matching for maiden names and compound first names in import

Data Fixes Applied

• Restored 97 records overwritten by initial Affinaquest import (78 pref_name, 18 last_name, 1 manual)
• Fixed 11 school email records (moved to email_school, personal emails restored)

---

[1.0.8 - 1.0.11] - 2025-12-09

Added - Affinaquest Contact Import

• Phase 1: Database migrations for Affinaquest sync infrastructure
  • Alumni fields: email_school, email_personal, email_business, email_other, zip, affinaquest_updated_at, affinaquest_synced_at
  • New tables: affinaquest_import_batches, affinaquest_import_conflicts
  • Unified CRM sync tables: crm_data_changes, crm_data_export_batches
• Phase 2: Models for import and CRM sync
  • AffinaquestImportBatch - Track import history with lifecycle methods
  • AffinaquestImportConflict - Handle ID mismatches with resolve/dismiss workflow
  • CrmDataChange - Unified change tracking for CRM export (Affinaquest conflicts, Champion Portal updates, manual edits)
  • CrmDataExportBatch - Export batch management with convenience class methods
  • Alumni model updates: filter_by_any_email, filter_by_zip, with_degrees, without_degrees scopes; has_degree?, zip_district, zip_region, all_emails methods
• Phase 3: Import service
  • Csv::AffinaquestContactImporter - Main import orchestrator
  • Full import mode with batch tracking and database writes
  • Preview mode for reviewing changes before commit
  • Recency-aware field updates (preserves newer local data)
  • ID mismatch detection with conflict logging
  • CRM sync integration via CrmDataChange.log_affinaquest_conflict
• Phase 4: Controller & routes
  • Settings::AffinaquestController with 8 actions (index, preview, commit, conflicts, export, resolve, batches, show_batch)
  • Routes at /settings/affinaquest/* for full import workflow
  • Conflict management with resolve/dismiss workflow
  • CSV export of conflicts for Advancement Services
• Phase 5: Views & UI
  • Upload form with file drag-and-drop and recent batches overview
  • Preview page with stats, column mapping, sample rows, and commit button
  • Conflicts page with resolve/dismiss modal workflow
  • Batch history and details pages
  • Settings sub-nav updated with Affinaquest link
• Phase 6: Search & Filtering Updates
  • District autocomplete search with state disambiguation (e.g., “TN-04 (TN)”)
  • API endpoint: GET /api/districts/autocomplete?query=...
  • Stimulus controller: district_autocomplete_controller.js
  • Multi-email search: filter_by_any_email scope checks email, email_school, email_personal, email_business, email_other
  • AlumniLookupService and AlumniMatcher updated for multi-email matching
  • Batch search supports matching on any email field
• Phase 7: Testing
  • Full test coverage for models, services, and controllers
  • 733 tests passing with 0 failures, 0 errors
• Phase 8: Documentation
  • docs/features/AFFINAQUEST_IMPORT.md - Complete feature documentation

Added - Event RSVP Converter (December 8-9, 2025)

• New utility for converting GiveCampus RSVP exports to event app format
  • Accessible at Settings > Event Converter for all authenticated users
  • Parses GiveCampus CSV format and transforms to event check-in app format
  • Automatic alumni matching via AlumniLookupService (BUID, BQID, email, name)
  • Nickname matching support (e.g., “Maddie” matches “Madeline” via NICKNAME_MAP)
  • Duplicate registration detection and removal with stats display
  • Resolution UI for ambiguous name matches (select from candidates or confirm as guest)
  • Preview with detailed statistics before download
• Smart guest resolution (December 9, 2025):
  • Two-pass algorithm to identify registrations with BQID holders
  • Empty guest info with BQID → uses registrant name (identifying themselves)
  • Empty guest info without BQID on multi-ticket registration → marked as “+1”
  • Guest first name = “Guest” → marked as “+1”
  • +1 format: first_name = "John", last_name = "Smith +1"
• Email/Phone comparison with system data:
  • rsvp_email / system_email / email_differs columns
  • rsvp_phone / system_phone / phone_differs columns
  • Flags “YES” when RSVP data differs from Alumni Lookup data
  • Helps identify outdated contact info in the system
• AlumniLookupService enhancements:
  • Centralized bulk alumni matching with preload optimization (~3.7s for 49K records)
  • Multiple matching strategies: BUID → BQID → Email → Name (in priority order)
  • Nickname expansion via generate_name_variations() at search-time
  • find_name_candidates() method for ambiguous match resolution
• New filter_by_bqids scope on Alumni model
  • Parallel to existing filter_by_buids for batch BQID lookups
• New files created:
  • app/services/csv/event_rsvp_converter.rb — Core conversion logic
  • app/services/alumni_lookup_service.rb — Centralized alumni matching service
  • app/controllers/settings/event_converter_controller.rb — Upload, preview, download, resolve actions
  • app/views/settings/event_converter/new.html.erb — Upload form
  • app/views/settings/event_converter/preview.html.erb — Preview with resolution UI
  • docs/planning/event-checkin-integration/04-event-rsvp-converter.md — Feature documentation
• Documentation updates:
  • Added AlumniLookupService section to docs/development/AGENTS.md
  • Added BQID UI feature request to docs/development/TODO_BUGS.md
• Test coverage:
  • test/services/csv/event_rsvp_converter_test.rb — Unit tests
  • test/services/alumni_lookup_service_test.rb — Service tests
  • test/controllers/settings/event_converter_controller_test.rb — Controller tests
  • test/fixtures/files/givecampus_rsvp_sample.csv — Sample fixture data

Added - Champion Portal Phase 1.3: SSO Authentication (December 8, 2025)

• Google OAuth integration
  • “Sign in with Google” button at top of login/signup pages
  • OmniAuth configured with /auth path prefix for multi-model Devise support
  • Origin-based CSRF protection for OAuth requests
  • Callback routes wrapped in devise_scope blocks
• Profile management
  • Cp::ProfileController for profile view/edit
  • ZIP code completion prompt for SSO signups (/profile/complete)
  • SSO users redirected to complete ZIP if missing
• Controllers created:
  • Cp::OmniauthCallbacksController — Google OAuth callback handling
  • Cp::ProfileController — profile show/edit/complete actions
• Test coverage:
  • test/controllers/cp/omniauth_callbacks_controller_test.rb
  • test/controllers/cp/profile_controller_test.rb
• Future enhancements deferred:
  • Apple Sign In integration
  • Facebook OAuth integration
  • Account linking (SSO to existing email account)

Added - Champion Portal Phase 1.2: Email Authentication (December 5, 2025)

• Email-based account creation (progressive signup)
  • Champions enter name + email + zip code, password set after email confirmation
  • Custom Devise controllers in Cp:: namespace for full control
  • Mobile-first TailwindUI forms for signup, login, password reset
• Custom Champion Mailer
  • Cp::ChampionMailer for Champion Portal emails using champions subdomain
  • Branded HTML+text templates: confirmation, password reset, email change, password change
  • Uses champion’s first_name in greetings
  • Development URL: dev.alumnichampions.com:3000
• Champion Dashboard
  • Profile completion card for incomplete profiles
  • Quick stats: district, verification status, member since
  • Quick action cards (placeholders for Phase 1.4+)
  • Auth-aware layout with navigation
• Header Navigation
  • Alumni Champions logo from /public/alumni-champions.svg
  • Desktop profile dropdown with Stimulus controller
  • Mobile hamburger menu with toggle
  • Sign out functionality in both desktop and mobile
• Stimulus Controllers
  • dropdown_controller.js - Desktop profile dropdown with click-outside close
  • mobile_menu_controller.js - Mobile hamburger menu toggle
• Controllers created:
  • Cp::BaseController - feature flag checking, layout setup
  • Cp::RegistrationsController - progressive signup flow
  • Cp::SessionsController - login/logout
  • Cp::ConfirmationsController - email confirm + password setting
  • Cp::PasswordsController - forgot/reset password
  • Cp::DashboardController - authenticated dashboard
• Test coverage (53 tests, 119 assertions):
  • test/controllers/cp/registrations_controller_test.rb (4 tests)
  • test/controllers/cp/sessions_controller_test.rb (5 tests)
  • test/controllers/cp/dashboard_controller_test.rb (4 tests)
  • test/controllers/cp/confirmations_controller_test.rb (8 tests)
  • test/controllers/cp/passwords_controller_test.rb (8 tests)
  • test/models/cp/champion_test.rb (14 tests)
  • test/mailers/cp/champion_mailer_test.rb (10 tests)

Added - Champion Portal Phase 1.1: Database & Models (December 5, 2025)

• Foundation tables migration
  • regions - 7 geographic regions
  • districts - 820 metro/micro areas
  • zip_codes - 39,305 ZIP codes with city/state
  • cp_champions - Champion Portal user accounts
  • cp_profile_changes - CRM export changelog
• Geographic seed data
  • Rake task: rails champion_portal:seed_geographic_data
  • Two-pass import: assigns cross-region districts to majority region
  • 14 multi-region MSAs handled correctly
• Model enhancements:
  • Cp::Champion with Devise authentication (email auth only for now)
  • Custom mailer configuration via devise_mailer method
  • Verification status enum: unverified → email_verified → champion_verified
  • Region, District, ZipCode models with associations
  • Alumni → Cp::Champion association via BUID

Pending

• Champion Portal Phase 1.3: SSO Authentication (Google, Apple, Facebook)
• Champion Portal Phase 1.4: Profile & Directory
• Champion Portal Phase 1.5: Dashboard & Admin verification queue
• Event check-in integration (see planning/event-checkin-integration/)

---

[1.0.7] - 2025-12-09

Added

• Rake task alumni:cleanup_duplicate_buids to handle duplicate BUID records before adding unique index

---

[1.0.6] - 2025-12-08

Fixed

• Redirect alumnichampions.com to signup flow when Champion Portal feature flag is disabled

---

[1.0.5] - 2025-12-08

Added

• Event RSVP Converter - See “Added - Event RSVP Converter” section above
• Champion Portal Phase 1.3: SSO Authentication - See “Added - Champion Portal Phase 1.3” section above

---

[1.0.4] - December 4, 2025: Bug Fixes & Test Coverage Improvements ✅

Addressed TODO items: fixed bugs, added validation, and expanded test coverage.

Fixed

• Alumni affinities modal flow - Added dropdown selector for direct navigation (non-JS fallback)
  • File: app/views/alumni_affinities/_form.html.erb
  • Users navigating directly to affinity form can now select affinities from grouped dropdown
  • Edit mode continues to display the selected affinity name as before

Added

• EngagementActivity activity_code validation
  • Model now validates activity_code against registered EngagementType codes
  • Invalid codes are rejected with clear error message
  • Added cache for valid codes with reset_valid_activity_codes_cache! method
  • File: app/models/engagement_activity.rb
• Controller test coverage
  • test/controllers/engagement_activities_controller_test.rb - 12 tests
    • Authentication, staff access, filtering, statistics display
  • test/controllers/engagement_stats_controller_test.rb - 21 tests
    • All 7 tabs, filters, cache operations, exports
  • test/controllers/batch_search_controller_test.rb - 21 tests
    • Single/multiple names, emails, empty input, large batches (50-100 names)
    • Special characters, accents, CSV export, Turbo Stream responses
• Model test coverage
  • test/models/engagement_activity_test.rb - 13 tests
    • activity_code validation, associations, scopes, point calculation

Verified

• Instance variable naming convention - Confirmed @alum/@alumni usage is consistent across all controllers

---

[1.0.3] - December 3, 2025: EngagementStats Service Refactoring & Feature Flags ✅

Complete refactoring of engagement stats to use dedicated services, fixing duplicate counting bug.

Fixed

• Demographics discrepancy - Goal #2 showed 283 engaged alumni while Demographics tab showed 461
  • Root cause: Demographics counted degree records instead of unique alumni by BUID
  • All 6 tabs now count unique alumni consistently
• Matrix scoring consistency - Now matches EngagementScoreCalculator exactly
  • Removed obsolete +5 attendance bonus from MatrixService
  • Added proper SQL subqueries for activity-type caps (email_click: 5, event_rsvp: 2)
  • Fixed incorrect hardcoded point values (was using wrong LEVEL_POINTS)
• Activity Pairs sorting - Now sorts by count DESC (was incorrectly sorting by level first)

Changed

• EngagementStatsController reduced from 1,755 lines → 745 lines (~1,010 lines removed)
• All tabs now delegate to dedicated services:
  • OverviewService - Goal #1, Goal #2, Goal #3-5 metrics
  • DemographicsService - Year/college/major breakdowns (uses COUNT(DISTINCT buid))
  • BreakdownService - Activity breakdown by role/level
  • MatrixService - Quadrant analysis with engagement/giving axes
  • AnalyticsService - Charts, score distributions, monthly activity stacks
  • ActivityPairsService - Activity combination analysis
• Smoke test delay reduced from 30s to 15s

Added

• Test coverage for all new services (111 service tests total, 409 tests overall)
  • test/services/engagement_stats/breakdown_service_test.rb
  • test/services/engagement_stats/matrix_service_test.rb
  • test/services/engagement_stats/analytics_service_test.rb
  • test/services/engagement_stats/activity_pairs_service_test.rb
  • test/services/engagement_stats/scoring_integration_test.rb - Ensures scoring consistency
• Enhanced AnalyticsService with monthly_activity_stacks for stacked bar chart data
• Services use BaseService#with_caching for consistent 1-4 hour cache expiration

Technical Notes

• All services inherit from EngagementStats::BaseService
• Key rule enforced: Count unique alumni by BUID, not degree records
• capped_level_to_points_sql now applies activity-type caps via SQL subqueries
• MatrixService fixed for ambiguous buid column in joined queries
• ActivityPairsService fixed: EngagementType.all.index_by (not .index_by directly)

Added (Feature Flags)

• Feature flag infrastructure for safe feature rollouts
  • feature_enabled? helper available in controllers and views
  • ENV variable overrides for quick enable/disable without deploy
  • champion_portal flag ready for Champion Portal development
  • See docs/development/FEATURE_FLAGS.md for usage

Removed

• 9 unused helper methods across 4 files
• Duplicate lib/tasks/populate_champion_roles.rb

---

[1.0.2] - December 2, 2025: Ruby 3.3.8 + YJIT Performance

Upgraded Ruby for 15-25% performance improvement.

Changed

• Ruby 3.2.3 → 3.3.8 with YJIT enabled on Heroku
• Added csv gem proactively (becomes non-default in Ruby 3.4)
• All 298 tests passing

---

[1.0.1] - December 2, 2025: CI/CD Pipeline Complete ✅

Full CI/CD pipeline implemented with staging environment.

Added

• CI Workflow (.github/workflows/ci.yml)
  • Automated testing on every push
  • PostgreSQL 14 service container
  • Ruby 3.2.3 + Node 18 setup
  • 298 tests passing
• Staging Environment (alumni-lookup-staging)
  • Heroku app with PostgreSQL Essential 0
  • Custom domains: beta.alumnilookup.com, beta.alumnichampions.com
  • Auto-deploy on push to main (after CI passes)
  • Database copied from production for realistic testing
• Deploy Workflows
  • deploy-staging.yml - Triggers after CI passes on main
  • deploy-production.yml - Triggers on version tags (v*)
  • Smoke tests verify endpoints after deploy
• Database Backups
  • Production: Daily at 2:00 AM CT (7-day retention)
  • Staging: Daily at 3:00 AM CT
• Monitoring
  • UptimeRobot alerts for both domains
  • Heroku built-in metrics and logs
• Documentation
  • docs/operations/DEPLOY_GUIDE.md - Step-by-step deploy instructions
  • docs/operations/ENV_SETUP_IMPLEMENTATION_CHECKLIST.md - Full setup checklist

Fixed

• Migrations that loaded Alumni model before columns existed (converted to raw SQL)
• Deploy workflow using HEAD:main for tag-based production deploys

---

Pre-Release Versions

The following versions were developed before CI/CD was established. They represent feature milestones but were not formally tagged releases.

---

[1.0.0-alpha.3] - November-December 2025: Authentication & Roles ✅

All 6 phases completed. Foundation ready for Champion Portal and Event Check-in.

Added

• Phase 6: Permission Flags Infrastructure — Patterns established for future permission flags
  • No code changes needed; Phases 1-5 established all required patterns
  • Documented pattern for adding can_* boolean flags with admin bypass
  • Ready for Event Check-in to add can_event_checkin, can_event_manage flags
• Phase 5: Google SSO for Internal Users — Optional Google account linking for staff
  • Added omniauth-google-oauth2 and omniauth-rails_csrf_protection gems
  • Added google_uid and google_linked_at columns to users table
  • Created Users::OmniauthCallbacksController for Google OAuth2 callback
  • Added google_connected?, unlink_google!, and from_google_oauth methods to User model
  • Login page shows “Sign in with Google” button when configured
  • Profile page allows users to link/unlink their Google account
  • Security: Only existing users can sign in with Google (admin creates accounts first)
  • Auto-links Google UID on first SSO sign-in for existing users
  • Added 13 integration tests for Google SSO flows
  • Production Setup: Set GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET env vars on Heroku
  • Production Fixes:
    • Moved Google Sign-In section outside main form to avoid nested form issues
    • Added custom OmniAuth origin-based validation to handle fresh session CSRF edge cases
    • Configured session store with same_site: :lax for OAuth compatibility
• Phase 4: Forgot Password Flow — Self-service password reset now working
  • Configured custom Mailgun API delivery method (MailgunDeliveryMethod class)
  • Fixed Devise mailer_sender from placeholder to noreply@mail.alumnichampions.com
  • Fixed ChampionSignupMailer to use instance method for default_url_options (was polluting other mailers)
  • Production uses alumnilookup.com for Devise emails, alumnichampions.com for Champion emails
  • Fixed Mailgun initializer to only load in production (was breaking tests)
  • Styled password reset views (new.html.erb, edit.html.erb) with Tailwind
  • Branded password reset email template with Belmont header and styling
  • Added “Forgot password?” link to login page (next to Remember me)
  • Added 11 integration tests for password reset flow
• Phase 3: Admin vs Staff Separation — Role-based access control now enforced
  • Added ensure_staff! method to ApplicationController for staff-accessible features
  • Staff users can now access: Alumni search, Engagement stats, Champion signups, Batch search, Statistics
  • Staff users CANNOT access: Settings, User management, Cache clearing, Champion merge/delete
  • Updated 7 controllers with ensure_staff! or mixed staff/admin access
  • Added comprehensive staff_access_test.rb with 18 tests
  • All role access comments updated in controllers
• Phase 2: Role Infrastructure — Added role enum to User model
  • Added role column with values: staff (default) and admin
  • Migration backfills existing admins with ‘admin’ role
  • Added staff? helper method (returns true for both staff and admin)
  • Updated admin? to check role enum OR legacy admin boolean
  • Updated user form with role dropdown (replaces admin checkbox)
  • Updated users index to show role badges
  • Added 7 new tests for role functionality
• Phase 1: Unified Admin Checks — Consolidated admin authorization pattern
  • Added admin? method to User model that uses the admin boolean
  • Added ensure_admin! method to ApplicationController as standardized authorization callback
  • All Settings controllers now use centralized ensure_admin! instead of local methods
  • Removed deprecated access_level column from users table
  • Added 3 tests for admin? method
• Authentication & Roles Implementation Guide — Prerequisite project for Champion Portal and Event Check-in
  • features/AUTH_AND_ROLES_SYSTEM.md — Complete authentication & role system (moved from planning/)
  • Unify admin checks, add role infrastructure, Admin/Staff separation
  • Forgot Password flow, Google SSO for internal users
  • Permission flags infrastructure for hybrid authorization model
• Event Check-in Integration Planning — Complete integration plan for alum-events functionality
  • planning/event-checkin-integration/00-overview.md — Problem, goals, recommendation
  • planning/event-checkin-integration/01-pros-cons-and-questions.md — Pros/cons analysis, pre-integration questions
  • planning/event-checkin-integration/02-phased-integration-plan.md — Phased development roadmap with Contact/Event/Registrant models
  • planning/event-checkin-integration/03-champion-portal-interaction.md — Champion Portal alignment and sequencing
• Hybrid Authorization Model — Documented Roles + Permission Flags approach in PERMISSIONS_MATRIX.md
  • Roles define baseline access (Admin, Staff, Champion, CLC)
  • Permission flags for cross-cutting features that don’t fit role hierarchy
  • Guidelines for when to add roles vs. permission flags
  • Implementation patterns for User model and Pundit policies

Known Issues

See development/TODO_BUGS.md for tracked bugs and issues.

---

[1.0.0-alpha.2] - November 2025: Documentation & Preparation

Added

• Product Overview Documentation — Comprehensive stakeholder-ready overview (PRODUCT_OVERVIEW.md)
• Champion Portal Planning — Complete specification for future Champion Portal development
• Development Cycle Preparation — Stages 1-5 completed preparing codebase for role-based access

Changed

• Authentication Standardization — All internal controllers now explicitly require authentication
• PublicController Base Class — External/public features inherit from dedicated base class
• EngagementStats Services — Extracted calculation logic into service objects

Fixed

• affinity_name helper crash on nil input
• Alumni affinities form crash when affinity_code is nil
• UsersController#destroy — @user not set before action
• Alumni fixture naming (alumnis.yml → alumni.yml)

Documentation

• Created ARCHITECTURE.md — Two-domain architecture documentation
• Created AUTHENTICATION.md — Devise setup and authorization patterns
• Created API.md — Internal API endpoint documentation
• Created PERMISSIONS_MATRIX.md — Role-based access blueprint
• Updated test suite to 241 tests, 573 assertions

---

[1.0.0-alpha.1] - August-October 2025: Champion Signup & Features

Added

• Champion Signup System v1.0 — Multi-step wizard at alumnichampions.com
  • Welcome → Personal Info → Questions → Role Selection → Interests → Completion
  • Email notifications (Mailgun) for new signups
  • Admin management interface on alumnilookup.com
  • CSV import/export functionality
  • Duplicate detection and merging
  • Lifestage interest data cleanup tools
• Alumni Contact ID Integration — Salesforce-compatible Contact IDs (C-000000000 format)
• Alumni Photos — Active Storage with Cloudinary for production
• Accent-Insensitive Search — PostgreSQL unaccent extension for name searches
• Alumni Prospect Status — Manual prospect flagging with notes
• Top Engaged Alumni — Time-period filtering (30 days, 6 months, 1 year, all time)
• Engagement Scoring Improvements
  • Activity caps: email_click (max 5), event_rsvp (max 2)
  • Distance formula: √((score × 1.5)² + (capped_activity_count × 1.0)²)
  • Removed bonus point system
• Flagship Event Tracking — Identify and track follow-up engagement
• Degree Upload Preview — Preview/commit workflow with auto-create alumni

Changed

• Memory Optimizations — 78% reduction in memory allocations for Engagement Stats
• Tailwind CSS 4.1 — Updated frontend framework
• Batch Search — Added email search capability
• Alumni Search Results — Redesigned with photo thumbnails

Fixed

• Engagement activity import from Emma reports
• Matrix export and chart issues
• Degree details display
• Score chart label issues

---

[1.0.0-alpha.0] - Early 2025: Initial Development

Added

• Core Alumni Management
  • Alumni search with full-text PostgreSQL search
  • Alumni profiles with contact information
  • Degree tracking linked to majors and colleges
• Engagement Tracking System
  • Level-based scoring (0-4 levels)
  • Activity tracking with types and dates
  • Engagement statistics dashboard
• Affinity Management
  • Affinity categories (Athletics, Greek Life, Campus Life, etc.)
  • Alumni-affinity associations with roles and years
• Data Import/Export
  • CSV import for alumni, degrees, engagement activities
  • CSV export for search results
• User Administration
  • Devise authentication
  • Admin/staff access levels
  • User management (admin only)
• Settings Management
  • Colleges, majors, affinities configuration
  • Engagement types and activity codes

Technical Foundation

• Ruby on Rails 7.1.5.1
• PostgreSQL database
• Tailwind CSS with TailwindUI
• Hotwire/Turbo for partial page updates
• Import maps (no JavaScript bundler)
• Heroku deployment with S3/Cloudinary

---

Pre-1.0 Development

Initial Commit - Late 2024

• Project scaffolding and initial models
• Basic user authentication
• Alumni and degree models
• Settings pages framework

---

Version Numbering

This project uses semantic versioning:

• Major (X.0.0) — Significant new capabilities or breaking changes
• Minor (0.X.0) — New features, enhancements
• Patch (0.0.X) — Bug fixes, minor improvements
• Pre-release (-alpha.X) — Development versions before CI/CD was established

Version History

Version	Date	Milestone
1.0.0-alpha.0	Early 2025	Initial development
1.0.0-alpha.1	Aug-Oct 2025	Champion Signup system
1.0.0-alpha.2	Nov 2025	Documentation & prep
1.0.0-alpha.3	Nov-Dec 2025	Auth & Roles system
1.0.1	Dec 2, 2025	CI/CD Pipeline (first tagged release)
1.0.2	Dec 2, 2025	Ruby 3.3.8 + YJIT
1.0.3	Dec 3, 2025	Service refactoring + Feature flags

---

Related Documentation

• PRODUCT_OVERVIEW.md — Stakeholder-ready product summary
• REPO_OVERVIEW.md — Technical architecture
• development/TODO_BUGS.md — Known issues and pending bugs