📝 document runtime sink append path methods

docs/api/index.md

@@ -361,6 +361,9 @@ BitLogger API navigation.
 - [runtime-sink-close.md](./runtime-sink-close.md)
 - [runtime-sink-pending-count.md](./runtime-sink-pending-count.md)
 - [runtime-sink-dropped-count.md](./runtime-sink-dropped-count.md)
+- [runtime-sink-file-path.md](./runtime-sink-file-path.md)
+- [runtime-sink-file-append-mode.md](./runtime-sink-file-append-mode.md)
+- [runtime-sink-file-set-append-mode.md](./runtime-sink-file-set-append-mode.md)
 - [runtime-sink-file-auto-flush.md](./runtime-sink-file-auto-flush.md)
 - [runtime-sink-file-set-auto-flush.md](./runtime-sink-file-set-auto-flush.md)
 - [configured-logger.md](./configured-logger.md)

docs/api/runtime-sink-file-append-mode.md

@@ -0,0 +1,75 @@
+---
+name: runtime-sink-file-append-mode
+group: api
+category: runtime
+update-time: 20260613
+description: Read the current append-mode policy used by a file-backed RuntimeSink.
+key-word:
+    - runtime
+    - sink
+    - file
+    - public
+---
+
+## Runtime-sink-file-append-mode
+
+Read the current append-mode policy used by a file-backed `RuntimeSink`. This helper exposes whether future reopen behavior is currently append-oriented on the runtime sink itself.
+
+### Interface
+
+```moonbit
+pub fn RuntimeSink::file_append_mode(self : RuntimeSink) -> Bool {
+```
+
+#### input
+
+- `self : RuntimeSink` - Runtime sink whose append-mode policy should be inspected.
+
+#### output
+
+- `Bool` - Current append-mode policy for the file sink.
+
+### Explanation
+
+Detailed rules explaining key parameters and behaviors
+
+- Plain `File` runtime variants report the current append policy from the wrapped `FileSink`.
+- `QueuedFile` runtime variants forward the policy from the wrapped inner `FileSink`.
+- Non-file runtime variants return `false`.
+- This helper reports runtime file policy, not whether a file is currently writable.
+
+### How to Use
+
+Here are some specific examples provided.
+
+#### When Need Direct Runtime Append-policy Visibility
+
+When diagnostics should show how future reopen behavior is configured on a `RuntimeSink`:
+```moonbit
+let append = sink.file_append_mode()
+```
+
+In this example, the runtime sink exposes current reopen policy directly.
+
+#### When Validate Direct Policy Changes
+
+When policy mutation should be observable after a direct setter call:
+```moonbit
+ignore(sink.file_set_append_mode(true))
+ignore(sink.file_append_mode())
+```
+
+In this example, callers verify the updated append-mode policy on the runtime sink itself.
+
+### Error Case
+
+e.g.:
+- If the runtime sink is not file-backed, the method returns `false`.
+
+- If callers need the full current file policy rather than just append mode, `file_policy()` is the better API.
+
+### Notes
+
+1. Use this helper when append policy is the only file setting you need to inspect.
+
+2. Pair it with reopen helpers when debugging direct runtime file behavior.

docs/api/runtime-sink-file-path.md

@@ -0,0 +1,74 @@
+---
+name: runtime-sink-file-path
+group: api
+category: runtime
+update-time: 20260613
+description: Read the effective file path used by a file-backed RuntimeSink.
+key-word:
+    - runtime
+    - sink
+    - file
+    - public
+---
+
+## Runtime-sink-file-path
+
+Read the effective file path used by a file-backed `RuntimeSink`. This helper is useful for diagnostics, support output, and confirming which direct runtime file sink is active.
+
+### Interface
+
+```moonbit
+pub fn RuntimeSink::file_path(self : RuntimeSink) -> String {
+```
+
+#### input
+
+- `self : RuntimeSink` - Runtime sink whose file path should be inspected.
+
+#### output
+
+- `String` - Effective runtime file path, or an empty string for non-file sinks.
+
+### Explanation
+
+Detailed rules explaining key parameters and behaviors
+
+- Plain `File` runtime variants return their current file path.
+- `QueuedFile` runtime variants forward the wrapped inner file sink path.
+- Non-file runtime variants return an empty string.
+- This helper is observation-only and does not modify file state.
+
+### How to Use
+
+Here are some specific examples provided.
+
+#### When Need Direct Runtime Path Diagnostics
+
+When code owns a `RuntimeSink` and should show which file is active:
+```moonbit
+println(sink.file_path())
+```
+
+In this example, operators can verify the effective destination path directly from the runtime sink.
+
+#### When Build Support Output From A Runtime Sink
+
+When application state dumps should include file destination info:
+```moonbit
+let path = sink.file_path()
+```
+
+In this example, the path can be surfaced without reading broader runtime state.
+
+### Error Case
+
+e.g.:
+- If the runtime sink is not file-backed, the method returns an empty string.
+
+- If callers need richer file status than just the path, `file_state()` or `file_runtime_state()` is the better API.
+
+### Notes
+
+1. Use this helper for direct runtime path visibility on `RuntimeSink` values.
+
+2. Empty string usually means the runtime sink is not file-backed.

docs/api/runtime-sink-file-set-append-mode.md

@@ -0,0 +1,76 @@
+---
+name: runtime-sink-file-set-append-mode
+group: api
+category: runtime
+update-time: 20260613
+description: Update the append-mode policy used by a file-backed RuntimeSink for later reopen behavior.
+key-word:
+    - runtime
+    - sink
+    - file
+    - public
+---
+
+## Runtime-sink-file-set-append-mode
+
+Update the append-mode policy used by a file-backed `RuntimeSink`. This helper changes future reopen behavior without forcing an immediate reopen on the runtime sink.
+
+### Interface
+
+```moonbit
+pub fn RuntimeSink::file_set_append_mode(self : RuntimeSink, append : Bool) -> Bool {
+```
+
+#### input
+
+- `self : RuntimeSink` - Runtime sink whose append-mode policy should change.
+- `append : Bool` - New append-mode policy.
+
+#### output
+
+- `Bool` - Whether the policy update was applied.
+
+### Explanation
+
+Detailed rules explaining key parameters and behaviors
+
+- Plain `File` runtime variants update their stored append policy and return `true`.
+- `QueuedFile` runtime variants forward the policy update to the wrapped inner `FileSink` and return `true`.
+- This helper updates policy only; it does not force immediate reopen.
+- Non-file runtime variants return `false`.
+
+### How to Use
+
+Here are some specific examples provided.
+
+#### When Need To Change Future Reopen Behavior On A Runtime Sink
+
+When runtime recovery should later prefer append mode explicitly:
+```moonbit
+ignore(sink.file_set_append_mode(true))
+```
+
+In this example, later reopen operations will use the updated append policy.
+
+#### When Want To Separate Policy Mutation From Reopen Timing
+
+When code should update policy now and reopen later:
+```moonbit
+ignore(sink.file_set_append_mode(false))
+ignore(sink.file_reopen_with_current_policy())
+```
+
+In this example, policy mutation and reopen timing remain separate decisions on the runtime sink.
+
+### Error Case
+
+e.g.:
+- If the runtime sink is not file-backed, the method returns `false`.
+
+- If callers need an immediate reopen as part of the same operation, one of the reopen helpers should be used afterward.
+
+### Notes
+
+1. This helper changes stored policy, not live file-handle state by itself.
+
+2. It is useful when recovery logic wants to stage reopen behavior in advance.