pf_app/routes
Paul Trowbridge 2337951b65 Store every log entry's segment and bucket instead of deriving them
pf_segment and pf_bucket were resolved at read time through a chain of
fallbacks (label, tag, note, the version's unlabeled_load; the version's
adjustment defaults), repeated in /agg, the /data cursor and the decorate
proc, so nothing but the pivot could say what bucket a row was in.

Now they are written onto pf.log when the entry is created: a load's
label is required and its bucket defaults to the label; an adjustment is
stamped with the version's adjustment_segment/adjustment_bucket, else
the built-ins. Reads become l.label / l.bucket. A log_named CHECK
guarantees both are present, and 01_schema.sql backfills existing
entries with the old read-time rule so no displayed name changes.

The Baseline page's "Fallback names" become "Defaults for new
adjustments"; unlabeled_load is no longer read.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-24 22:35:49 -04:00
..
auth.js Read territory at login, and survive having none 2026-09-18 11:52:00 -04:00
layouts.js Make a pivot layout a thing people own and publish 2026-09-19 14:20:04 -04:00
log.js Store every log entry's segment and bucket instead of deriving them 2026-09-24 22:35:49 -04:00
operations.js Store every log entry's segment and bucket instead of deriving them 2026-09-24 22:35:49 -04:00
plans.js Put the forecasts in the nav, and lock the admin pages down 2026-09-23 01:57:24 -04:00
sources.js Put the forecasts in the nav, and lock the admin pages down 2026-09-23 01:57:24 -04:00
tables.js Put the forecasts in the nav, and lock the admin pages down 2026-09-23 01:57:24 -04:00
versions.js Put the forecasts in the nav, and lock the admin pages down 2026-09-23 01:57:24 -04:00