Closes#13.
Today GITEA_DEBUG=true only flips the zap level to debug, dumps a
contextless `Text Result:` blob per tool call, and enables the gitea
SDK's own debug stream (which doesn't merge with our log file). That is
not enough to diagnose a misbehaving tool call in production.
This change introduces:
- A `pkg/middleware.ToolLogging` ToolHandlerMiddleware that logs each
tool invocation on entry and exit with structured fields: tool name,
redacted args, request_id, token source, duration_ms, and status. The
request_id is stashed in the context so downstream layers can
correlate.
- A `loggingRoundTripper` in `pkg/gitea` that wraps the shared HTTP
transport and emits one structured line per upstream Gitea API call
(method, token-stripped URL, status, duration_ms, bytes). This
replaces — and is far more useful than — `gitea.SetDebugMode()`.
- An effective-config dump at startup (`logEffectiveConfig`) when
debug+config scope is on, so "did my env var get picked up?" becomes
answerable from the log file.
- Token source tracking. CLI flag / GITEA_ACCESS_TOKEN /
GITEA_ACCESS_TOKEN_FILE / per-request Authorization header are now
distinguished in logs as flag/env/env-file/header.
- A baseline redactor in `pkg/debug` that masks args / query params
whose keys look like secrets (token, password, secret, api_key,
authorization, …). This is the placeholder for issue #5's shared
redactor; once that lands, callers here should defer to it.
- `GITEA_DEBUG_SCOPES` env var to scope debug output to any subset of
`tools,http,config`. Default (unset) is "everything".
Test coverage was added for the redactor, scope flag, request-id
helpers, preview truncation (multibyte-safe), and the middleware's
context wiring + error propagation.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
