Roadmap relationship
Outcome
Provide one permission-aware runtime inventory and detail experience for services, functions, containers, tasks, and system processes, with provider-capability-aware lifecycle controls and diagnostic access.
Current gap
Server, serverless, service, worker, terminal, and deployment views exist separately, while container lifecycle commands are stubbed and there is no unified view of what process/container/task backs a service. Operators cannot consistently inspect config, resource usage, mounts, networks, logs, or exec availability.
User experience
- List workloads by project/environment/server/provider with status, health, active release, replicas, image/runtime, resource usage, restart count, age, and tags.
- Service detail groups overview, deployments, logs, metrics, configuration, domains, processes/containers, mounts/networks, and operations without losing context.
- Offer start, stop, restart, redeploy, scale, and exec only when the driver declares support; explain unsupported and transiently unavailable actions.
- Live data shows freshness and reconnect state; tables support search/filter, column selection, and responsive cards on small screens.
- Shell/exec opens in an explicit target banner and supports read-only diagnostics presets before free-form access.
Scope
- Define provider-neutral workload, replica/process, container/task, network, mount, resource, and lifecycle capability descriptors.
- Discover systemd/pantry services, server processes, Docker/OCI containers, ECS tasks/services, and Lambda functions through adapters.
- Implement lifecycle actions, replica scale where supported, bounded log reads/follow, exec sessions, container config inspection, file upload/download policy, and network/mount views.
- Link each runtime object to its service, release, deployment, server, provider IDs, and health events.
- Expose the model through CLI/API/dashboard and reuse durable operations for mutations.
Technical direction
- Keep read/discovery adapters separate from mutation drivers and normalize status without discarding raw provider state.
- Use stable composite identities and reconcile discovered objects into ephemeral observed-state tables with freshness timestamps.
- Implement streaming channels with target authorization, resize/heartbeat/close semantics, bounded buffers, and reconnect rules.
- Use provider pagination and rate-limit handling; cache only with visible staleness.
Safety and operability
- Exec/terminal and file transfer require elevated scoped permission, recent authentication, audit, target confirmation, and configurable disablement.
- Default file access to service-owned paths; prevent traversal and sensitive host paths.
- Lifecycle actions lock against deploy/destroy/restore jobs and communicate blast radius.
- Never expose environment secret values through config inspection or process listings.
Acceptance criteria
- A service page identifies and navigates to every backing workload and current release.
- Supported lifecycle actions work through shared services; unsupported actions are disabled with provider-specific guidance.
- Log follow and exec reconnect/close cleanly and cannot cross resource scope.
- Runtime inventory remains useful when one provider/server is unreachable, with per-source degraded status.
Verification
- Adapter contract fixtures for systemd, containers, ECS, and Lambda plus status-normalization tests.
- Authorization, traversal, secret redaction, stream backpressure/reconnect, and operation-lock tests.
- End-to-end inspect → logs → restart → health recovery on one server and one serverless/container target.
Non-goals
- Replacing provider consoles for every low-level field.
- Providing unrestricted host root access to ordinary service operators.
- Building a general-purpose container orchestrator in this issue.