Module config 

Layered configuration and profile resolution.

Two entities that are easy to conflate (see CONTEXT.md):

• an account owns a credential — one auth login per account, one keychain entry;
• a profile is an organisation seen through an account, plus display defaults.

One account can serve many profiles (same login, several organisations) and one organisation can be reached through several accounts (admin and read-only). That is why the token is keyed by account and never by profile.

Modules

cache

What we have learned about the organisations, kept between runs.

paths

Per-OS locations and the upward search for a repository pin.

store

Writing the config file back.

timers

Timers running locally, kept between runs.

Structs

Account

An identity that holds a credential. The struct is intentionally empty of secrets: the token lives in the OS keychain under this account’s name.

Config

The user-level config file, $XDG_CONFIG_HOME/ytcli/config.toml.

Display

Display defaults. Every one of these is overridable per profile and per repository, because a default that cannot be moved becomes someone’s papercut.

Profile

An organisation reached through an account.

ProjectPin

The committed, secret-free .tracker.toml found by walking up from the cwd. It pins a repository to a profile so that an agent working in a checkout lands in the right organisation without any global mutable state.

Resolved

A fully resolved profile plus the provenance of that choice.

Enums

ConfigError

OrgKind

Which header carries the organisation id. Sending the wrong one is a 403, so it is a profile-level decision rather than something we probe at runtime.

ProfileSource

Where the active profile name came from. Always reported by auth status and by every writing command: “which organisation am I about to change” must never be a guess.