📝 补充runtime文档

docs/api/configured-logger-close.md

@@ -2,8 +2,8 @@
 name: configured-logger-close
 group: api
 category: runtime
-update-time: 20260613
-description: Close the configured runtime logger sink and return whether the wrapped RuntimeSink reported a successful close action.
+update-time: 20260707
+description: Close the configured runtime logger sink and return whether the wrapped RuntimeSink close path succeeded.
 key-word:
     - logger
     - runtime
@@ -27,7 +27,7 @@ pub fn ConfiguredLogger::close(self : ConfiguredLogger) -> Bool {}
 
 #### output
 
-- `Bool` - Whether the wrapped `RuntimeSink::close(...)` call reported a successful close action.
+- `Bool` - Whether the wrapped `RuntimeSink::close(...)` call reported a successful close path.
 
 ### Explanation
 
@@ -35,9 +35,11 @@ Detailed rules explaining key parameters and behaviors
 
 - This helper delegates directly to `self.sink.close()`.
 - Plain file sinks forward to `FileSink::close()` through `RuntimeSink`.
-- Queue-backed file sinks close the wrapped file sink instead of only the queue wrapper.
-- Generic `close()` on queued file sinks does not drain pending queue entries first; it closes the wrapped file sink directly.
-- Console-style sinks and queue-wrapped console-style sinks return `true` as a no-op success because they do not expose a meaningful close step here.
+- Queue-backed file sinks now follow the same safe teardown path as `file_close()`: they first try to drain the queue, then flush the wrapped inner file sink, then close it.
+- On queued file sinks, the returned `Bool` is `true` only when that whole teardown path succeeds without introducing new file failures.
+- Plain console-style sinks return `true` as a no-op success because they do not expose a meaningful close step here.
+- Queue-wrapped console-style sinks now use drain-first teardown before returning `true`.
+- For `QueuedConsole`, `QueuedJsonConsole`, and `QueuedTextConsole`, success means the queued backlog was consumed to zero.
 - For file-backed configured loggers, later `close()` calls return `false` after the wrapped file handle has already been cleared.
 
 ### How to Use
@@ -69,12 +71,16 @@ e.g.:
 
 - If the configured logger shares the same wrapped runtime sink state with another facade and one path already closed that file-backed sink, a later close attempt returns `false`.
 
-- If callers need a file-specific close path with queue flush nuances, `file_close()` may be the better API.
+- If callers need a file-specific close path with queue flush nuances, `file_close()` may still be the clearer API.
+
+- On queued file sinks, `true` still does not mean the records are guaranteed to be durable beyond what the current backend can report; it means the queue-drain, file-flush, and file-close path completed without a newly observed file failure.
+
+- On queued non-file sinks, `true` means the queued backlog was consumed before teardown completed.
 
 ### Notes
 
 1. This is the generic configured runtime close helper.
 
-2. Prefer `file_close()` when the configured sink shape is file-backed and queued records should be flushed before teardown.
+2. Generic `close()` is now safe for queue-backed runtime sinks and no longer skips queued records silently.
 
 3. Converting the same configured logger through wrapper paths such as library projection still shares the wrapped runtime sink state, so close effects are visible across those facades.