Repository navigation
The environment prefix is doubled: WRIT_WRIT_VERBOSE works and WRIT_VERBOSE does not; the variable is the prefix plus the bare key, for every program #927
Description
Epic: #447 · Feature: #762 The writ lifecycle surface · Schedule: #916, lane 8, PR C
The defect
cmd/internal/cli/viper.go sets viper's environment prefix to the program's name (WRIT, LORE, STAR) and
turns on AutomaticEnv. The configuration keys are themselves namespaced under the program -- writ.verbose --
so the variable viper looks for is WRIT_WRIT_VERBOSE. WRIT_VERBOSE does nothing. Neither spelling is documented.
Every program on the shared root has the same doubled prefix.
The ruling, 2026-09-23
The prefix plus the bare key, for every program: WRIT_VERBOSE, LORE_VERBOSE, STAR_VERBOSE. The program
segment of the key is dropped when the prefix already names the program; WRIT_WRIT_VERBOSE is not honored. This
is how aws, gh and docker name theirs.
Acceptance
Rewritten 2026-10-02 to lane 8's plan: the shared root's flags, --verbose among them, became global settings in
lane 24 (#1010), so this lane covers the settings only one program has.
Amended 2026-10-10: this note, and the one on lane 24 below the list, are superseded. Since lane 8's ruling 18
(2026-10-03, the owner: "EVERY ONE of the DEVLORE_ settings must be in config. add that task to lane 8."), lanes 23
(#1011) and 24 (#1010) are done in this lane with #1026 (lane 43), as #1022 (lane 37) has been since ruling 10. This
lane makes the shared root's flags global settings, and PR C closes #927, #1010, #1011, #1022 and #1026, each to its
own acceptance.
- a program setting reads the program's prefix plus the bare key:
writ.repofromWRIT_REPO; nested keys map
the same way,writ.deploy.conflicttoWRIT_DEPLOY_CONFLICT; a hyphen becomes_ - the doubled spelling,
WRIT_WRIT_REPO, is not honored - no two settings share a variable: a test maps every known setting
- a variable with a program's prefix or
DEVLORE_that nothing reads draws a warning naming it and the near name
it resembles; one subprocess test per program on the shared root -
10-command-line-interface.mdstates the rule in one line, and the warning
Moved to lane 24 (#1010): the shared root's flags as global settings with DEVLORE_ variables, and the generated
reference naming them.
Plan and design documents
| Kind | Document |
|---|---|
| Plan | docs/plans/fix/927-env-prefix-doubled.md, lane 8 of #916 |
| Design | 10-command-line-interface.md |
Activity
docs(plan): lane 8 drafted: a setting's environment variable is the p…
David-Noble-at-work commentedon Oct 3, 2026
Ruled 2026-10-02: #1011 joins this lane
The owner: "Lane 23 should join lane 8." Lane 8's plan (docs/plans/fix/927-env-prefix-doubled.md) now carries #1011 as well: a flag's hyphen becomes an underscore in its setting and its variable, so
--dry-runiswrit.dry_runandWRIT_DRY_RUN, beside this issue's prefix plus the bare key. PR C closes both.The model flags are left to lane 24 (#1010), where the owner ruled that
WRIT_MODEL_PROVIDERgoes away in favour ofDEVLORE_MODEL_PROVIDER. Lane 8's reference names no variable for them, and until lane 24 lands,WRIT_MODEL_PROVIDERand its kin work undocumented.docs(plan): lane 8 covers the settings one program has, with a collis…
David-Noble-at-work commentedon Oct 3, 2026
2026-10-02: #1022 joins this lane. Enumerating graph parameters for the owner found that
--dry-runmisses the runtime's skip:Application.DryRun()readsdry_runfrom the flag map, lore and devlore-test hand itdry-run, solore deploy --dry-runruns every provider method, and a method called outside a graph is never skipped. The owner ruled that dry-run belongs to the runtime ("I agree that dry_run belongs to the runtime and will add that other settings do too. verbosity comes to mind.") and directed "log the defect and include it in lane 8." It is lane 37 on #916; PR C closes it with this issue. The plan,docs/plans/fix/927-env-prefix-doubled.md, takes it in the next commit.docs(plan): lane 8 is chartered and takes #1022; dry-run belongs to t…
fix(cli): a setting's variable is the prefix plus the bare key; lane …
test(cli): no two settings share an environment variable, and none li…
David-Noble-at-work commentedon Oct 3, 2026
2026-10-02: lane 8's phase 2 is done, and the plan records rulings 11 to 15.
Phase 2 landed as
50e03403(the mapping) and6644c382(the collision test). A program setting's variable is the program's prefix plus the key without its own segment, each.and-as_; the doubled spelling names nothing;cli.EnvironmentPrefixandcli.EnvironmentVariableexport the rule.cmd/internal/cli/environment_test.gomaps every persistent flag, every documented setting and every key the code reads through viper, and fails when two settings share a variable or one lies in a reserved family.The rulings since the charter (
docs/plans/fix/927-env-prefix-doubled.md):--variable NAME=value,<PREFIX>_VARIABLE_<NAME>and<program>.variable, which only the variable resolver reads (The variables family: --variable NAME=value, <PREFIX>_VARIABLE_<NAME> and <program>.variable, read only by the variable resolver #1023, lane 38, PR C′).<PREFIX>_VARIABLE_<NAME>and drops its lookups of settings; The variables family: --variable NAME=value, <PREFIX>_VARIABLE_<NAME> and <program>.variable, read only by the variable resolver #1023 adds the flag and the file.LORE_MODEL_*with the--model-*flags, are lane 24's exception.writ.scope,writ.segment(writ's scopes and segments take singular keys: writ.scope and writ.segment #1024) and<program>.variable.Next: phase 3, the resolver and the warning.
docs: settings and variables are orthogonal, and the name-keyed famil…
docs: variables are a section read through the config system; setting…
docs(plan): lane 8 puts every DEVLORE_ setting in the config system (#…
fix(install): install.sh takes --option value, exits with a status fo…