config

type Config struct {
	Version       int       `yaml:"version"`
	ActiveProject string    `yaml:"activeProject,omitempty"`
	Projects      []Project `yaml:"projects,omitempty"`
	Settings      Settings  `yaml:"settings"`
}

type EnvVar struct{ Name, Value string }

type Error struct {
	Err error
	// contains filtered or unexported fields
}

type Project struct {
	// Name identifies the project to the user and namespaces its secrets.
	Name string `yaml:"name"`

	// BaseURL is the fully-qualified API root, for example
	// "https://acme.api.fulfillmenttools.com". It is stored, never derived.
	//
	// The official docs contradict themselves on whether the host is
	// "{projectId}.api…" or "ocff-{projectId}.api…", so fft refuses to guess:
	// ProjectID and Environment below exist for display and for building a
	// candidate email, and are never used to construct a URL.
	BaseURL string `yaml:"baseUrl"`

	// FirebaseAPIKey is the Firebase *Web* API key. It identifies the Firebase
	// project and is sent only as the ?key= parameter on Google's identity
	// endpoints, never to fulfillmenttools.
	//
	// It is treated as sensitive: hydrated at runtime from the secret store (a
	// configured project) or the environment (a headless one) and never written
	// to the plaintext config file — hence the yaml:"-".
	FirebaseAPIKey string `yaml:"-"`

	// LegacyFirebaseAPIKey catches the cleartext key that pre-v2 config files
	// stored under firebaseApiKey. It exists only so the startup migration can
	// move it into the secret store; nothing else sets it, and once the migration
	// clears it, omitempty drops it from the file. See migrateAPIKeys in cmd/fft.
	LegacyFirebaseAPIKey string `yaml:"firebaseApiKey,omitempty"`

	// Email is the address that actually authenticates. fulfillmenttools users
	// often have a synthetic address ({username}@ocff-{projectId}-{env}.com) but
	// not always, so whatever value signs in successfully is persisted verbatim
	// rather than recomputed.
	Email string `yaml:"email"`

	// Username is the short login name the email was derived from, kept so that
	// `fft project list` can show something a human recognises.
	Username string `yaml:"username,omitempty"`

	// Tenant, ProjectID and Environment are descriptive only.
	Tenant      string `yaml:"tenant,omitempty"`
	ProjectID   string `yaml:"projectId,omitempty"`
	Environment string `yaml:"environment,omitempty"`

	// ReadOnly refuses every request that would change this tenant. The project
	// still gets, lists and searches — including the POST-bodied cursor searches,
	// which are reads — and a refused write is refused before fft signs in, so it
	// costs no round trip and mints no token.
	//
	// It protects the *tenant*, not the config file: `fft project use` and
	// `fft project remove` still work on a read-only project, because configuring
	// fft is not changing anything in the tenant.
	//
	// omitempty, so that adding this field churns no existing config file.
	ReadOnly bool `yaml:"readOnly,omitempty"`

	// Ephemeral marks a project synthesized from FFT_* environment variables in
	// headless mode. It is never written to disk — hence the yaml:"-".
	Ephemeral bool `yaml:"-"`
}

type Settings struct {
	// Output is the default output format when -o is not given.
	Output string `yaml:"output"`
	// UpdateCheck enables the once-a-day check for a newer fft release.
	UpdateCheck bool `yaml:"updateCheck"`

	// NoKeyring stores credentials in a 0600 file rather than the OS keychain, for
	// a machine that has none — WSL, a container, a headless server. It is what
	// --no-keyring says, made permanent; the flag and FFT_NO_KEYRING still win.
	//
	// omitempty, so that adding this field churns no existing config file.
	NoKeyring bool `yaml:"noKeyring,omitempty"`

	// NoHistory stops fft from recording the requests it sends in its local
	// history. FFT_HISTORY still wins, as the environment does over every setting.
	NoHistory bool `yaml:"noHistory,omitempty"`
}

type Store struct {
	// contains filtered or unexported fields
}