Ctx module
Source: modules/ctx/.
At a glance
Section titled “At a glance”| CLI | shc ctx |
| Subcommands | 3 (login, logout, update) |
| HTTP endpoints | — |
| Events emitted | — |
| Error codes | see the error code reference |
| Service classes | — |
| Cross-module deps | stack |
Source layout
Section titled “Source layout”modules/ctx/├── command.go├── errors.go└── commands/CLI entry points
Section titled “CLI entry points”shc ctx— manage CLI contexts (inspect/update the active context;--tenant/--stack/--environment/--cluster/--reset)shc ctx login <name>— register a cluster and persist its access tokenshc ctx logout [name]— clear the token from a contextshc ctx update— upsert a context row in contexts.yaml- CLI reference
Errors
Section titled “Errors”Typed errors are catalogued in the error code reference with HTTP statuses and message templates.
Responsibilities
Section titled “Responsibilities”The ctx module owns the ambient execution context — the
context values threaded through nearly every service method — and the CLI
subcommand that lets operators inspect or switch it. Context carries
identity (tenant, stack, environment, node) and request correlation
(trace IDs), so that any service method called with the same context
produces logs, audit rows, and events that agree on “who is doing
what, where.”
Context propagation through the call graph is handled via Go’s
context.Context — entry points (HTTP middleware, CLI runner,
scheduler, event handlers) set context values; business logic reads them
via helper functions in core/reqctx (ce module). See the
implicit context pattern for the
full developer guide, including field listing, cross-node
serialization, goroutine propagation, and testing.
The CLI (shc ctx) shows and persists the operator’s current context
so subsequent commands don’t need to re-specify --tenant / --stack
every time.