durar-ai 2026.4.4

package/docs/concepts/usage-tracking.md

@@ -0,0 +1,59 @@
+---
+summary: "Usage tracking surfaces and credential requirements"
+read_when:
+  - You are wiring provider usage/quota surfaces
+  - You need to explain usage tracking behavior or auth requirements
+title: "Usage Tracking"
+---
+
+# Usage tracking
+
+## What it is
+
+- Pulls provider usage/quota directly from their usage endpoints.
+- No estimated costs; only the provider-reported windows.
+- Human-readable status output is normalized to `X% left`, even when an
+  upstream API reports consumed quota, remaining quota, or only raw counts.
+- Session-level `/status` and `session_status` can fall back to the latest
+  transcript usage entry when the live session snapshot is sparse. That
+  fallback fills missing token/cache counters, can recover the active runtime
+  model label, and prefers the larger prompt-oriented total when session
+  metadata is missing or smaller. Existing nonzero live values still win.
+
+## Where it shows up
+
+- `/status` in chats: emoji‑rich status card with session tokens + estimated cost (API key only). Provider usage shows for the **current model provider** when available as a normalized `X% left` window.
+- `/usage off|tokens|full` in chats: per-response usage footer (OAuth shows tokens only).
+- `/usage cost` in chats: local cost summary aggregated from Durar session logs.
+- CLI: `Durar status --usage` prints a full per-provider breakdown.
+- CLI: `Durar channels list` prints the same usage snapshot alongside provider config (use `--no-usage` to skip).
+- macOS menu bar: “Usage” section under Context (only if available).
+
+## Providers + credentials
+
+- **Anthropic (Claude)**: OAuth tokens in auth profiles.
+- **GitHub Copilot**: OAuth tokens in auth profiles.
+- **Gemini CLI**: OAuth tokens in auth profiles.
+  - JSON usage falls back to `stats`; `stats.cached` is normalized into
+    `cacheRead`.
+- **OpenAI Codex**: OAuth tokens in auth profiles (accountId used when present).
+- **MiniMax**: API key or MiniMax OAuth auth profile. Durar treats
+  `minimax`, `minimax-cn`, and `minimax-portal` as the same MiniMax quota
+  surface, prefers stored MiniMax OAuth when present, and otherwise falls back
+  to `MINIMAX_CODE_PLAN_KEY`, `MINIMAX_CODING_API_KEY`, or `MINIMAX_API_KEY`.
+  MiniMax's raw `usage_percent` / `usagePercent` fields mean **remaining**
+  quota, so Durar inverts them before display; count-based fields win when
+  present.
+  - Coding-plan window labels come from provider hours/minutes fields when
+    present, then fall back to the `start_time` / `end_time` span.
+  - If the coding-plan endpoint returns `model_remains`, Durar prefers the
+    chat-model entry, derives the window label from timestamps when explicit
+    `window_hours` / `window_minutes` fields are absent, and includes the model
+    name in the plan label.
+- **Xiaomi MiMo**: API key via env/config/auth store (`XIAOMI_API_KEY`).
+- **z.ai**: API key via env/config/auth store.
+
+Usage is hidden when no usable provider usage auth can be resolved. Providers
+can supply plugin-specific usage auth logic; otherwise Durar falls back to
+matching OAuth/API-key credentials from auth profiles, environment variables,
+or config.

package/docs/date-time.md

@@ -0,0 +1,128 @@
+---
+summary: "Date and time handling across envelopes, prompts, tools, and connectors"
+read_when:
+  - You are changing how timestamps are shown to the model or users
+  - You are debugging time formatting in messages or system prompt output
+title: "Date and Time"
+---
+
+# Date & Time
+
+Durar defaults to **host-local time for transport timestamps** and **user timezone only in the system prompt**.
+Provider timestamps are preserved so tools keep their native semantics (current time is available via `session_status`).
+
+## Message envelopes (local by default)
+
+Inbound messages are wrapped with a timestamp (minute precision):
+
+```
+[Provider ... 2026-01-05 16:26 PST] message text
+```
+
+This envelope timestamp is **host-local by default**, regardless of the provider timezone.
+
+You can override this behavior:
+
+```json5
+{
+  agents: {
+    defaults: {
+      envelopeTimezone: "local", // "utc" | "local" | "user" | IANA timezone
+      envelopeTimestamp: "on", // "on" | "off"
+      envelopeElapsed: "on", // "on" | "off"
+    },
+  },
+}
+```
+
+- `envelopeTimezone: "utc"` uses UTC.
+- `envelopeTimezone: "local"` uses the host timezone.
+- `envelopeTimezone: "user"` uses `agents.defaults.userTimezone` (falls back to host timezone).
+- Use an explicit IANA timezone (e.g., `"America/Chicago"`) for a fixed zone.
+- `envelopeTimestamp: "off"` removes absolute timestamps from envelope headers.
+- `envelopeElapsed: "off"` removes elapsed time suffixes (the `+2m` style).
+
+### Examples
+
+**Local (default):**
+
+```
+[WhatsApp +1555 2026-01-18 00:19 PST] hello
+```
+
+**User timezone:**
+
+```
+[WhatsApp +1555 2026-01-18 00:19 CST] hello
+```
+
+**Elapsed time enabled:**
+
+```
+[WhatsApp +1555 +30s 2026-01-18T05:19Z] follow-up
+```
+
+## System prompt: Current Date & Time
+
+If the user timezone is known, the system prompt includes a dedicated
+**Current Date & Time** section with the **time zone only** (no clock/time format)
+to keep prompt caching stable:
+
+```
+Time zone: America/Chicago
+```
+
+When the agent needs the current time, use the `session_status` tool; the status
+card includes a timestamp line.
+
+## System event lines (local by default)
+
+Queued system events inserted into agent context are prefixed with a timestamp using the
+same timezone selection as message envelopes (default: host-local).
+
+```
+System: [2026-01-12 12:19:17 PST] Model switched.
+```
+
+### Configure user timezone + format
+
+```json5
+{
+  agents: {
+    defaults: {
+      userTimezone: "America/Chicago",
+      timeFormat: "auto", // auto | 12 | 24
+    },
+  },
+}
+```
+
+- `userTimezone` sets the **user-local timezone** for prompt context.
+- `timeFormat` controls **12h/24h display** in the prompt. `auto` follows OS prefs.
+
+## Time format detection (auto)
+
+When `timeFormat: "auto"`, Durar inspects the OS preference (macOS/Windows)
+and falls back to locale formatting. The detected value is **cached per process**
+to avoid repeated system calls.
+
+## Tool payloads + connectors (raw provider time + normalized fields)
+
+Channel tools return **provider-native timestamps** and add normalized fields for consistency:
+
+- `timestampMs`: epoch milliseconds (UTC)
+- `timestampUtc`: ISO 8601 UTC string
+
+Raw provider fields are preserved so nothing is lost.
+
+- Slack: epoch-like strings from the API
+- Discord: UTC ISO timestamps
+- Telegram/WhatsApp: provider-specific numeric/ISO timestamps
+
+If you need local time, convert it downstream using the known timezone.
+
+## Related docs
+
+- [System Prompt](/concepts/system-prompt)
+- [Timezones](/concepts/timezone)
+- [Messages](/concepts/messages)

package/docs/debug/node-issue.md

@@ -0,0 +1,85 @@
+---
+summary: Node + tsx "__name is not a function" crash notes and workarounds
+read_when:
+  - Debugging Node-only dev scripts or watch mode failures
+  - Investigating tsx/esbuild loader crashes in Durar
+title: "Node + tsx Crash"
+---
+
+# Node + tsx "\_\_name is not a function" crash
+
+## Summary
+
+Running Durar via Node with `tsx` fails at startup with:
+
+```
+[Durar] Failed to start CLI: TypeError: __name is not a function
+    at createSubsystemLogger (.../src/logging/subsystem.ts:203:25)
+    at .../src/agents/auth-profiles/constants.ts:25:20
+```
+
+This began after switching dev scripts from Bun to `tsx` (commit `2871657e`, 2026-01-06). The same runtime path worked with Bun.
+
+## Environment
+
+- Node: v25.x (observed on v25.3.0)
+- tsx: 4.21.0
+- OS: macOS (repro also likely on other platforms that run Node 25)
+
+## Repro (Node-only)
+
+```bash
+# in repo root
+node --version
+pnpm install
+node --import tsx src/entry.ts status
+```
+
+## Minimal repro in repo
+
+```bash
+node --import tsx scripts/repro/tsx-name-repro.ts
+```
+
+## Node version check
+
+- Node 25.3.0: fails
+- Node 22.22.0 (Homebrew `node@22`): fails
+- Node 24: not installed here yet; needs verification
+
+## Notes / hypothesis
+
+- `tsx` uses esbuild to transform TS/ESM. esbuild’s `keepNames` emits a `__name` helper and wraps function definitions with `__name(...)`.
+- The crash indicates `__name` exists but is not a function at runtime, which implies the helper is missing or overwritten for this module in the Node 25 loader path.
+- Similar `__name` helper issues have been reported in other esbuild consumers when the helper is missing or rewritten.
+
+## Regression history
+
+- `2871657e` (2026-01-06): scripts changed from Bun to tsx to make Bun optional.
+- Before that (Bun path), `Durar status` and `gateway:watch` worked.
+
+## Workarounds
+
+- Use Bun for dev scripts (current temporary revert).
+- Use Node + tsc watch, then run compiled output:
+
+  ```bash
+  pnpm exec tsc --watch --preserveWatchOutput
+  node --watch Durar.mjs status
+  ```
+
+- Confirmed locally: `pnpm exec tsc -p tsconfig.json` + `node Durar.mjs status` works on Node 25.
+- Disable esbuild keepNames in the TS loader if possible (prevents `__name` helper insertion); tsx does not currently expose this.
+- Test Node LTS (22/24) with `tsx` to see if the issue is Node 25–specific.
+
+## References
+
+- [https://opennext.js.org/cloudflare/howtos/keep_names](https://opennext.js.org/cloudflare/howtos/keep_names)
+- [https://esbuild.github.io/api/#keep-names](https://esbuild.github.io/api/#keep-names)
+- [https://github.com/evanw/esbuild/issues/1031](https://github.com/evanw/esbuild/issues/1031)
+
+## Next steps
+
+- Repro on Node 22/24 to confirm Node 25 regression.
+- Test `tsx` nightly or pin to earlier version if a known regression exists.
+- If reproduces on Node LTS, file a minimal repro upstream with the `__name` stack trace.

package/docs/diagnostics/flags.md

@@ -0,0 +1,91 @@
+---
+summary: "Diagnostics flags for targeted debug logs"
+read_when:
+  - You need targeted debug logs without raising global logging levels
+  - You need to capture subsystem-specific logs for support
+title: "Diagnostics Flags"
+---
+
+# Diagnostics Flags
+
+Diagnostics flags let you enable targeted debug logs without turning on verbose logging everywhere. Flags are opt-in and have no effect unless a subsystem checks them.
+
+## How it works
+
+- Flags are strings (case-insensitive).
+- You can enable flags in config or via an env override.
+- Wildcards are supported:
+  - `telegram.*` matches `telegram.http`
+  - `*` enables all flags
+
+## Enable via config
+
+```json
+{
+  "diagnostics": {
+    "flags": ["telegram.http"]
+  }
+}
+```
+
+Multiple flags:
+
+```json
+{
+  "diagnostics": {
+    "flags": ["telegram.http", "gateway.*"]
+  }
+}
+```
+
+Restart the gateway after changing flags.
+
+## Env override (one-off)
+
+```bash
+Durar_DIAGNOSTICS=telegram.http,telegram.payload
+```
+
+Disable all flags:
+
+```bash
+Durar_DIAGNOSTICS=0
+```
+
+## Where logs go
+
+Flags emit logs into the standard diagnostics log file. By default:
+
+```
+/tmp/Durar/Durar-YYYY-MM-DD.log
+```
+
+If you set `logging.file`, use that path instead. Logs are JSONL (one JSON object per line). Redaction still applies based on `logging.redactSensitive`.
+
+## Extract logs
+
+Pick the latest log file:
+
+```bash
+ls -t /tmp/Durar/Durar-*.log | head -n 1
+```
+
+Filter for Telegram HTTP diagnostics:
+
+```bash
+rg "telegram http error" /tmp/Durar/Durar-*.log
+```
+
+Or tail while reproducing:
+
+```bash
+tail -f /tmp/Durar/Durar-$(date +%F).log | rg "telegram http error"
+```
+
+For remote gateways, you can also use `Durar logs --follow` (see [/cli/logs](/cli/logs)).
+
+## Notes
+
+- If `logging.level` is set higher than `warn`, these logs may be suppressed. Default `info` is fine.
+- Flags are safe to leave enabled; they only affect log volume for the specific subsystem.
+- Use [/logging](/logging) to change log destinations, levels, and redaction.