Skip to content

feat(chat): "@" suggests the resources the conversation is about - #108

Draft
scotwells wants to merge 1 commit into
mainfrom
feat/at-mention-suggestions
Draft

scotwells wants to merge 1 commit into
mainfrom
feat/at-mention-suggestions

Conversation

@scotwells

Copy link
Copy Markdown
Contributor

The problem

Pointing at a resource mid-sentence costs three steps every time: remember the kind, pick the kind, then find the name in a listing — even when it is the resource the last three turns were about.

What changes

@ now opens on the resources this conversation is about, above the full list of kinds:

── referenced in this conversation ─────────────────────────────
@workload/image-test      tab/enter inserts · ↑↓ select · esc closes
@workload/dnet-slim-test
── all resource kinds ──────────────────────────────────────────
@activity/          Activity · activity.miloapis.com
@allowancebucket/   AllowanceBucket · quota.miloapis.com
  • Both halves of the conversation count. Resources you pointed at, and resources the assistant found for you — ask "which workloads are failing?" and every workload in that answer is one @ away, with nothing typed.
  • Ranked by the message you are writing. "is the frontend still crashing? check @" highlights the frontend one. With nothing drafted it is simply most-recent-first.
  • Nothing is taken away. The kinds are still there under the divider, the query filters both sections at once, and narrowing to a kind still lists all of it — just with this conversation's objects first.

How the assistant's findings get there

The service now reports what each tool call came back with. The run loop extracts Kubernetes-shaped resources from the tool result, and their identities ride the tool-activity events clients already receive — identities only (kind, name, API group), never any of the result's content. Extraction is narrow by design: only kind + metadata.name JSON is recognised, prose and tables yield nothing rather than guesses, and the walk is bounded on every axis a provider controls.

The two sources are remembered separately, so an answer listing forty workloads cannot crowd out the resource you named yourself.

Rollout

The client half is inert against an older service — the field is simply absent — so the CLI can ship ahead of the deploy.

Not in this PR

  • Resume restores only what you typed. Tool results are not in the stored transcript, so resuming a conversation rebuilds the typed references and not the found ones.
  • The portal's SSE frames do not carry the field. The web chat has no @ picker yet; adding it there is a field-forward away.

Testing

go build ./..., go vet ./... and go test ./... green. 24 new tests across the four layers: extraction (shapes, bounds, determinism), the wire payload and its clamping, the wiring translation, and the picker (ranking, the two tiers and their caps, section headers, keys, layout).

🤖 Generated with Claude Code

Referencing a resource mid-sentence meant remembering its kind, picking
that kind, then finding the name in a listing — every time, even for the
resource the last three turns were about.

The "@" picker now opens on the resources this conversation has already
touched: the ones you pointed at, and the ones the assistant found for
you. Asking "which workloads are failing?" leaves every workload in that
answer one "@" away. The shortcuts re-sort as you write, so the sentence
you are typing decides which one is highlighted, and the full list of
kinds sits underneath — everything else in the project is still one
keystroke of filtering away.

For the assistant's own findings to be offered, the service now reports
what each tool call came back with: the run loop extracts Kubernetes-
shaped resources from the tool result and their identities ride the
tool-activity events clients already receive. Identities only — kind,
name and API group — never any of the result's content.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Base automatically changed from feat/crd-capability-source to main September 25, 2026 19:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant