fix(init): ask the instance name in the provider form so it is never skipped

[davideimola]

Problem

The operator-chosen instance name (persona.name in argus.yaml — the name colleagues address the agent by as @<name> in addition to @argus) was effectively never captured during argus init.

Cause

The name was only asked in Phase B (the LLM-driven SOUL interview), as an optional "topic 7" placed last and marked "keep it light", persisted via a dedicated set_persona_name tool. The interviewer LLM finalizes (calls write_soul) before reaching topic 7, and the TUI exits the instant SOUL.md is written (the mtime check in dispatch). Net effect: the name question was almost never posed.

Fix

Move the instance-name question from Phase B (non-deterministic LLM interview) to Phase A (the deterministic huh provider form). This is also more coherent: persona.name lives in argus.yaml, which is exactly the artifact Phase A writes.

• Added an optional huh.NewInput() step to the provider form. Empty = skip (keeps the @argus brand default). Non-empty is trimmed, has a leading @ stripped, and must be a single word.
• The single-word / strip-@ rule (previously in setPersonaName.Execute) is extracted into a shared normalizePersonaName helper, used by both the form validator and the post-form normalization, and covered by a unit test.
• The field prefills from the existing cfg.Persona.Name when re-running init, matching the other form steps.
• The value is saved to cfg.Persona.Name before Phase A's SaveConfig.
• Removed the set_persona_name tool (setPersonaName type + registration) and updated interviewerPersona(): dropped topic 7, the WHEN DONE set_persona_name bullet, and the set_persona_name guardrail reference.

Testing

go build ./... and go test ./... both pass. The setPersonaName unit tests were replaced with a table-driven test for normalizePersonaName (strip @, trim, empty-is-valid, multi-word rejected). The huh form itself needs a TTY and is not driven headless.

🤖 Generated with Claude Code

[argusappsecuritybot]

🛡️ Argus security review

No security findings.