internal/output/events.go (1)

59-79: Add first-class emit helpers for the new status events.

InstanceInfoEvent and ServiceResourcesEvent are in the Event union now, but callers still have to fall back to the generic Emit, and the usual helper/test pattern for new events is incomplete. Matching EmitInstanceInfo / EmitServiceResources helpers would keep producers consistent and make parity coverage easier to extend.

♻️ Suggested helpers

+func EmitInstanceInfo(sink Sink, event InstanceInfoEvent) {
+	Emit(sink, event)
+}
+
+func EmitServiceResources(sink Sink, event ServiceResourcesEvent) {
+	Emit(sink, event)
+}

Based on learnings: When adding a new event type, update internal/output/events.go (event type + Event union constraint + emit helper), internal/output/plain_format.go (line formatting fallback), and tests in internal/output/*_test.go for formatter/sink behavior parity.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@internal/output/events.go` around lines 59 - 79, Add first-class emitter
helpers for the two new event types so callers don't need to call the generic
Emit directly: implement EmitInstanceInfo(ctx, e InstanceInfoEvent) and
EmitServiceResources(ctx, e ServiceResourcesEvent) (matching the existing helper
signatures/pattern used by other events) and have them call the generic Emit
with the concrete struct; update any tests to use these helpers. Ensure you
reference the types InstanceInfoEvent and ServiceResourcesEvent and follow the
existing helper naming/parameter conventions used by other emit helpers in this
package so formatter/sink parity remains consistent.

internal/ui/app.go (1)

151-159: Avoid duplicating AuthEvent wording in the TUI.

The new fallback text now lives here and in internal/output/plain_format.go, so plain and TUI rendering can drift on the next copy change. Prefer deriving the text from the shared formatter and only applying TUI-specific styling in this branch.

Based on learnings: UI should consume shared output events directly; reuse FormatEventLine(event any) for line-oriented rendering so plain and TUI stay consistent.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@internal/ui/app.go` around lines 151 - 159, The TUI branch handling the
AuthEvent duplicates plain-text wording instead of reusing the shared formatter;
change the AuthEvent case in the switch (the block that appends to a.lines using
appendLine and styledLine) to call the shared FormatEventLine(event any) (or the
existing formatter function) to obtain the canonical line(s) for the event and
then apply only TUI-specific styling (e.g., wrap/mark as secondary) before
appending to a.lines, so the TUI text stays consistent with
internal/output/plain_format.go; keep the existing styledLine/appendLine usage
but derive the content from FormatEventLine rather than hardcoding strings.

internal/output/plain_format.go (1)

151-153: Prefer emulator wording in the status details.

CONTAINER: is now part of the user-facing status output. That exposes the runtime implementation instead of the emulator concept the CLI uses elsewhere.

Based on learnings: In user-facing CLI/help/docs, prefer emulator over container/runtime; use container/runtime only for internal implementation details.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@internal/output/plain_format.go` around lines 151 - 153, Replace the
user-facing "CONTAINER: "+e.ContainerName entry with emulator wording so the
status shows the emulator label; modify the code that appends to meta (the block
that checks e.ContainerName in plain_format.go) to use "EMULATOR: " (or the
agreed-upon emulator label) instead of "CONTAINER: ", leaving the rest of the
logic (e.ContainerName and meta append) unchanged.

test/integration/status_test.go (1)

15-23: Force non-interactive mode in these tests.

These assertions are for plain-text output, but the command path is chosen at runtime. Right now the tests rely on whatever runLstk does with stdio; if that ever becomes terminal-backed, status will switch to Bubble Tea and these tests will become flaky or hang. Please pass the non-interactive flag/env explicitly here so the plain-sink path is pinned.

As per coding guidelines: **/integration/**/*_test.go: "Integration tests that run the CLI binary with Bubble Tea must use a PTY (github.com/creack/pty) since Bubble Tea requires a terminal; use pty.Start(cmd) instead of cmd.CombinedOutput()..."

Also applies to: 25-59, 61-87

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/integration/status_test.go` around lines 15 - 23, The test
TestStatusCommandFailsWhenNotRunning (and the other tests in ranges 25-59 and
61-87) currently invoke runLstk which may pick a terminal-backed path and
trigger Bubble Tea; update these tests to force non-interactive/plain-sink mode
by passing the explicit non-interactive flag or environment to runLstk (e.g.,
add "--no-interactive" or set a NO_INTERACTIVE env var via the runLstk call) so
the CLI takes the plain-text path; modify the calls to runLstk(testContext(t),
...) in TestStatusCommandFailsWhenNotRunning and the other affected tests to
include that non-interactive indicator so assertions against stderr/stdout
remain stable.

internal/output/events.go (1)

61-77: Consider adding emit helper functions for new event types.

The new InstanceInfoEvent and ServiceResourcesEvent types are added to the Event union but lack corresponding emit helpers like EmitInstanceInfo and EmitServiceResources. While callers can use Emit() directly, the pattern established by other events (e.g., EmitAuth, EmitStatus) suggests helpers improve discoverability and consistency.

♻️ Suggested helpers

func EmitInstanceInfo(sink Sink, event InstanceInfoEvent) {
	Emit(sink, event)
}

func EmitServiceResources(sink Sink, event ServiceResourcesEvent) {
	Emit(sink, event)
}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@internal/output/events.go` around lines 61 - 77, Add two thin emitter helpers
to mirror existing patterns: implement EmitInstanceInfo(sink Sink, event
InstanceInfoEvent) and EmitServiceResources(sink Sink, event
ServiceResourcesEvent) that simply call Emit(sink, event). Place them alongside
other emit helpers so callers can use EmitInstanceInfo and EmitServiceResources
instead of calling Emit directly; reference the existing Emit function and the
types InstanceInfoEvent, ServiceResourcesEvent and the Sink type when adding
these helpers.

internal/output/events_test.go (1)

17-43: Test coverage is limited to URL-only scenario.

This test only validates the AuthEvent without a Code field. While plain_format_test.go covers the full scenario with Code, consider adding a second test case here to verify EmitAuth behavior when Code is populated, ensuring the emit helper and formatter work together correctly for both paths.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@internal/output/events_test.go` around lines 17 - 43, Add a second test case
that calls EmitAuth(sink, AuthEvent{Preamble: "Welcome", URL:
"https://example.com", Code: "1234"}) and then asserts sink.events length,
type-asserts the stored event to AuthEvent, checks event.Code, event.URL and
event.Preamble, and finally calls FormatEventLine(event) and compares the
returned line to the expected formatted string for the Code-present path; update
the test to exercise EmitAuth, AuthEvent and FormatEventLine together for the
Code-populated scenario.

internal/auth/login.go (1)

41-46: ⚠️ Potential issue | 🟡 Minor

Still handle the browser.OpenURL failure path.

Line 46 still ignores the error from browser.OpenURL(authURL), so this flow cannot distinguish “browser opened” from “browser launch failed” and always shows the optimistic path. Please check it and downgrade to a warning/manual-open flow when the launch fails. As per coding guidelines "Errors returned by functions should always be checked unless in test files".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@internal/auth/login.go` around lines 41 - 46, The call to
browser.OpenURL(authURL) in internal/auth/login.go is ignoring its returned
error; update the logic after output.EmitAuth(...) to capture the error from
browser.OpenURL(authURL), check it, and on failure downgrade to a
warning/manual-open flow: call the logger (or output) to emit a warning that the
browser launch failed and instruct the user to open authURL manually (instead of
assuming success). Reference the browser.OpenURL call and the
EmitAuth/output.AuthEvent usage so you modify the branch where the URL is opened
and emit an alternate message when err != nil rather than discarding the error.