Develop a Web App That Streams Live Container Logs and Metrics

## Write Short Reviews That Report Only Bugs and Blockers Use ultra-brief mode for change-request reviews and maintainer responses. Report only bugs, security problems, and blockers. Use short bullets, add `file:line` references when relevant, omit sections such as Strengths or Summary, and keep the entire response to roughly 10 to 15 lines. Write like a human maintainer. Do not use em dashes or en dashes, rhetorical “not X, but Y” contrasts, throat-clearing praise, closing recaps, bold inline labels, or empty hedges. Casual lowercase and contractions are acceptable. State the decision, give one reason, and stop. ## Have Reporters Test a Fix From Its Change-Request Build When a reported problem is fixed in an open change request, ask the reporter to test the continuous-integration artifact built for that request. Give the exact prebuilt image or package reference, using a generic pattern such as `{registry}/{image}:change-{number}`. This lets the reporter verify the fix before the next release. Confirm that automation actually publishes one tagged artifact per change request before recommending this path. ## Map the Backend and Frontend Layers Before Editing Treat the system as a compiled HTTP backend plus a typed single-page frontend. The backend handles routing, authentication, container or workload clients, live log and metric streams, actions, notifications, and remote-agent communication. The frontend handles file-based views, reusable components, reactive stores, stream composables, routing, localization, and user preferences. Support each documented deployment mode explicitly, including standalone or multi-host service, clustered orchestration, and remote-agent operation. Do not assume that a change working against one client implementation works against every backend. Keep the main dependency direction clear: `HTTP handlers -> host service -> per-host service -> domain client -> runtime implementation`. ## Build and Test With the Documented Targets Set up the project by installing dependencies and running the generation target for certificates, schemas, or protocol code. Use the full development task for coordinated backend and frontend hot reload, or run the two watchers separately when isolating a problem. Build the frontend assets before embedding them in a complete backend build. Keep distinct targets for frontend distribution, the whole application, and the deployable image. Use the preview target to inspect a production-style build locally. Run backend tests, frontend unit tests, type checking, and browser integration tests through their documented targets. Use `TZ=UTC` for timestamp-sensitive frontend tests and watch mode only during iterative local work. ## Keep Backend Layers Separate Behind a Shared Client Interface Keep HTTP routing and streaming handlers above host and client services. Put runtime-specific operations behind a shared domain-client interface, then implement that interface for each supported container, cluster, or remote-agent backend. Separate authentication providers, domain models, event parsing, notification evaluation, and notification delivery from transport handlers. Keep command-line parsing and multi-host orchestration in support layers rather than duplicating them in handlers. For a new workload operation, update the domain-client interface, every applicable runtime implementation, the per-host service wrapper, and the HTTP handler with its route. Do not bypass a layer to make one deployment mode pass. ## Keep Frontend Stores and Log Entry Types in Their Roles Keep route views, auto-imported components, reactive stores, stream composables, and application plug-ins in their established roles. Treat configuration injected by backend-rendered HTML as immutable. Keep persisted preferences behind a reactive storage abstraction. Represent single-line text, structured objects, and grouped multi-line messages as distinct log-entry types. Use the shared message alias instead of repeating a union type, and construct entries through a factory that selects the correct type from each event. Components reused across route or workload changes must refresh all derived state. If a chart optimizes updates by mutating only its last bar, expose a full recalculation method and call it when the complete data series is replaced. ## Follow the Fixed Limits for Live Log and Metric Streams Use server-sent events for log, lifecycle-event, and metric streams, and WebSocket connections for interactive attach or execution sessions. Send state-changing workload actions through explicit HTTP requests rather than over read-only streams. Buffer incoming frontend events for 250 milliseconds, but flush after at most 1,000 milliseconds. Batch reactive updates, and when displayed messages exceed 400 entries, replace or mark the oldest entries according to the viewer contract. Track metric history in a rolling window of at most 300 items. Smooth metrics with an exponential moving average using alpha 0.2, normalize CPU values by the allowed or host core count, and keep percentage and absolute memory values distinct. Downsample charts to the available display width. A full data-series replacement, such as switching workloads, must trigger full recalculation even when ordinary ticks update only the final bar. ## Handle Each Login and Deployment Mode Separately Support unauthenticated, local-file, and forward-proxy authentication as separate modes. Use expiring signed tokens for local authentication, validate the configured user file, and keep role-based authorization independent of the identity provider. In standalone mode, combine local and remote clients through a retry-capable manager. In clustered mode, discover nodes through the orchestration API and connect to an agent on each node. In cluster-native mode, implement the same domain-client interface through that platform's API. In remote-agent mode, require certificate-authenticated transport. Keep mode selection at the application entry point. A feature is incomplete until its behavior is defined for every applicable mode or explicitly rejected for unsupported modes. ## Add New Features Through Every Backend and Frontend Layer For a new HTTP route, register the route, implement its handler, resolve the target through the host service, and return structured data or establish the intended stream. For a new log view, add the route view, create a stream composable, build the filtered API URL, manage buffering, return reactive messages and controls, and reuse the established viewer. For a new metric, extend the backend statistic type, extract and calculate the value, update the protocol schema, regenerate protocol code, and expose the field in the frontend model when the interface needs it. Existing event streams should carry the update without a parallel transport. For a new notification channel, implement the dispatcher interface, register it in the dispatcher factory, add its configuration form, and preserve persisted rule and alert-state behavior. ## Limit Remote Tool Calls and Retry Only Temporary Failures Do not connect until a remote dispatcher is configured. Use a bidirectional stream for tool discovery and calls, dispatch calls through one registry, and limit concurrent executions to five with a weighted semaphore. Reconnect transient failures with exponential backoff from 1 to 30 seconds plus jitter. Stop retrying permanently on permission-denied responses that indicate invalid credentials or an unavailable plan. Cache immutable tool definitions once so disabled remote operation adds negligible overhead. To add a tool, define its name, description, and parameter schema; add its response type to the protocol result union; regenerate protocol code; register the dispatch case; implement it behind the host-service interface; and add focused tests. ## Sort Incoming Log Events by Type and Stream Them Live Parse multiplexed runtime streams by reading their headers and payloads, then classify each raw event as structured data, a grouped multi-line event, or a single-line event. Extract severity with explicit patterns, serialize the domain event, and deliver it through the live stream. For remote agents, translate domain-client calls into protocol requests, delegate them to the local runtime client, and convert responses back to domain models. Preserve streaming behavior for logs, metrics, and lifecycle events instead of collecting unbounded results in memory. Filtering by level, query, or regular expression must retain a clear result limit. Workload actions must remain behind an explicit enablement gate. ## Run Repeatable Tests and Inspect Live Stream Connections Run backend tests with the race detector. Use the project's assertion library consistently, run frontend tests in UTC, and execute browser integration tests with their required service setup. Regenerate required certificates and protocol artifacts before treating build failures as code defects. For development with unembedded assets, enable filesystem serving and coordinated hot reload. Backend changes should restart the backend watcher, while frontend changes should use module replacement without forcing a full restart. For debugging, enable backend debug logging, inspect frontend state with browser development tools, and inspect the network panel for server-sent-event and WebSocket connections. Review the final difference so generated files and automated edits do not conceal unrelated changes.