Paul Trowbridge 2689e95b2c Count adjustments as Forecast rather than their own banner ... pf_bucket mirrored pf_segment for scale/recode/clone rows, so adjustments showed as '(adjustment)' -- a banner of their own, sitting outside the forecast they are adjustments to. Grouping by pf_bucket therefore split the forecast in two. An adjustment is always part of the forecast: exclude_iters keeps operations off the reference segments, so there is no adjustment that is not. It falls back to 'Forecast' now, and still yields to an explicit bucket on its own log entry. pf_segment keeps '(adjustment)', which is right there -- it answers which segment a row came from, and an adjustment came from none. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>		2026-09-17 01:03:34 -04:00
..
auth.js	Put the app behind a login	2026-09-14 22:20:25 -04:00
log.js	Let a segment say what it counts toward, and pivot on it	2026-09-17 00:59:00 -04:00
operations.js	Count adjustments as Forecast rather than their own banner	2026-09-17 01:03:34 -04:00
sources.js	Keep master data for a dim_group instead of re-deriving it from the source	2026-09-17 00:19:39 -04:00
tables.js	Expose pf_note/pf_op in forecast data; fix tables list duplicates	2026-04-28 19:51:45 -04:00
versions.js	Complete recode values from the version, not the source view	2026-09-17 00:03:05 -04:00