pf_app/todo.md

- [ ] should be able to edit and revise forecase segments that constitute baseline or reference. if you edit, maybe a warning that your forecast values wont mean a lot, and have an option to delete them.

  Notes: A baseline/reference segment is a `pf.log` row plus the
  forecast rows it produced (joined by pf_logid). Editing has the
  shape of a delete-then-replay: drop the rows by pf_logid, drop the
  log entry, re-run the segment with the new params (offset, filter,
  iter type), insert the new log entry. New endpoint:
  `PUT /versions/:id/baseline/:logid` (and the same for reference).
  UI: an Edit button on each segment in Baseline view, populating the
  form with the original `params`.

  Cascade warning: if any scale/recode/clone log entries exist *after*
  this segment was added, those operations were calibrated against
  the old totals and will no longer reconcile cleanly. Show a banner
  like "3 forecast operations applied after this segment may be
  invalidated. View / Delete / Continue." Probably want a CASCADE
  option that deletes downstream forecast entries too, plus a plain
  "edit only" option for the user who knows what they're doing.

  Implementation order: API + cascade detection first (compare
  pf.log.stamp ordering); UI second.

- [ ] be able to copy an existing forecast and it's segments to adjust some parameters without having to start from scrath.

  Notes: A version is the unit of copy. Need a `POST /versions/:id/copy`
  endpoint that creates a new pf.version row with the same source/
  col_meta, creates the new fc_<tname>_<id> table via the same DDL
  path, and replays each pf.log entry's INSERT against the new table
  (preserving stamp ordering). Each log entry gets re-inserted
  pointing at the new version_id; the new pf_logid feeds the row
  inserts. Notes/users come along.

  UI: "Copy" button next to each version in Baseline. Copy modal
  asks for a new name and optional description, then runs the API
  call (likely 5–30s for a 350k-row version since every segment is
  re-evaluated). Show progress.

  Two design questions worth deciding up front:
  - Copy as-of-now (re-fetch source data, so freshly-arrived rows
    show up in baseline)? Or freeze (replay from existing forecast
    rows, i.e. clone the forecast table directly)? Different
    semantics, different SQL — pick one before building.
  - Should the copy track its origin? A `parent_version_id` column
    on pf.version makes "show me variants of FY2026 Plan" easy.

- [ ] need the list of filters to have an and/or specification

  Notes: Spec already covers this in `pf_spec.md:245` — `filters` is
  an array of groups; conditions within a group are AND-ed, groups
  OR-ed. Backend has `buildFilterClause` in
  `lib/sql_generator.js:247` but it's not wired into the routes
  (baseline currently takes raw `where_clause`). Wiring + UI is the
  remaining work.

  UI: each group is a card with a header ("Group 1", "Group 2 — OR"),
  rows of `column / operator / values`, a `+ Add condition` link,
  and a `+ Add OR group` button at the bottom. The Baseline view
  already has a single-group filter builder; extend it to wrap the
  current rows in a group container and allow adding more groups.

- [ ] the filters should have the option to just write the WHERE clause SQL

  Notes: Spec covers this too (`pf_spec.md:251`, `:454`) as the
  `raw_where` admin-only escape hatch. The current baseline endpoint
  *already* takes `where_clause` as a raw string — so the API is
  effectively in "raw only" mode today; it's the structured side
  that's missing. Two things to add:

  - Once structured `filters` is wired in, gate `raw_where` behind
    an admin check (`pf_user` in admin list — needs admin list
    config) and reject 400 if both are sent.
  - UI toggle: a "Switch to manual SQL" link in the Baseline filter
    builder swaps the structured rows for a `<textarea>`; warning
    banner: "Raw SQL is not validated. You are responsible for
    correctness and security."

- [ ] load status bar is super jittery and the numbers wildly change

  Notes: `setLoadProgress` fires per chunk in the body-stream reader
  (Forecast.jsx:155–161). On localhost or fast connections the
  reader yields chunks in tight bursts and React re-renders the
  overlay text on each — the visible bytes value flickers because
  paints land out of order with respect to setState batching.

  Fix: throttle to ~10 updates/sec. Either `if (now - lastUpdate >
  100)` before `setLoadProgress`, or accumulate received bytes into
  a ref and flush on `requestAnimationFrame`. Five-line change.

- [ ] default layout for the pivot should be sales_usd group by pending_rep, split by pf_iter

  Notes: Default-layout logic lives in `initViewer` (Forecast.jsx
  ~line 240) and currently picks `group_by = first 2 dimensions`,
  `split_by = date column`. `sales_usd` / `pending_rep` are
  source-specific, so hardcoding them in the view would break for
  any other source.

  Two paths:
  - **Quick**: hardcode for the current source. Cheap, but rots
    the moment a second source comes along.
  - **Right**: store a default-layout config on `pf.source` (e.g., a
    JSON `default_view` column with `{ group_by, split_by, columns }`)
    and let initViewer read it. Setup view gets a small "Default
    pivot" editor — pick a value column, group_by columns, split_by
    column.

  Suggest the right version since the spec already implies
  per-source customization in col_meta, and you're going to want
  this for any future source you register. The col_meta path is
  even tighter: extend col_meta with role flags like `default_value`,
  `default_group`, `default_split` that initViewer reads.