mirror of
https://github.com/multica-ai/multica.git
synced 2026-07-07 06:19:50 +02:00
a87b3f7b58
PR #4449 wired `execenv.SetFeatureFlags(flags)` in cmd/server/main.go, but the API server process never calls `execenv.InjectRuntimeConfig` — the brief is generated by the daemon process (`multica daemon` from cmd/multica/cmd_daemon.go). Result: setting FF_RUNTIME_BRIEF_SLIM=true on the API server pod would have had zero effect, and the staging rollout would have silently kept rendering the legacy brief. Yushen caught this asking how to configure the flag in K8s; mapping the answer to the actual code surfaced the bug. Fix: - cmd/multica/cmd_daemon.go: construct the feature flag service from the same `MULTICA_FEATURE_FLAGS_FILE` / `FF_<KEY>` env conventions and pass it to `execenv.SetFeatureFlags` right before `daemon.New`. Malformed rule file fails startup loudly, matching the DATABASE_URL parse-error precedent. - cmd/server/main.go: revert the misplaced SetFeatureFlags call. Drop the execenv import (no longer referenced from the API server). Restore the prior `_ = flags` comment shape so future call sites reading the API server's flag service stay grepable. Now to enable slim brief in staging: 1. Set `FF_RUNTIME_BRIEF_SLIM=true` (or `MULTICA_FEATURE_FLAGS_FILE` YAML rule) on **the daemon pods** (where `multica daemon` runs). 2. Restart the daemon pods (`kubectl rollout restart`). 3. Verify via the log line from the first commit on this PR (`brief_mode=slim`) or by `cat`-ing AGENTS.md / CLAUDE.md inside any active task workdir. The API server pods do NOT need the flag set — they don't render briefs. Verification: - go vet ./cmd/... ./internal/daemon/... ok - go build ./... ok - go test ./internal/daemon/... ok - go test ./cmd/multica/... ok Co-authored-by: multica-agent <github@multica.ai>