Problem: The merged-but-unreleased voices redesign ships new client-side menu behavior (4-row capped shortlist, pin store, cross-host catalog, Host Studio settings tab) that no server-side lever can revert if it turns out to be defective on a shipped version.
Scope: The v1.13.0..main voices cluster (#470, #476–#480, #486, #492, #512, #514–#517, #520, #522). In scope: the client-side shortlist/pin/render logic and the Host Studio tab. Out of scope: catalog content — that is already server-controlled via GET /voices + the curation manifest (the additive-optional contract in src/tts/VoiceCuration.ts), which can serve a minimal list / omit manifest fields; and building new flag infrastructure on saypi-api.
Reproduction / verification: Per doc/release/kill-switch-policy.md (the crisp test: user-visible failure mode on a shipped version, not neutralizable by an existing server-side lever): if curateShortlist, the pin store, or the Host Studio render has a shipped defect, the in-host voice menus / settings Voices tab break for updated users and saypi-api has no flag that restores pre-redesign behavior — content-shaping is the only lever, and it still exercises the same new code paths. Expected per the policy: a named lever or an explicitly accepted residual risk before the next store release.
Acceptance criteria (either resolves this):
- A recorded founder decision accepting the residual risk for this release (noting the mitigations that exist: menu-never-empty and grandfathering invariants unit-pinned; catalog content server-controlled), referenced from the kill-switch policy's audit appendix; or
- A server-side lever the shipped client honors (e.g. a manifest-served mode/flag the client already reads) that reverts the menus to a safe baseline behavior, with the flag-off state pinned by a unit test.
Notes (non-binding): Found by the one-time flag-coverage audit in #532 / doc/release/kill-switch-policy.md (appendix, 2026-07-07). The manifest is the natural carrier for a lever since the client already polls it every GET /voices.
Problem: The merged-but-unreleased voices redesign ships new client-side menu behavior (4-row capped shortlist, pin store, cross-host catalog, Host Studio settings tab) that no server-side lever can revert if it turns out to be defective on a shipped version.
Scope: The v1.13.0..main voices cluster (#470, #476–#480, #486, #492, #512, #514–#517, #520, #522). In scope: the client-side shortlist/pin/render logic and the Host Studio tab. Out of scope: catalog content — that is already server-controlled via
GET /voices+ the curation manifest (the additive-optional contract insrc/tts/VoiceCuration.ts), which can serve a minimal list / omit manifest fields; and building new flag infrastructure on saypi-api.Reproduction / verification: Per
doc/release/kill-switch-policy.md(the crisp test: user-visible failure mode on a shipped version, not neutralizable by an existing server-side lever): ifcurateShortlist, the pin store, or the Host Studio render has a shipped defect, the in-host voice menus / settings Voices tab break for updated users and saypi-api has no flag that restores pre-redesign behavior — content-shaping is the only lever, and it still exercises the same new code paths. Expected per the policy: a named lever or an explicitly accepted residual risk before the next store release.Acceptance criteria (either resolves this):
Notes (non-binding): Found by the one-time flag-coverage audit in #532 /
doc/release/kill-switch-policy.md(appendix, 2026-07-07). The manifest is the natural carrier for a lever since the client already polls it everyGET /voices.