Tell the buddy persona which mode it is in

[LinseCed]

Related issue

#193

Short summary

The backend sends capabilities_enabled and team_mode on every buddy agent hop and this service read neither. With capabilities off the persona still described a mentor who can act, so the refusal that followed read as a bug; with team mode it greeted a project's manager as a new hire. Both flags now reach build_persona, which assembles a different persona for each.

Checks

• uv run ruff check . clean
• uv run ruff format --check . clean
• uv run pyright src/ — 0 errors
• uv run pytest — 903 passed, 8 skipped
• Verified against the running backend (sprintstart-backend#230–#233) with a real manager account

Additional notes

What changes

• BuddyAgentRequest gains capabilities_enabled: bool = True and team_mode: bool = False, both documented in the OpenAPI description because the backend is the reader.
• Threaded through the route and run_agent_turn into build_persona, and read on every hop. _ensure_persona replaces the system message a resume carries and keeps only its summary, so a hop that lost a flag would rebuild the default persona mid-turn. test_a_resume_that_lost_team_mode_is_the_default_mentor_again pins that.
• Capabilities off: says it has search_docs and nothing else, answers from the project's material, and offers nothing — no escalation, no claim, no assessment. Grounding and the test/fixture caveat stay: they are safety rules, not capabilities.
• Team mode is its own persona:
  • the reader is the manager of one project, never greeted as a hire and never told what they should work on;
  • situations are stated as facts about the situation — work waiting on a review is the reviewer's move — never as a judgment of the person, and the team is never ranked;
  • open_area is explained only when mounted, including that an area's tools arrive on the next step;
  • a standing rule that a change is only ever offered for the manager to confirm elsewhere.

Decisions worth arguing with

The proposal rule is about the model, not about a named tool. Which actions are mounted changes hop by hop as areas open, so a clause gated on them would be missing on the hop before the first open_area — the hop where a model is most likely to announce it has done something. Worded as a rule it stays true when nothing is mounted and still names no tool that is not there.

Hire clauses are dropped by mode, not only by mounting. Their tools are never mounted in team mode today, so gating alone would be enough today. It stops being enough the moment the backend mounts one of them, and "let's settle where you're starting from" in front of somebody's manager is not a failure worth leaving available.

No escalation offer in team mode. flag_to_pm raises a question to a manager, and the reader here is one.

search_docs stays in both modes. Neither mode is about what the reader may read.

Not in this PR

• The opening greeting, which is Team greeting when a manager opens the buddy in team mode #194 (stacked on this branch).
• Anything the backend sends beyond these two flags.

🤖 Generated with Claude Code