Why the model has a narrow job
A recommendation interface becomes unsafe when fluent model text is allowed to invent products, plan terms, prices, or procurement conclusions. The useful unit of analysis is using Kimi for semantic selection while keeping commercial and editorial facts in the verified local catalog. The model can interpret a brief, but the application can deterministically validate IDs and rehydrate canonical evidence. That distinction matters because a polished interface or familiar brand can hide the operating condition that determines whether the route works. Kimi returns only three to six tool identifiers from the supplied allow-list. The review should leave an attributable record rather than a memory of what the page or demo appeared to say. Reject unknown, duplicate, malformed, or out-of-range selections before rendering. This sequence keeps the decision testable by another person and makes later changes easier to audit.
- No model-supplied price is displayed.
- No free-form brief enters analytics.
- Fallback output is never labeled as Kimi.
The request is structured before inference
Advisor collects a role, headcount, market, platforms, budget, current plans, requirements, preferences, and a bounded brief. Start by examining validated field lengths, controlled values, catalog plan IDs, minimum necessary free text, and an explicit request-size ceiling. A structured boundary reduces prompt ambiguity and request-body abuse while preserving the information needed for selection. The purpose is not to reward the product with the longest feature list; it is to see whether a specific team can complete a specific job while preserving evidence, access, and recovery. Invalid or oversized input fails before any provider call. Write the boundary before the trial so a convenient success cannot erase a serious failure. Generate the provider prompt on the server and exclude analytics or client-side credentials. Keep the observed result, source date, owner, and unresolved questions together.
- The API interface remains stable.
- Unknown plans and tools are removed or rejected.
- Provider instructions require strict structured output.
The provider key stays outside the release
The Moonshot key is read from a root-owned file that is mounted read-only into the running container. In practice, the review covers TTY no-echo entry, SSH standard input, root-only secret directory, restrictive file permissions, no command argument, no environment variable, no build artifact, and no log output. A status operation reports only configured or missing, permission quality, and whether the container loaded the file. These details turn a general product claim into an operating test with a clear input and output. Visitors never receive a key input field and the application never exposes the value. Unknown conditions should remain visible instead of being converted into confident prose or a synthetic score. Rotate by setting the file again and deploying the inactive slot. A second reviewer should be able to reconstruct why the team accepted, restricted, postponed, or rejected the route.
- Do not paste the key into chat.
- Do not put the key in .env production files.
- Rollback preserves secret files.
Rate limiting fails closed
A provider key turns a public endpoint into a financial and availability boundary, so local in-memory counters are not sufficient for blue-green production. The control surface here is trusted proxy client address, minute-scoped HMAC identifier, independent server salt, shared SQLite state, atomic increments, expiry cleanup, request ceiling, and provider-call ordering. Raw IP addresses are unnecessary when a keyed short-lived identifier can enforce the limit across both slots. Procurement and workflow design meet at this point: commercial access is valuable only when the required behavior and responsibility exist in the purchased plan. Missing trusted address, salt, database, or successful counter write stops the request before Kimi. Document exceptions because they become the hidden source of extra tools and unsafe workarounds. Caddy overwrites the internal address header and containers share the state mount. The result should describe both the normal path and what happens when the service, network, data, or responsible person is unavailable.
- The client cannot supply the trusted address header.
- Raw IP is not stored in the rate database.
- Local development may use a clearly isolated fallback.
The visible result comes from canonical data
After ID validation, Tool Atlas joins each selected tool to catalog descriptions, paid plans, billing units, official sources, verification dates, and role routes. A credible comparison therefore measures local headline, summary, reasons, Professional and Lean routes, exact plan changes, known totals, unknown totals, risk, and human gates. The application can reproduce these fields without trusting provider prose. List price or output appearance cannot carry the entire decision because change work, permissions, rights, and review obligations remain part of the system. A valid Kimi response is labeled AI-assisted while invalid or unavailable responses use a localized deterministic route. Keep known values separate from unknown values and do not use invented precision to make uncertainty look resolved. Keep provider error bodies out of the UI and logs shown to visitors. Review the result against the same acceptance criteria used at the start.
- Every result links to reviewable tool evidence.
- Prices keep source date, region, and currency.
- The free-form brief never enters a share URL.
A live Kimi result is a release gate
Provider plumbing, a configured file, a healthy candidate container, and a public AI response are four different facts. The release decision brings together inactive-slot deploy, secret mount status, shared rate-limit write, provider response, schema validation, mode equals kimi, public-edge headers, coexistence health, traffic switch, and rollback. Only a candidate smoke request that contains no user free text proves the bounded provider path before cutover. This is where a research note becomes an accountable operating choice rather than a recommendation that nobody owns. Do not switch traffic when the smoke returns fallback, malformed data, or an infrastructure dependency is missing. Preserve the source snapshot and local test so future reviewers can distinguish vendor change from an internal workflow change. Preserve the old slot and restore routing automatically when post-cutover checks fail. Set a fresh evidence date and a rollback trigger; a decision that cannot be revisited safely is incomplete.
- Never claim live Kimi from local fallback.
- Record candidate revision and smoke time.
- Rotate without deleting shared state or old releases.