[Pantheon] Auto-detect bare-name persona mentions in followups

← All Specs

[Pantheon] Auto-detect bare-name persona mentions in followups

Task

  • ID: 2a688f2e-de4a-408e-9652-dad78771f7cf
  • Type: one_shot
  • Layer: Agora
Effort: standard

Goal

PR #913 shipped an @-prefix persona picker in the Pantheon
followup / continue / fork / reply textareas. The user's original
request also asked about bare-name mentions — "when I reference
a person by name in the followup (with or without using @) is there
a way to lookup those personas and add them to the chat" — which
was deferred as out of scope ("needs a name-resolution pass").

This task delivers that pass.

Background

The originating prompt from the session:

> when i reference a person by name in the followup (with or without
> using @) is there a way to lookup those personas and add them to
> the chat; would claude skills be able to pick up on this if those
> personas were skills? might not work with llm client that we have
> now; perhaps there is some pass that can identify people mentions
> in the text of a question or followup and add those people?
> @ syntax is definitely something we could add.

The @ syntax shipped in PR #913. The bare-name case is left.

What this task does

Add a server-side pre-flight pass that runs on every POST /pantheon/sessions/{id}/continue, /fork, /reply body
before the request reaches the round-runner:

  • Tokenize the topic / follow_up_question into candidate spans
  • (named-entity-recognition-lite — [A-Z][a-z]+(?: [A-Z][a-z]+)?
    roughly, plus quoted strings).
  • Match against the persona registry:
  • - Direct slug match (case-insensitive).
    - Display-name match (display_name field).
    - Last-name match if unambiguous (one persona with that last
    name). Skip if ambiguous.
  • Auto-augment:
  • - For each unambiguous match that wasn't already in the
    persona-chip selection, append it to the body's persona_ids
    list with a note in the response (auto_resolved_mentions: [...]).
    - The frontend should display these as a small "Also pinged:
    <name>, <name>" line above the response cards so the user can
    see the augmentation happened.

    Design choices

    • No LLM call for the resolution pass. A pure-substring lookup
    is fast (<10ms), deterministic, and explainable. Save LLM cycles
    for the actual debate.
    • Don't resolve ambiguous matches. "Karel" matches one persona
    (karel-svoboda); "Chris" matches none unambiguously (probably).
    When ambiguous, leave the text alone — the user can disambiguate
    with @.
    • Don't resolve common first-names without context. "I think
    Karel made this point" should resolve; "Karel from accounting
    said..." should not. Heuristic: only resolve if the persona
    registry has < 3 candidates with that first-name, OR the surname
    is also a match.
    • Respect existing @ tokens. If the user already wrote
    @karel-svoboda once, don't double-augment when "Karel" appears
    later in the same prompt.

    Acceptance criteria

    ☐ New module scidex/pantheon/name_resolver.py with a
    resolve_bare_names(text: str, persona_registry: list) ->
    list[ResolvedMention]
    function.
    ☐ Unit tests covering: direct slug, display-name, last-name
    unambiguous, last-name ambiguous (no resolve), already-@-tagged
    (no double-resolve), empty input, no matches.
    ☐ Wired into the 3 endpoints (/continue, /fork, /reply)
    with the auto-augment behavior described.
    ☐ Frontend renders the "Also pinged: ..." line; clicking a name
    there opens the persona's profile.
    ☐ Response payload carries auto_resolved_mentions: [{slug,
    display_name, matched_text, confidence}] so the UI + future
    audits can introspect what got resolved.

    Out of scope

    • LLM-based co-reference resolution ("the third person who responded
    to the synthesizer's question..."). That's a much harder problem;
    this task is just literal name matching.
    • Cross-session mention threading (an @karel-svoboda in pan_A
    triggering a notification in pan_B). Separate feature.

    Why priority 60

    Quality-of-life feature. The @ picker (PR #913) already covers
    the explicit case; this is the additional layer that catches user
    flows where they're typing fast and don't think to prefix names.
    Not blocking any other work.

    Dependencies

    • PR #913 must merge (or its equivalent on v2). The persona-registry
    endpoint + the @-picker frontend handle the rendering surface this
    task augments.

    Lineage

    • Originating session prompt quoted above.
    • Out-of-scope note in docs/planning/2026-04-27-orchestra-session-summary.md.

    File: 2a688f2e-de4a-408e-9652-dad78771f7cf_pantheon_bare_name_mentions_spec.md
    Modified: 2026-05-20 18:03
    Size: 4.7 KB