feat(completion): complete context names for positional args

[levontumanyan]

Summary

Extends shell tab completion to offer context names as candidates when completing positional arguments on leaf commands — specifically config current-context set, config context edit, and config context remove.

Before this change, pressing Tab after elastic config current-context set yielded no candidates. After it, the context names from ~/.elasticrc.yml are offered.

Approach

• Adds an optional getPositional(commandPath: string) method to the DynamicCompleterRegistry interface. The command path is the space-joined ancestry excluding the root program name (e.g. "config current-context set").
• Adds a getCommandPath() helper to enumerate.ts that walks cmd.parent to build the path.
• In enumerate(), when the walk lands on a leaf command (no children) and a positional completer is registered for its path, that completer's candidates are returned instead of the empty children list.
• Registers the three above commands in registry.ts, all reusing the existing completeContextNames function — no new I/O code.

The change is additive: registries that don't implement getPositional continue to work unchanged.

Test plan

• enumerate -- positional completer registry suite (4 new tests): invocation, prefix-filtering, error tolerance, no call when command has children
• defaultRegistry -- positional completers suite (4 new tests): registered paths, unregistered paths
• npm test — 1471/1471 pass
• Manual: elastic config current-context set <TAB> lists context names from config

🤖 Generated with Claude Code

[JoshMock]

Nice! Thanks for the contrib. 🙏

[levontumanyan]

Hi @JoshMock,

All GitHub Actions checks are green. The Buildkite job is waiting on a maintainer to approve the fork pipeline run — would you be able to trigger it or merge directly if you're happy with the changes?

[plinde]

🤖 Claude Code

Two non-blocking improvements from a local review. Nice, tightly-scoped change.

[plinde]

The branch offers positional candidates whenever the leaf has no children, regardless of how many positionals are already typed. For a single-positional command like set, config current-context set prod <TAB> walks to the set leaf (prod isn't a child, so the walk breaks on it) and context names are offered again for a second positional the command doesn't accept. Harmless in practice — but worth a one-line note documenting it as a conscious won't-fix, since matching positional depth would add real complexity:

Suggested change

	if (children.length === 0 && registry != null) {
	// Leaf command (no subcommands): offer a registered positional completer.
	// Note: this fires regardless of how many positional args are already typed,
	// so a single-positional command re-offers candidates after the first.
	if (children.length === 0 && registry != null) {

[levontumanyan]

🤖 Claude Code

Both addressed in 935fffe — added the inline comment and updated the algorithm docstring in step 5.

[plinde]

Doc nit: the function-level JSDoc above (the numbered algorithm, step 5) still describes the default branch as returning only "subcommand names and aliases of the deepest matched command/group." With this change, a leaf command that has a registered positional completer returns those candidates instead. The interface comment was updated, but the algorithm narrative — the canonical description of enumerate's priority order — wasn't. Consider adding the positional-completer case to step 5 so the docstring stays authoritative.

[levontumanyan]

🤖 Claude Code

Both addressed in 935fffe — added the inline comment and updated the algorithm docstring in step 5.

[JoshMock]

buildkite test this

[JoshMock]

Buildkite is for integration tests against ES, KB and control plane APIs, which isn't affected by shell completion changes. Will ignore that and merge.