The previous commit stopped stored layouts overriding the theme, which
was necessary and not sufficient: nothing was setting it either.
setAttribute('theme', ...) does nothing in 5.4.0 -- the theme is a
ViewerConfig field (ViewerConfig.theme, a theme name) and the element
observes no such attribute -- so the pivot stayed light whatever the
toggle said. Presumably it worked on an older Perspective; CLAUDE.md
documented it and is corrected here too.
A partial restore, so it does not rebuild the view the way applyDepth's
whole-config restore does.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two unrelated changes, in one commit because both touch Forecast.jsx in
ways that cannot be staged apart without an interactive add.
Calculating indicator. Perspective shows a beaker while the view
rebuilds, but it lives in the viewer's status bar, which is only
rendered while the settings panel is open -- so the signal disappears
exactly when the panel is closed and you have nothing else to go on.
Forecast.jsx now raises a counter around the calls that *start* a
rebuild and lowers it after viewer.flush(), broadcasting `pf-pivot-busy`
on the window; StatusBar listens and shows a spinner, following the
`pf-data-changed` pattern already used between the two.
Deliberately not driven from `perspective-config-update`, which was the
obvious hook and is wrong: measured on a depth change over a large
grain, the event arrives *after* the rebuild -- seconds late -- and the
flush that follows resolves in 6ms. It reports the end of the work, not
the start. This therefore covers what the toolbar drives (depth on both
axes, applying a layout) and not sorting or filtering from the viewer's
own chrome, which the app is never told has begun.
Theme. viewer.save() includes `theme`, so every persisted layout had one
baked in, and cleanLayout passed it through -- each restore reasserted
the stored theme and silently undid the light/dark toggle. It is the
reader's choice, not a property of the layout, so it is dropped on the
way in; a published layout can no longer impose its author's theme
either. sameConfig ignores it too, or toggling would light the dirty dot
and offer to save a change nobody made.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The last row-label column is where the deepest level's labels land once
the tree is opened, and nothing was sizing it, so expanding squashed
them against the numbers.
It is column group_by.length. The geometry is now written down, because
the old comment had it wrong and that error steered several failed
attempts: tree_header_offset is group_by.length + 1 and is where the
DATA starts, so the row labels are columns 0..group_by.length -- column
0 the indent gutter, 1..N the N levels. tree_header_offset - 1 is the
last label column, not a data column, and the hidden grand-total column
is the data one at tree_header_offset itself.
A constant rather than a measurement, because only the levels currently
on show have cells: at group_by_depth 1 the deeper label columns are not
in the DOM at all, so the wall is sized before there is anything to
measure. 218px was measured by hand on a rep/customer/month/part tree.
A floor, like the neighbouring 3-char one, so a wall dragged wider
survives the next layout apply.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The floor is the indentation: every row-header column sits at it, and a
level's inset is the previous column's width. Raising it to 12 to give
clipped labels room widened every level's indent by the same amount,
which is the opposite of the compact tree that was wanted. Making a
label readable means letting the text overflow its column, not growing
the column to hold it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A level's indent is the previous column's width, so fitting a
row-header column to its content deepens the inset of everything below
it. Which column got fitted depended on how deep the tree happened to
be drawn when the layout loaded, so one level per layout came back
deeply inset while the rest stepped evenly -- deterministic, and
unreadable as a pattern from outside. fitRowLabels is unwired again and
carries a note saying why, so the next attempt starts from the reason
rather than the idea.
The squashed labels it was meant to fix are addressed by raising
ensureRowLabelWidth's floor from 3 characters to 12. A floor is safe
where a fit is not: it goes under every row-header column equally, so
the levels still step by a constant.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fitting every row-header column widened the indentation bands too, and
since each group_by level is its own column, widening any but the last
moves the start of the one after it -- the deeper bands stepped right.
Only the last column, the wall before the data columns start, can grow
without disturbing the levels above it, so that is the only one resized
now. Every level is still measured, because which column is outermost
depends on the depth on show.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The stepper's depth and ViewConfig's group_by_depth/split_by_depth are
the same unit -- a count of levels to show -- but applyDepth and
applySplitDepth sent d + 1 and every readback subtracted the same 1.
Self-consistent, so the toolbar always agreed with itself, and off by
one against the grid at every position: picking partgroup showed one
level past it. server.cpp turns group_by_depth into set_depth(n - 1)
and t_traversal::set_depth adds the 1 back, so n asks for n levels.
The +1 existed to dodge depth 0, which reaches the engine as
set_depth(-1) on an unsigned t_depth, underflows, and clamps to fully
expanded. The value is floored at 1 instead, so the stepper's "Total"
slot goes on showing the first level as it always has -- the wart is
kept deliberately rather than traded for the underflow. A bare total
needs group_rollup_mode.
Separately: fitRowLabels() has been written and unused since it was
judged to read worse than the default spacing. That judgement has
changed -- row labels come back clipped after a restore -- so it is now
called after both restore paths, initViewer and applyLayout. It is not
routed through the Fit widths button on purpose: that path goes via
regular-table's auto-size, which measures the leaf header's rendered
box over viewport rows only, while fitRowLabels canvas-measures the
label text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Opening the log is almost always to check your own recent work, not
the whole version's, so it now starts on 'mine' -- still resets on
every open rather than persisting, same reasoning as before, just the
other default.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The version this was built against carries 127 adjustments from five accounts,
one of them the reader's, so finding your own meant reading the By column down
the whole list.
Own entries are now marked in place -- a blue rule down the left of the row, the
By cell in blue -- and the modal header carries an Everyone / Mine control with
a count on each. Marked as well as filterable on purpose: the mark tells you
without hiding anyone, the filter is for when you want only yours.
The filter resets to Everyone on every open and is not persisted. A filter that
hides other people's work is fine as a thing you asked for and a trap as a thing
you inherited from last week.
`isMine()` is strict authorship, deliberately not `canUndo()` -- an admin can
undo everything, so marking every row as theirs would say nothing. The fetch
stays unfiltered, since the counts on the control need the whole set.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two defaults both moved price when nobody asked:
A qty edit held the dollars, so price absorbed the whole difference -- 10% more
cases at the same revenue is a 9% price cut, and nothing in the figure being
edited shows it. Dollars now follow qty at the current price:
`value = (curValue / curUnits) * unitsIncr`, on the server in resolveIncrs() and
mirrored in the ledger's Result line. A slice with no units has no price to
hold, so there the dollars stay put and the edit is a pure qty change.
`plug` defaulted to 'price' -- volume holds, price moves -- because that is what
the API did before the flag existed. It now defaults to 'volume'. The client's
stored preference is keyed pf_scale_plug_v2, since a browser carrying the old
'price' choice would otherwise go on moving price silently.
The deliberate routes are unchanged and both outrank the above: name the dollars
and the qty together and price falls out of the two, or name a target_price,
which is the Excel form's Edit Price mode. The ledger labels the column that
cannot move `· holds`, which now includes price on a qty edit.
One behaviour to know about: holding price is impossible on a slice whose value
is zero, so a dollar edit there answers 400 with an explanation where before it
quietly moved price. Fail-loud is the point.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Clicking the blank `partgroup` node under ALTMAN PLANTS selected the customer's
whole $27,588,393.62 (6,851 rows) rather than the $6,198,860.42 (2,421) under
the node clicked -- and the ledger agreed, because the panel totals through the
same filter list the operation writes from. The key was not narrowed, it was
absent, and an absent key means every value of it.
The drop is the engine's: `getCellConfig` builds the click's filter list with
`pivot_value ? [pivot, '==', pivot_value] : undefined`, so a blank group key is
gone before `perspective-click` is dispatched -- and being falsy, so is a
dimension whose value is 0. `cellFilters()` re-derives both axes from
`detail.row.__ROW_PATH__` and the clicked column name instead; the click and a
dragged region now share that one derivation rather than keeping two copies of
the same falsy test.
Both blanks are real here and they are different rows: `partgroup` is null on
51,964 and '' on 111,696. So they stay distinct end to end. `buildWhere` renders
a null as IS NULL, where it used to fall through `esc()` to `= ''` and select
*the other blank* -- the slice naming one node while the operation wrote the
other. In a list the null arm is ORed on, since `IN (NULL)` is never true. The
ledger filters with `is null` rather than `== null`, the engine matching on type
and a null threshold against a string column being the same dropped predicate.
Only `undefined` now means absent, which keeps a subtotal row (a shorter row
path) and a collapsed column level reading as "not part of the slice".
A blank on the *column* axis still cannot be isolated: a column name is its
values joined with '|' and a null joins as the empty string, so the two blanks
are the same text by the time it reaches the client. Those cells are refused
with a message rather than widened.
The panel prints (null) and (blank), and keeps em dash for a column genuinely
absent from the slice -- isolating the blank node and ignoring the column are
opposite statements and read identically before.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Wording variants are a user problem, but the completion was making it one:
a native datalist substring-matches, so typing "moved to different sku"
never offered "moved to a different sku" -- one inserted word and the
existing tag is invisible. Four spellings of that initiative are on the
current version, with a ledger line each.
TagInput matches on words instead. Both sides lowercased, stripped of
punctuation, relieved of stopwords and lightly stemmed, so Pulled Forward
finds Pull Forward. Typing something that reduces to an existing tag
without being it says so: already used as X, use that.
Nothing is merged automatically. The suggestion is offered and the typing
stays yours -- moved to another sku is genuinely a different sentence from
moved to a different sku, and only the person typing knows whether it is a
different thing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The effect that recounts the selection is keyed on `slices`, and neither an
undo nor an operation changes the selection -- so the panel went on showing
totals that included rows it had just removed, or excluded rows it had just
written. Only scale refreshed, and only for itself.
Undo now re-reads the log as well, since the walk lines come from there: an
undone entry has to leave the ledger and not just the table. It runs after
the remove resolves, because fetchCurrentTotals counts through the table's
own views and would otherwise count what was being deleted. It reads
slicesRef rather than slices, being inside a handler registered once.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The six quick-pick pills under it wrapped onto two rows as soon as the tags
were longer than a word, which most are, and the operations panel docked at
the bottom has a fixed height to spend -- so the form ran past its own
border. The same tags complete from the input's datalist, which costs no
space and is not capped at six.
The datalist now carries the tag alone. An option's text content renders as
a second column beside the value, so the use count was widening every row
of the list to show a number nobody picks on.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The list came from every version of the source, joined through pf.version,
so adjusting this year's plan offered last year's initiatives and counted
uses earned somewhere else. A tag names an initiative inside a scenario.
A new version now completes from nothing until it has a tag of its own,
which is what it actually has: cloning a definition copies no adjustments.
The bucket datalist on the Baseline page was already per version, so the
two agree now.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The toolbar was one row of buttons separated by identical hairlines, so a
column width and the version's change history read as peers. Split it: a
view zone on its own ground -- layout, the two depth controls, fit widths,
none of which reach the server -- and the forecast zone that re-loads,
opens a window, or writes.
The row depth buttons were a fixed 0 1 2 3. A number means nothing without
already knowing what group_by holds, and a fixed range offers levels a
two-field pivot does not have while hiding the fifth of one that does.
They are now built from the live group_by and named after the level they
reveal, which is what the column axis already did -- so both are drawn by
one DepthButtons component, since both are the same thing: a depth in
ViewConfig.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
cleanLayout's job is to let a layout outlive the columns it names, and it
walked every config field that carries a column name except aggregates --
which carries one as its key and, in the multi-arg form, a second as the
weight. Empty in practice today, so nothing was breaking; the first
explicit aggregate would have made a later column change abort the whole
restore rather than lose one entry.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Named layouts lived in localStorage: invisible to anyone else, gone on the
next machine, and nothing to publish from. The one server-side layout was
pf.source.default_layout -- a single anonymous blob any account could
overwrite for every account, which is a published layout with no owner.
pf.layout replaces both. A layout is named, owned, and either private or
published; published ones are listed by everyone on the forecast and
writable only by their owner or an admin, the same rule pf.log already uses
for its entries. Scope is the version, since that is the entry point, with
version_id NULL for the source-wide default a new version inherits.
Applying is never restricted -- Save is withheld on a layout that is not
yours, Save as forks it -- because the guarantee wanted is that a published
layout cannot be changed out from under people, not that it cannot be
adapted.
The toolbar's flat chip row becomes one Layout menu: Published and Mine,
rename/publish/default/delete shown only where they would be allowed, and
a dirty dot computed by comparing the live config against the one the pivot
was applied from, since restore() fires the change event itself.
Existing localStorage lists are lifted into pf.layout on first load.
PUT /sources/:id/default-layout is removed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Perspective's auto-pause is on by default, and pausing deletes the view:
AutoPauseState::apply() fires on the viewer's own IntersectionObserver and
on the document's visibilitychange, and set_pause(true) does
view_sub.take().delete(). Coming back is therefore not a redraw but
restore_and_render() -- a fresh view and a fresh traversal of the whole
grain -- which is the multi-second chug on every tab switch, and takes any
per-node expansion with it.
Nothing updates the table while the tab is hidden; every operation is
driven from this page. So the pause bought nothing and cost a rebuild.
Also drops a comment that still described the old set_depth re-apply on
refocus, whose machinery is long gone.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Refresh Data aborted with Table "fc_29" already exists. The name was fixed
per version and the cleanup before it is best-effort: the viewer is still
holding the previous table when the new one is built, so deleting it does
not free the registry entry, and creating a second under the same name
fails.
Nothing reads the name -- the viewer is loaded by reference, and cleanLayout
strips it out of saved configs -- so it only has to be unique. The previous
name is remembered and freed on the next load, when the viewer has let go of
it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Apply Scale sat there live and silent for the whole round trip, so on a large
slice the only sign anything was happening was the absence of a result -- and
a second click applied the change twice.
The button now spins, reads "Applying…", and refuses further clicks until the
write returns, with a line beside it saying the pivot updates when it
finishes. Cleared in a finally, so a failure releases it too.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
It was the literal 'Forecast'. The moment the buckets were renamed to carry
their sort prefix -- '04 - Forecast' -- nothing matched: every row counted as
a comparison rather than a step, so the walk had no middle, the loads came to
nothing, and the bridge showed the basis cancelling itself exactly to zero
with a Forecast anchor of 0.00 over 0 rows.
The version's adjustment_bucket is the right source, being the same value an
unbucketed adjustment is labelled with, so the bridge and the pivot agree by
construction rather than by both hardcoding the same string.
If that value names no bucket in the data -- renamed since, or never
configured -- it falls back to whichever bucket actually holds the
adjustments. A bridge that is merely mislabelled beats one that is silently
empty.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
params says what was asked for. That is not enough to explain a surprising
result, because the same intent produces different rows depending on state
the entry does not carry, and because the translation from intent to SQL is
itself a place bugs live.
So both, not one. env records the state that cannot be reconstructed later:
the territory in force, the version's exclude_iters, and when the template
was generated -- all mutable rows elsewhere with nothing remembering what
they were. sql_text records the statement as executed, territory and scope
already resolved into it.
The template generation is a fingerprint rather than a version. It cannot
bring the old template back; it can tell you the entry did not run under the
current one, which is what would otherwise make a comparison quietly wrong.
Generate SQL has overwritten those templates four times today.
The statement is fetched on demand through GET /log/:logid/debug and left out
of the list, which is opened to scan rather than to read SQL. Under an
entry's payload in the change log there is now an "executed SQL" toggle.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
PATCH /log/:logid had no check, so any account could edit the tag, note,
label and bucket of any entry -- including loads whose rows it cannot see.
That reads as harmless annotation and is not: label and bucket name the
pivot's columns for everyone in the version, so a rep could rename the
company's segments.
Same rule as undo now, author or admin, with the fields shown read-only
rather than editable-then-403 -- in the change log's tag and note cells and
on the Baseline page's label and bucket.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The change log showed what happened and never who did it, which stops being
a detail the moment more than one person is in the version.
The Undo button greys out on entries belonging to someone else, with the
reason on hover. The server already refused them; the button offered the
click anyway and answered with a 403, which reads as a fault rather than a
rule.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The login query names its columns, and territory and is_admin were not among
them -- so every session carried an empty list, every account scoped to
FALSE, and the forecast page came back with nothing however the grant was
set. The CLI had written it correctly; nothing read it.
The empty case then aborted twice over. First on the index, fixed already.
Then on the layout: an empty table has no schema, so restoring a saved
config asks for the dtype of a column that is not there and the worker dies
-- "Could not get dtype for column `sseas_e`". With no rows there is nothing
to lay out, so nothing is restored, and the saved layout waits in
localStorage for rows to come back.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
worker.table([], { index: 'pf_gkey' }) aborts: an empty array carries no
columns, so the index names one that does not exist and the page dies with
"Specified index `pf_gkey` does not exist in dataset" instead of saying it
found nothing.
Nothing is a legitimate answer -- an empty version, and now a territory with
no rows in it, which is what surfaced this. The empty table is built without
an index and the page says which of the two it is.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The walk read from tag and note, and hardcoded the word "Baseline" for the
baseline load -- so a segment called 03 - New Orders in the pivot, in the
bridge and on the Baseline page read as "Baseline" in the one place you go
to check a number before changing it. label comes first now, the same
precedence pf_segment uses, in the ledger and the bridge alike. logMeta did
not carry label at all, which is why neither could reach it.
The immovable rows split one line per segment. Combined, "01 - YTD Sales ·
02 - Open Orders" said 1.6m was untouchable without saying how much of it was
billed and how much was booked -- different things a forecaster treats
differently. The FINAL badge also gains the space it was missing, having
rendered as "02 - Open Ordersfinal".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Perspective pads a subtotal's column path to full length rather than
shortening it -- ['04 - Forecast', '', 'sales_usd'] -- so testing for
an empty string found no subtotals and nothing was tinted. The blank test now
strips zero-width spaces and the other invisibles alongside whitespace.
The grand total falls out of the same rule, its path being blank at every
level above the measure.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Prior, plan and forecast each carry twelve months and a total, so scanning
across is thirty-odd columns of identical-looking numbers with nothing to say
where one domain ends and the next begins -- annual figures read as just
another month.
Each group's first column now takes a left rule and each group's subtotal a
tint and a heavier weight. Both are derived from the cell's column path: the
deepest path is a leaf, so anything shorter is an aggregate of the levels
below it, which is what makes a subtotal a subtotal.
Through regular_table's style listener rather than CSS, because the DOM cells
are recycled across columns as you scroll -- a stylesheet would paint the
wrong ones the moment the grid virtualised. The styles go into the grid's own
shadow root, since a page stylesheet cannot reach it, and use currentColor so
the rule follows the theme instead of disappearing against Pro Dark.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The panel's preview calls buildPayload itself, and the scope arrived as a
parameter that the preview had no way to supply -- so it defaulted to empty
and printed a payload with no scope for a write that had one. A preview that
disagrees with what is sent is worse than no preview: it is the one place
someone looks to check before committing a change.
buildPayload reads the scope from the ref instead, so there is one payload
and both callers get it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Refusing anything but == was safe and useless: a view bounded to
sseas_e <= 2027 is an ordinary way to scope a forecast, and it has no slice
form at all, a slice being {col: value}. The filter now travels beside the
slices as [col, op, value] triples and is ANDed onto every unit -- not folded
into the slices, since it applies to all of them equally and under
apply_mode 'each' would just repeat itself in every statement.
Operators are Perspective's, since that is where they come from, and the list
is a whitelist: anything outside it is refused rather than ignored, because a
scope silently dropped is a write wider than the panel that authorised it.
The scope goes into the log's params too, so the audit trail records what
bounded the write and not only what was clicked.
The panel prints it above the selection as "within sseas_e <= 2027". It
scopes every figure below it and every row the operation writes while
appearing in none of the slices, so without it the panel showed a selection
wider than the one it was acting on -- which is exactly what made the
ledger's 956,485.13 look plausible against a cell of 921,225.71.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
X-Row-Count is exact but travels with the response headers, and in grain mode
the server aggregates the whole table before sending any -- so the number
appeared just as the fifteen-second wait ended, which is no use to anyone
watching it.
The forecast table's own count goes up first instead, from the same
table-info the status bar already reads, and the exact figure replaces it
when the headers arrive. The count query is deliberately not awaited: it
scans the whole table, and the load must not wait on a progress message.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
perspective-click reports only the clicked cell's own dimensions -- the
view-level filter is not in it -- so a slice never carried the season the
grid was scoped to. The ledger therefore counted rows the grid was hiding
(921,225.71 on screen against 956,485.13 in the panel) and an operation
would have written them.
Both now read the filter off the viewer. The ledger applies it to its own
view, where the values are already in the table's types and any operator
works. The operation merges the equalities into each slice, cell values
winning on a shared column since a cell cannot contradict the filter it was
drawn inside, and refuses outright on any other operator: a range or an
in-list cannot travel in a slice, and dropping it silently is the widening
this is meant to stop.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
X-Row-Count arrives with the headers, long before the body has been read, so
the overlay can name the wait instead of saying "Loading…" over a grey
screen for fifteen seconds. On this data the row count *is* the wait -- the
bytes are quick and the rows are not -- so it is the number worth showing
beside the transfer bar, which only ever measured the fast part.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A slice carries every value as a string -- built from filters the grid
reports, and shaped to survive JSON on the way to the API. Perspective
matches on type, and a string '2027' against an integer column is not a
filter that matches nothing, it is a filter that is dropped.
So the pivot's own season filter never reached the ledger: with the grid
scoped to sseas_e = 2027 the ledger totalled 956,485.13 against a cell
reading 921,225.71, the difference being eleven rows of a baseline segment
whose shipments fall in the next season. Only dates were being coerced, and
only because someone had hit this before with them.
Values are now typed against the loaded table's schema rather than against
col_meta's role, which is the thing that actually decides the match. The
server side was already right -- Postgres casts the literal -- and returns
921,225.71 for the same slice.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Clicking a bucket subtotal with the month level collapsed produced
{"customer": "...", "pf_bucket": "04 - Forecast", "smon_e": "sales_usd"} --
a month equal to a measure, matching nothing, so the ledger came back empty
and an operation would have had no rows to act on.
Perspective maps split_by positionally over the column name, and a collapsed
axis has fewer segments than there are split_by levels, so the measure lands
on the first hidden dimension. Both slice paths now drop any == filter whose
value is one of the view's measures; the region path additionally takes the
measure off the end of the column name before mapping, which is the same
error made in our own code.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The phantom: pf_segment and pf_bucket are computed from pf.log when the rows
are served, so buildWhere had no column to compare and dropped them. Clicking
one bucket's cell and scaling therefore wrote every bucket at that dimension
intersection, while the panel showed only the bucket clicked. On the example
slice that is 350,524.74 displayed against 503,446.08 written.
They resolve exactly, without a new column: the name lives on the log row and
every forecast row carries the pf_logid that points at it, so the predicate is
pf_logid IN (SELECT id FROM pf.log WHERE <the same expression> = ...). Verified
against version 29 -- the clause returns 350,524.74 over 12 rows.
Any other pf_ key is now refused rather than skipped, since skipping is the
mechanism by which a selection silently widens. pf_iter stays exempt: the
client drops it deliberately, two cells differing only by iter band being the
same slice.
Client side they are ordinary columns in the loaded table, so both the
dispatch path and the panel's own totals filter on them directly -- the latter
matters as much, or the ledger reconciles against a wider selection than the
operation writes.
The ledger: excluded rows read "02 - Prior Year · FINAL" in amber rather than
"reference · fixed" -- named by the segment a forecaster recognises instead of
the iter band that happens to exclude it, and coloured because immovable is a
property worth seeing before reading a number. When the whole selection is
immovable it now says so in a sentence, where before it printed a row of zeros
and left the reason to be inferred from the edit rows failing below.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
bucket_order and log.seq were still settable -- PUT /versions/:id took the
first, PATCH /log/:logid the second -- with nothing left to read either. A
field that only ever gets written is worse than a missing one: the call
succeeds, so the caller has no way to find out it did nothing.
The columns themselves stay, marked vestigial where they are declared.
Dropping a column is not worth a migration to reclaim two that cost nothing.
pf.log.bucket is untouched and stays exactly as it was -- what a row counts
toward, read first by BUCKET_EXPR. It is the bucket *order* that no longer
needs storing, the text having become the order.
Also removes a comment head in Forecast.jsx that survived its function and
had glued itself onto fitColumns.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
With the prefix stored in pf.log.label there is nothing left to compute, so
all of it goes: ORDER_EXPR_NAMES, buildOrderExpression and its ExprTK
printable-ASCII-per-byte guard, SYNTHETIC_SEGMENTS and its 98/99 ordinals,
syncOrderExpressions with its two self-issued fetches, the dbgOrder tracing,
and the three places it had to be re-applied because restore() replaces
`expressions` wholesale.
What remains is a list of the names it used to manage, stripped by
cleanLayout so a layout saved under the old scheme does not keep ordering by
a rule nothing updates. The strip goes before the axis filter: dropping them
from `expressions` is what makes the existing ok() reject them on every axis,
which restore() requires -- an expression the pivot is using cannot vanish
from underneath it.
Net 250 lines out. The Baseline page's reorder buttons no longer feed
anything and go next.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
130px was far too wide — it was a guess, and it turned the row labels into a
quarter of the sheet. The floor only needs to stop a column coming back
unusable after a layout restore, not to fit anything.
Three characters, measured in the grid's own font plus its cell padding
rather than fixed in pixels, so it survives a theme or zoom change.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Loading a saved layout brought them back a few pixels wide, needing to be
dragged open by hand. Restoring resets the widths, and the row-header
columns are then sized from their header — which for row headers is a blank
corner cell — so they measure as empty.
A minimum rather than a fit. Fitting to content is the other extreme: each
group_by level is its own column, so the first widens to its longest label
and shoves the second rightwards, which is the spacing that read worse than
the default. 130px leaves a reasonable default alone and only intervenes
where a column came back unusable; anything already wider, whether dragged
or recorded in a layout, is untouched.
Applied after the initial load and after a layout restore — the two places
that reset widths.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Each group_by level is its own row-header column, so fitting the first to
its longest label pushes the second to start after it — and the default
spacing reads better than the fitted result, cap or no cap. Fit now sizes
the data columns only, which is what it was doing when it was useful.
fitRowLabels is kept, unused, one call away: the measurement was the hard
part and the judgement about whether to apply it may change.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Switching to a saved layout dropped pf_bucket_ord and pf_segment_ord.
restore() replaces `expressions` wholesale rather than merging, and a layout
saved before the feature existed carries none to restore — the same fault
initViewer had, fixed there and not generalised.
The layout is persisted from the merged config afterwards, so the saved copy
picks the expressions up rather than re-dropping them on the next load.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Each group_by level is its own row-header column, so fitting the first to
its longest label pushes the second to start after it — which reads as the
deeper level being indented past the end of the shallower one, and sends the
rest of the pivot off to the right when a label is long.
Capped at 260px, which trades a rare truncation for a sheet that stays
legible. And taking the max with the current width means Fit only ever
widens, so a width set by dragging is not undone by pressing it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Row labels still did not fit, because the override was landing on the wrong
column. restore_column_size_overrides maps the key "__ROW_PATH__" to index
tree_header_offset - 1, which with two group_by levels is index 2 — the
first data column. That column is the grand total, which the stylesheet
hides, so pinning it changed nothing visible.
The row labels are separate columns (rt-col-0 and rt-col-1 here, one per
group_by level), so each is measured on its own and set by index through
regular-table's saveColumnSizes / restoreColumnSizes, which are index-based
and public.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
It works now — inputs carrying a bucket_order and three seq values, both
expressions applied — so the console does not need narrating, least of all
during a demo.
Kept rather than deleted, gated like the depth tracing: the failure it
diagnosed (running before its inputs existed, then reporting nothing) is the
kind that recurs, and rebuilding this each time is wasted work. The
initViewer scaffolding goes, having served its purpose.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"Bucket" and "Segment" sit too close to the source data -- segment_new is an
actual column here -- and a name collision would be worse than a confusing
label: an expression named after an existing column shadows or rejects it
rather than just reading ambiguously.
pf_ prefixed like every other synthesised column, so they sort beside
pf_bucket and pf_segment in the column list and read as belonging to the app.
The old names are kept in the managed list so they are cleared from configs
that still carry them. Without that they would sit in saved layouts forever,
ordering by a rule nothing updates -- which is exactly what a stale Segment
expression was already doing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The instrumentation finally said it plainly:
inputs {versionId: '29', versionFound: false, bucket_order: null,
logMetaCount: 0, seqs: []}
It read the `versions` prop and the `logMeta` state, both populated
asynchronously, while running from initViewer — which finishes well before
them on a large load. So it was called with nothing every time, could never
build an expression, and the effect meant to re-run it once the data landed
never fired. Two small queries beat depending on that timing, the same
correction the master-data effect needed for the same reason.
Also explains why the ordering half-worked: `existing: Array(1)` with
Segment already applied. An earlier session had built it and it has been
riding in the saved layout since, so segment ordering appeared to work while
Bucket never existed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The earlier attempt at this never landed: its patch failed an assertion, and
I read a `grep -c "pf-order"` of 1 as confirmation when that count is just
the logger's own template literal — every call site was missing. So the
function was reached, returned silently, and reported nothing, twice over.
Logs on entry, the inputs it resolved, the expressions already in the saved
config, and each exit. Verified against the source and against the
individual strings in the built bundle rather than a count.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
