📝 补充runtime文档

docs/api/configured-logger-file-close.md

@@ -2,8 +2,8 @@
 name: configured-logger-file-close
 group: api
 category: runtime
-update-time: 20260512
-description: Close the file sink behind a configured runtime logger when one is present.
+update-time: 20260707
+description: Close the file sink behind a configured runtime logger when one is present, with queued-file success tied to safe drain-flush-close behavior.
 key-word:
     - logger
     - runtime
@@ -27,14 +27,15 @@ pub fn ConfiguredLogger::file_close(self : ConfiguredLogger) -> Bool {}
 
 #### output
 
-- `Bool` - Whether the underlying file close succeeded.
+- `Bool` - Whether the file-specific close path succeeded.
 
 ### Explanation
 
 Detailed rules explaining key parameters and behaviors
 
 - Plain file sinks forward directly to file close behavior through the wrapped `RuntimeSink`.
-- Queued file sinks flush queue work before closing the wrapped inner file sink.
+- Queued file sinks first drain the queue, then flush the wrapped inner file sink, then close it.
+- For queued file sinks, the returned `Bool` is `true` only when that whole path succeeds and no new write, flush, or rotation failures are observed during the drain-flush-close step.
 - Non-file sinks return `false`.
 - This helper is narrower than generic `close()` because it specifically targets file sink shutdown.
 - After a file-backed configured logger has already cleared its file handle, later `file_close()` calls return `false`.
@@ -59,7 +60,7 @@ When application code wants the file close outcome directly:
 let closed = logger.file_close()
 ```
 
-In this example, the result describes file close behavior rather than generic sink close behavior.
+In this example, the result describes the file-specific close path rather than generic sink close behavior.
 
 ### Error Case
 
@@ -70,10 +71,12 @@ e.g.:
 
 - If callers only need generic sink teardown, `close()` is the broader API.
 
+- On queued file sinks, `true` still does not mean a stronger durability contract than the current backend can report; it means the safe drain-flush-close path completed without a newly observed file failure.
+
 ### Notes
 
 1. Prefer this helper when file-backed runtime behavior matters specifically.
 
-2. Queued file sinks flush pending records before closing the file, unlike generic `close()`.
+2. Generic `close()` now uses the same safe queued-file teardown path.
 
 3. Library or application facades derived from the same configured runtime logger still observe the same underlying file-close state.