Ed Zynda 5ec2217b0f docs(sdk): document global viper state leakage in New and Options ...

The SDK applies Options by calling viper.Set on viper's process-global
store, which means two Kits constructed in the same process are not
isolated from each other: the second New overwrites the first's keys,
and downstream readers (SetModel, GetThinkingLevel, BuildProviderConfig)
observe the most recent value.

- Add a 'Global viper state warning' block to the Options godoc
  explaining the leak, the zero-value-does-not-clear gotcha, and
  pointing at viper.Reset() as the migration workaround.
- Add a matching warning to the New godoc so consumers discover the
  constraint from either entry point.
- Detach the viperInitMu godoc (previously lodged inside New's comment
  block) and clarify that the mutex only guards the construction
  window, not instance isolation.
- Add a TODO noting the proper fix: refactor to a per-call viper.New()
  instance so each Kit owns its own config store.

2026-04-17 12:09:13 +03:00

..

extensions/test

fix(test): add return after t.Fatal to silence SA5011 nil-deref warnings

2026-04-01 21:24:02 +03:00

kit

docs(sdk): document global viper state leakage in New and Options

2026-04-17 12:09:13 +03:00