See a candidate's entire Lever history on one merged profile

Build me an app my recruiting team opens whenever we are about to talk to someone we might have seen before. Lever organizes its pipeline by requisition rather than by person, so nobody here can see everything one human has been through with us without searching the same name several times and stitching the results together by hand. This app should do that stitching for us.

The front page is a search box. I type a candidate name or an email address and get back matching people, not matching applications. Load the data with Lever's List Opportunities using the contact and applications expansions, then group the results by the contact ID returned on the expanded contact, so each row in the results is one human showing their name, primary email, how many opportunities they hold in total and how many of those are still live.

Clicking a person opens their merged profile: one header for the human, then a table of every opportunity they hold across every posting, live and archived. Each row shows the posting title, current stage, owner, archive reason and archive date, plus when the opportunity was created and when it last advanced. Include archived opportunities, not only live ones, since the whole point is seeing the history. Sort live opportunities first, then archived ones newest first.

Expanding an opportunity row reveals its full record: the applications on it from List Applications for an Opportunity, the interview feedback from List Feedback on an Opportunity with each interviewer's scores and written comments, the notes from List Notes on an Opportunity, the referrals from List Referrals on an Opportunity, and links to the resumes from List Resumes on an Opportunity.

Two situations need flagging loudly at the top of the profile rather than being buried in the table. The first is the same person sitting live in two or more pipelines right now, which usually means two recruiters are working them without knowing about each other; show both owners by name so they can go and talk. The second is near duplicate contact records, meaning two separate contacts that share a name or an email address. Lever deduplicates on email when opportunities are created, so anything that slipped past that check is worth surfacing. Render both as visible banners that call out the specific rows involved.

From any opportunity row I can act without leaving the app: add a note with Create Note on an Opportunity, apply or remove a tag with Update Opportunity Tags, move the candidate to a different stage with Update Opportunity Stage, and archive or restore with Archive or Unarchive Opportunity. Populate the archive reason picker from List Archive Reasons, and render the special Hired reason differently from a rejection reason, because being hired is not the same as being turned down and the two should never look alike in the table. Pass perform_as with the acting user's Lever user ID on every write so the audit log attributes the change to the real person rather than to the integration.

Add a "Write the history brief" button on the profile that kicks off a background agent. The agent reads all of the feedback and all of the notes across every one of that person's opportunities, past and present, then writes a plain English summary of how they performed the previous times we spoke to them, what interviewers consistently liked, what concerns kept coming up, and exactly where and why they stalled. It files the brief back onto the current opportunity as a note with Create Note on an Opportunity, and offers a button to post the same brief to a Slack channel with Send a Message. Show the finished brief in the app so I can read it before deciding whether to post it.

A few details to get right. The current Lever model is the Opportunity, which is one candidate per posting, and a single person is a Contact who can hold many Opportunities, so all grouping has to happen on the contact ID returned when opportunities are listed with contact expanded; the legacy candidates endpoints are deprecated and must not be used. Timestamps come back as Unix milliseconds, so format them as readable dates everywhere they appear. Page through list results rather than showing only the first page. If someone has a long history, keep the profile readable by collapsing older archived opportunities behind a show more control.