Z.ai temporary campaign policy: date-bounded blackouts so the Sep 25 – Oct 7 2026 all-day off-peak campaign stops wrongly excluding Z.ai at nominal peak hours #154

New issue

Closed

opened 2026-09-28 10:20:53 +00:00 by kilo · 0 comments

kilo commented

2026-09-28 10:20:53 +00:00

Member

Problem

The shipped default selector policy (examples/selector-policy.json, provisioned on first use) models Z.ai peak hours as a standing weekly blackout zai-peak-hours-sgt (Mon–Fri 14:00–18:00 Asia/Singapore, reason preserve_zai_offpeak). Z.ai's official documentation (Plan Update Announcement; GLM Coding Plan overview) states that from September 25 through October 7, 2026 all-day usage is charged at the off-peak rate. During that period the standing blackout still fires in every nominal peak window, so an otherwise eligible request constrained to zai/glm-5.3 or zai/glm-5.3-flash is excluded at policy_blackout / preserve_zai_offpeak even though the plan is billed at the cheap off-peak rate — the opposite of the rule's conservation intent.

The same documentation extended the GLM-5.3-Flash Usage Campaign through October 7, 2026; the shipped happy-hour rule zai-flash-campaign-night-sgt still carries the stale end_date: "2026-09-20".

Change (policy correctness only — no ranking redesign)

Date-bounded blackouts (amends D-026 by reusing D-035's exact semantics). WeeklyBlackoutRule gains the same optional inclusive local calendar bounds start_date/end_date (YYYY-MM-DD, in the rule's zone, start_date <= end_date) that WeeklyHappyHourRule has had since D-035, backed by one shared implementation so the two rule kinds cannot drift at boundaries. A blackout whose weekly window matches but whose date bounds exclude the instant does not block, and is surfaced by the mirrored explanation-only is_date_expired_at plus the additive SelectionDecision member expired_blackout_rules (serialized only when non-empty; same shape as expired_happy_hour_rules). Policy documents without the new keys load and round-trip unchanged (additive, machine-interface v1 per the D-039/D-035 precedent).
Shipped default encodes the temporary campaign explicitly. The standing blackout becomes two dated rules — zai-peak-hours-sgt with end_date: 2026-09-24 and zai-peak-hours-sgt-post-campaign with start_date: 2026-10-08 — so between September 25 and October 7 no peak blackout applies (all-day off-peak rate) and normal peak behavior resumes automatically on October 8 without another change. zai-flash-campaign-night-sgt is extended to end_date: 2026-10-07. The permanent baseline weekly schedule is otherwise unchanged; peak logic is NOT disabled globally.
Docs + decision record. docs/selection-policy.md and README.md updated in place (campaign names, official source URLs, Asia/Singapore calendar, start/end, affected models, effective behavior); docs/decisions.md gains D-059 recording the amendment and sources.

Explicitly out of scope (recorded, not silently dropped)

The Flash campaign's execution-method split (zero quota via ZCode ≥ 3.10 / AutoClaw vs doubled quota via other supported agents; 5 h/week cap interaction) is NOT automatable in the selector: there is no authoritative per-request execution-source identity or version (D-053 sources are administrator grants bound to workers, not request attestation). The happy-hour rule stays the honest representation — a ranking preference inside the documented nightly window, never an eligibility or zero-cost claim; exhaustion still excludes (weekly-cap small print). This boundary is documented, not faked.
No qualitative ranking change, no harness/source redesign, no HTTP/SSE/worker/gateway work.

Required regressions

Policy unit: blackout date-bound validation (ordering, format), inclusive bounds, weekly-window × dates interaction, blocks_at boundary instants, is_date_expired_at semantics, serialization round-trip, old documents unchanged.
Example-policy selection: Thu 2026-09-24 15:00 SGT blocked; Fri 2026-09-25 00:00 and 15:00 SGT not blocked; weekend inside the campaign unchanged; Wed 2026-10-07 15:00 and 23:59 SGT not blocked; Thu 2026-10-08 14:00–18:00 blocked again; preserve_zai_offpeak absent from exclusions during the campaign; expired_blackout_rules names the parked rule and is absent when empty.
Flash campaign: preferred inside the nightly window through the inclusive end date 2026-10-07, not preferred on 2026-10-08; GLM-5.3 never targeted; preference never bypasses exhaustion or hard constraints (existing invariants re-asserted).

Security classification

Not security-critical (user-policy semantics + shipped example + docs; no credentials, transport or execution-surface changes). Independent exact-head review mandatory; UX impact assessment mandatory (the fix removes a wrong exclusion; the new expiry signal answers "why did my blackout go quiet?").

Workflow

Branch policy/zai-temp-campaigns from develop @ 81b8e63; PR targets develop, left open for human review; never merged by agents. Budget: 120 min wall clock.

## Problem The shipped default selector policy (`examples/selector-policy.json`, provisioned on first use) models Z.ai peak hours as a standing weekly blackout `zai-peak-hours-sgt` (Mon–Fri 14:00–18:00 Asia/Singapore, reason `preserve_zai_offpeak`). Z.ai's official documentation (Plan Update Announcement; GLM Coding Plan overview) states that from **September 25 through October 7, 2026 all-day usage is charged at the off-peak rate**. During that period the standing blackout still fires in every nominal peak window, so an otherwise eligible request constrained to `zai/glm-5.3` or `zai/glm-5.3-flash` is excluded at `policy_blackout` / `preserve_zai_offpeak` even though the plan is billed at the cheap off-peak rate — the opposite of the rule's conservation intent. The same documentation extended the **GLM-5.3-Flash Usage Campaign** through October 7, 2026; the shipped happy-hour rule `zai-flash-campaign-night-sgt` still carries the stale `end_date: "2026-09-20"`. ## Change (policy correctness only — no ranking redesign) 1. **Date-bounded blackouts (amends D-026 by reusing D-035's exact semantics).** `WeeklyBlackoutRule` gains the same optional inclusive local calendar bounds `start_date`/`end_date` (`YYYY-MM-DD`, in the rule's zone, `start_date <= end_date`) that `WeeklyHappyHourRule` has had since D-035, backed by one shared implementation so the two rule kinds cannot drift at boundaries. A blackout whose weekly window matches but whose date bounds exclude the instant does not block, and is surfaced by the mirrored explanation-only `is_date_expired_at` plus the additive `SelectionDecision` member `expired_blackout_rules` (serialized only when non-empty; same shape as `expired_happy_hour_rules`). Policy documents without the new keys load and round-trip unchanged (additive, machine-interface v1 per the D-039/D-035 precedent). 2. **Shipped default encodes the temporary campaign explicitly.** The standing blackout becomes two dated rules — `zai-peak-hours-sgt` with `end_date: 2026-09-24` and `zai-peak-hours-sgt-post-campaign` with `start_date: 2026-10-08` — so between September 25 and October 7 no peak blackout applies (all-day off-peak rate) and normal peak behavior resumes automatically on October 8 without another change. `zai-flash-campaign-night-sgt` is extended to `end_date: 2026-10-07`. The permanent baseline weekly schedule is otherwise unchanged; peak logic is NOT disabled globally. 3. **Docs + decision record.** `docs/selection-policy.md` and `README.md` updated in place (campaign names, official source URLs, Asia/Singapore calendar, start/end, affected models, effective behavior); `docs/decisions.md` gains D-059 recording the amendment and sources. ## Explicitly out of scope (recorded, not silently dropped) - The Flash campaign's execution-method split (zero quota via ZCode ≥ 3.10 / AutoClaw vs doubled quota via other supported agents; 5 h/week cap interaction) is NOT automatable in the selector: there is no authoritative per-request execution-source identity or version (D-053 sources are administrator grants bound to workers, not request attestation). The happy-hour rule stays the honest representation — a ranking preference inside the documented nightly window, never an eligibility or zero-cost claim; exhaustion still excludes (weekly-cap small print). This boundary is documented, not faked. - No qualitative ranking change, no harness/source redesign, no HTTP/SSE/worker/gateway work. ## Required regressions 1. Policy unit: blackout date-bound validation (ordering, format), inclusive bounds, weekly-window × dates interaction, `blocks_at` boundary instants, `is_date_expired_at` semantics, serialization round-trip, old documents unchanged. 2. Example-policy selection: Thu 2026-09-24 15:00 SGT blocked; Fri 2026-09-25 00:00 and 15:00 SGT not blocked; weekend inside the campaign unchanged; Wed 2026-10-07 15:00 and 23:59 SGT not blocked; Thu 2026-10-08 14:00–18:00 blocked again; `preserve_zai_offpeak` absent from exclusions during the campaign; `expired_blackout_rules` names the parked rule and is absent when empty. 3. Flash campaign: preferred inside the nightly window through the inclusive end date 2026-10-07, not preferred on 2026-10-08; GLM-5.3 never targeted; preference never bypasses exhaustion or hard constraints (existing invariants re-asserted). ## Security classification Not security-critical (user-policy semantics + shipped example + docs; no credentials, transport or execution-surface changes). Independent exact-head review mandatory; UX impact assessment mandatory (the fix removes a wrong exclusion; the new expiry signal answers "why did my blackout go quiet?"). ## Workflow Branch `policy/zai-temp-campaigns` from `develop` @ `81b8e63`; PR targets `develop`, left open for human review; never merged by agents. Budget: 120 min wall clock.