Documentation
¶
Overview ¶
Package onboard implements Console's onboarding subsystem: helping an operator register their application into Console — which components to monitor and which feature flags to create. It offers two modes that produce the same artifact: Human mode runs a guided, interactive terminal wizard; AI-Assisted mode asks an LLM to draft the plan from a free-text description. The resulting Plan can be applied to a live App (Apply) or rendered as a markdown setup guide (Guide).
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Apply ¶
Apply persists p into a live App: each component is created via a.Status.CreateComponent and each flag via a.Flags.Create. It returns the number of items successfully created.
Duplicate handling: a per-item core.ErrConflict (the key already exists) is not fatal. The item is skipped and a record of the skip is collected; the remaining items are still applied. Any *other* store error aborts immediately and is returned wrapped (with the count applied so far). When the only failures were conflicts, Apply returns a *SkippedError — a soft error that callers can inspect via errors.As or ignore entirely (it is never returned alongside a hard failure). This lets re-running Apply over an already-partially-onboarded app converge rather than fail.
Types ¶
type Plan ¶
type Plan struct {
// App is the application's display name.
App string
// Description is a free-text summary of what the application does.
Description string
// Components are the parts of the app to monitor.
Components []core.Component
// Flags are the feature flags to create.
Flags []core.Flag
// Notes carry advisory messages — guidance produced while drafting the plan,
// or skipped-item notices recorded during Apply.
Notes []string
}
Plan is the shared output of both onboarding modes: a proposed Console setup for one application. It is a pure data value — building a Plan never touches storage. Apply turns it into real components and flags; Guide renders it as a human-readable setup guide.
func AI ¶
AI drafts a Plan from a free-text description by asking the LLM provider p to fill out the documented JSON schema. It returns a clear error when no provider is configured (p == nil), so callers can fall back to Human mode. The model's reply is parsed robustly — a wrapping ```json code fence is stripped — and the decoded plan is normalized (rollout clamped 0..100, scope defaulted to "all", provider defaulted to "http", component keys minted from names when absent). On unparseable output the returned error includes a snippet of the reply.
func Human ¶
Human runs the guided, interactive onboarding wizard. It reads answers from in and writes prompts to out, so it is fully testable with a strings.NewReader session and a bytes.Buffer — it never touches os.Stdin directly.
The flow is: app name, app description, then two repeating loops. The component loop asks for a name (blank ends the loop), a provider (default "http"), and a url/config value. The flag loop asks for a key (blank ends the loop), a description, a scope (default "all"), and a rollout percentage (default 0, clamped to 0..100). Input is trimmed throughout. The assembled Plan is returned; ctx is honoured between prompts so a cancelled wizard stops promptly.
type SkippedError ¶
type SkippedError struct {
Skipped []string
}
SkippedError reports the items Apply skipped because they already existed. It is a soft error: the apply still succeeded for every non-conflicting item. Callers can use errors.As to retrieve the skipped list, or ignore it.
func (*SkippedError) Error ¶
func (e *SkippedError) Error() string