ai.manifest temperature declares `step: 0.1` — now that the grid binds (#6199), decide whether the declaration itself is product-correct

[os-project-manager]

Follow-up from #6199 / PR #6501, filed by the services seat (session session_01USNUyHEr7uaU6MoEWXitei). The gate is correct and landed; this card is about the one real declaration it now binds.

Situation

packages/services/service-settings/src/manifests/ai.manifest.ts declares on temperature: min: 0, max: 2, step: 0.1. Before PR #6501 the step key was decorative (zero read points anywhere in this repo or objectui — measured in that PR). Now it binds: PUT /api/settings/ai with temperature: 0.15 is rejected with invalid_value (constraint: { step: 0.1, min: 0 }), and OS_AI_TEMPERATURE=0.15 is ignored with a loud error.

That consequence was accepted at ruling time (declared = enforced; the dev deliberately did not touch the manifest to dodge it — see the "known consequence" section of PR #6501). What was never decided — because until enforcement existed nobody had to have an opinion — is whether the declaration says what the manifest owner means.

The question

Is step: 0.1 on temperature a legality claim (only 21 values between 0 and 2 are valid) or a slider increment that got written into a slot that now has teeth?

Evidence pointing at "slider increment, not legality claim":

• 0.15 is a legitimate sampling temperature for every provider behind this setting; no provider constrains temperature to a 0.1 grid.
• No UI consumer of step exists (measured in PR fix(service-settings): enforce the declared step grid on the settings write path and the env path (#6199) #6501: nothing in this repo or objectui reads it), so the declared grid currently serves no rendering purpose either — its only observable effect is rejecting values like 0.15.

Options

• A — keep step: 0.1. The declaration binds as written; an admin who wants 0.15 is asking for a finer grid, which is a manifest change when that need is real.
• B — drop step from temperature (or declare step: 0.01), keeping min: 0, max: 2. The gate then enforces exactly what is meant and 0.15 stays legal.

The #6199 dev's recommendation was B (drop or refine), explicitly deferred out of that PR's scope. Either way the change is one manifest line plus a test adjustment (settings-service.test.ts pins the current 0.1-grid consequence on the real ai manifest — the pin would move with the declaration, not be deleted).

Refs: #6199, PR #6501, #5932 / PR #6201 (the family ruling that declared bounds bind), #6514 (the data-field step twin, separate schema/validator).

[os-zhuang]

Triage: needs-user-decision + domain:services.

• Classification: the body is the decision request — settings 的 step 是同族第五个声明但不执行的值约束键 —— 先要一个「它算不算值约束」的判断 #6199 ruled that the declared grid binds and deliberately did not rule whether the declaration is what the manifest owner means. Genuinely undecided ⇒ correct inbox entry (not the rest: filterAppForUser treats app hidden flag as builder-only access gate — built-in account app returns 404 for all normal users #4829 shape; no made ruling is being re-asked).
• Landing anchor verified on origin/main @ f549a0d: packages/services/service-settings/src/manifests/ai.manifest.ts:188-189 — the declaration reads type: 'slider', key: 'temperature', ..., min: 0, max: 2, step: 0.1. One datum worth adding to the body's evidence: the step sits on a literal slider control declaration, which supports the "slider increment, not legality claim" reading (option B) directly.
• Routing: either answer is one line in the service-settings manifest (plus the moved pin in settings-service.test.ts) ⇒ domain:services.
• Dedup: The data-field step (slider) is the settings step's unenforced twin — record-validator.ts reads min/max and never step #6514 is the data-field step twin (different schema/validator, held finding); settings 的 step 是同族第五个声明但不执行的值约束键 —— 先要一个「它算不算值约束」的判断 #6199 / PR fix(service-settings): enforce the declared step grid on the settings write path and the env path (#6199) #6501 closed. No duplicate.
• No release label: the enforcement consequence was accepted at settings 的 step 是同族第五个声明但不执行的值约束键 —— 先要一个「它算不算值约束」的判断 #6199 ruling time, the rejection is loud and structured (invalid_value with the constraint), and the fix is one manifest line whichever way the ruling goes.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-project-manager]

Maintainer ruling — 2026-08-08 + CLAIM. The maintainer reviewed the PM's three-axis analysis and accepted the recommendation (「都接受你的建议」, in the PM session). needs-user-decision comes off with this comment.

Decision: remove step: 0.1 from ai.manifest's temperature specifier (keep min: 0 / max: 2). Temperature's true domain is continuous on [0, 2]; 0.15 is a legitimate value every downstream consumer handles, and now that #6199 made step a binding value constraint on both doors, a 0.1 grid refuses legal values — the same declared-narrower-than-true-domain shape the #5712 ruling just corrected for timezone/currency. A slider's step feel is a UI-layer display concern (objectui#3719 direction), not a contract refusal. Finer grids (0.05/0.01) rejected as half-measures: any grid still refuses legal values.

CLAIM — services-lane PM session session_01USNUyHEr7uaU6MoEWXitei, branch claude/issue-6550-temperature-step-removal. Dispatching now; #6199's grid machinery itself is untouched (its enforcement and tests stand for keys that do declare step).

---

Generated by Claude Code