📝 refine config helper docs

docs/api/default-logger-config.md

@@ -31,6 +31,8 @@ Detailed rules explaining key parameters and behaviors
 
 - This helper returns the same baseline config shape used by `LoggerConfig::new()` defaults.
 - It includes the default minimum level, empty target, disabled timestamp, default sink config, and no queue wrapper.
+- The implementation is exactly `LoggerConfig::new()`, so it stays aligned with the constructor defaults rather than duplicating a separate preset object.
+- That means `build_logger(...)` can consume the returned value directly, and `build_async_logger(...)` reuses the same sync-side defaults before adding the outer async layer.
 - It is useful for explicit config composition when callers want a known baseline object.
 
 ### How to Use
@@ -58,3 +60,5 @@ e.g.:
 1. This helper is the top-level default config entry point.
 
 2. It is useful for explicit config-first workflows and tests.
+
+3. Use `default_sink_config()` when callers only want the baseline sink portion rather than the full top-level logger config.

docs/api/default-sink-config.md

@@ -31,6 +31,8 @@ Detailed rules explaining key parameters and behaviors
 
 - This helper returns the same baseline sink config used by `LoggerConfig::new(...)` defaults.
 - The default sink config is console-oriented unless later replaced by explicit config composition.
+- The implementation is exactly `SinkConfig::new()`, so the returned value uses the standard constructor defaults: `kind=Console`, empty `path`, `append=true`, `auto_flush=true`, no rotation, and the default text formatter config.
+- `parse_logger_config_text(...)` also falls back to this same helper when the `sink` object is omitted from JSON input.
 - It is a typed config object, not a runtime sink instance.
 
 ### How to Use
@@ -58,3 +60,5 @@ e.g.:
 1. This helper is for config-driven assembly, not runtime sink wiring.
 
 2. It is most useful in explicit config composition code.
+
+3. Use `default_logger_config()` when callers want the full top-level config default instead of only the sink portion.

docs/api/parse-logger-config-text.md

@@ -36,6 +36,9 @@ Detailed rules explaining key parameters and behaviors
 - Parsing is separated from runtime construction.
 - This API is ideal for validating, editing, or inspecting config values before calling `build_logger(...)`.
 - Supported keys are intentionally constrained to stable built-in sink shapes and formatter options.
+- Omitted top-level keys fall back to the same defaults used by the typed config constructors: `min_level=Info`, `target=""`, `timestamp=false`, `sink=default_sink_config()`, and `queue=None`.
+- When a `sink` object is present, parsing selects the built-in sink kind and validates sink-specific data before any runtime logger is built. In particular, `kind=File` requires a non-empty `path`.
+- `parse_and_build_logger(...)` is only this parser plus `build_logger(...)`, so using the two-step path here does not change the configured runtime pipeline.
 - The error surface is `ConfigError` rather than silent fallback behavior.
 
 ### How to Use
@@ -73,6 +76,8 @@ e.g.:
 
 - If supported fields have wrong types or unsupported enum text, parsing raises `ConfigError`.
 
+- If `sink.kind` is `File` but `sink.path` is empty, parsing raises `ConfigError` before runtime construction.
+
 ### Notes
 
 1. Prefer this API when you need typed config inspection before building.