Forecast and Total selected differed only in weight, and the Total line's
running figure was bold either way, so neither read as the target. The
basis row is now tinted and tagged, and clicking either row selects it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The stepper's middle is sized to the axis's longest level rather than the
current one, and Save and the dirty dot keep their slots while hidden, so
nothing shifts under the cursor.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Each axis's depth stepper is now one joined control, styled like the
operation panel's Scale | Recode | Clone, so the arrows are visible and
tell enabled from disabled in dark mode. The Total checkboxes become
toggle chips beside their stepper. Operations shows its open state as
pressed rather than relabelling to a blue "Hide panel", keeping blue
for actions. The zone boxes are gone; the gap between the zones already
separates them. The layout name gets more room before it truncates.
color-scheme: dark on the dark palette fixes native controls app-wide.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Both named an adjustment by its label first. Every log entry now carries
a label -- adjustments all get the version's adjustment segment -- so every
adjustment fell under that one name and no tag was ever shown.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The chart's text and rules were hex literals, so in dark mode the value
labels stayed dark grey on the dark panel. They now follow the theme.
The panel drags by its header and is no longer modal: the backdrop passes
clicks through, so the pivot stays usable while the bridge is open, and
Escape closes it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
bg-gray-50/60 is its own class, so the .bg-gray-50 override never reached
it and the band stayed light grey in dark mode.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Both totals travel in the layout as pf_totals { row, col }: added by
captureConfig, stripped by cleanLayout before restore(). The grand-total
column, previously always hidden by GRID_CSS, now hides only without
data-pf-col-total. Layouts saved before the key get row shown, column
hidden.
The group rule is skipped when every column group is one column wide --
one split level and one measure -- where it separated nothing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The engine has no rollup mode that keeps subtotals and drops the grand
total, so the row is hidden in the grid's style listener instead.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The engine renders a null split_by value as the literal "null" in the
column name (t_tscalar::to_string on an invalid scalar) and an empty
string as ''. cellFilters() passed "null" through as a value, so a
slice over a blank segment_new became segment_new = 'null', matched no
row, and the adjustment wrote nothing. '' was refused outright, on the
mistaken belief that the two blanks joined to the same text.
Both are now mapped back: "null" to null, '' to ''.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
date_offset moves the put-back leg of a recode while the negative leg
stays put, so a shifted recode is a timing move (pull forward, push
out); with a shift, set may be empty. Period dimensions on the moved
rows are re-derived from pf.dim_period against the shifted date, except
where the date is null, where the existing label is kept. No shift, no
derivation: a plain recode is unchanged.
The Recode form gets the same "Shift dates" field as Clone, blank by
default and cleared after each post.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
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>
Direction was a prop, which only moved the clipping around: the panel is
an overflow-auto box, so a popover below a setting near the bottom is
cut by the dock's edge and one above a control near the top is cut by
its top. The box is `fixed` now, placed from the icon's own rect, so it
leaves the dock altogether -- it prefers up everywhere and flips down
only when the window itself has no room above. Scrolling closes it,
since a fixed box cannot follow its anchor.
Drops the dir prop and the `Change` icon's downward special case.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Opening downward put the popover under controls that already sit low in
a scrolling dock, so the dock's edge cut it off. Up is the default now;
`dir="down"` is for the few at the top of the panel, where up is the
clipped direction.
Scale, recode and clone each get one, and so does Post -- the three
controls that actually change the version were the three with no
explanation anywhere. They say what happens to the numbers and what is
left alone: that scale writes the difference as new rows rather than
editing what is there, that recode writes a negative and a positive
under one entry, that clone leaves the original, and that Post is one
change-log entry which undoes whole.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"01 - YTD Sales · 02 - Open Orders can't move — the forecast absorbs
it" was printed under its toggle, and a line of prose beside a toggle is
skipped while still costing the dock a row. Every Field's hint is now a
? next to the control: hovering gives it (a native title, which nothing
clips), clicking pins it in a small popover.
The Per slice row goes with them -- what it said belongs to Apply, whose
help now covers both modes, and the ledger already marks its rows (all)
and (each).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Button labels are capitalised and font-medium, the segmented groups
carry a border and a shadow of their own. An inactive segment used to
be white text-on-white inside a group border, which is why none of
them read as something you could press.
- Each section says what it is: the operation strip, LEDGER (or RECODE
TO / CLONE TO, which is what the form under those two operations is),
SETTINGS over the toggles, LABEL THIS CHANGE.
- Together/Each moves down beside Price/Volume and Forecast/Total, in a
wrapping row. Three one-line settings stacked cost three rows of a
dock that is 260px tall to begin with, and they are read together
anyway: what absorbs the change, what it is measured against, and
whether it applies once or per slice.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A highlight is a rectangle of grid coordinates. Post a decrease on a
grid sorted by sales descending and the customer drops down the list,
while the highlight holds the coordinate and comes to rest over whoever
took that position. `slices` is value-based, so the panel goes on
writing to the customer it always meant -- the grid is the only thing
that lies, which is the worst place for the lie to be.
The rectangles are re-derived from the slices now rather than tracked:
after a post or an undo, sweep the grid the way a drag does
(slicesFromRegion, quietly) and keep the cells whose slice is still
selected. That also survives the column axis shifting, which it does on
almost every post -- a new segment column group moves every x by one.
- Bounded at 5,000 displayed rows. The sweep reads what the pivot shows,
not the grain, so at any ordinary depth it is a handful; fully
expanded it is the whole traversal and not worth a highlight.
- Past the bound, or on any failure, the highlight is cleared rather
than left in place: losing it says "I don't know where it went", which
is true, and leaving it says "it is here", which is not.
- A slice may now land on more cells than it did -- one that never named
the segment column matches the customer under the old segment and
under the adjustment's own. That is what the slice covers.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The preview was a 10rem box in the corner of a docked panel: enough to
see that there is JSON, not enough to read it. It opens as a modal with
the endpoint line and a copy button (with an execCommand fallback,
since navigator.clipboard is undefined on this app's plain-http origin).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A footer across the panel put Post directly below the ledger in the
bottom dock, since the ledger is the tall column -- so you could read a
figure, hit Post and never pass the tag. An untagged adjustment is
invisible to the bridge and ungrouped in the change log, so the layout
has to route you through that field rather than leave it beside the
work.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The summary printed back the cells you had just clicked in the grid --
count, total and filter, none of it news. It is a peek button now, and
the peek still carries the pivot filter and the duplicate-slice warning,
which are the parts that are not visible in the grid.
Post moves to a footer of its own, last in the flow: pick the operation,
read the ledger, name the change, post it. It sits on the same label
column as every other button, and sticks to the bottom of the dock --
a fixed-height dock with its own scrollbar would otherwise put the
primary action below the fold.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every button group now reads `label [ A | B ]` on one label column, so
nothing is staggered: change, apply, absorbs, target, per slice. The
strip and the ledger zone share the same left edge, so the alignment
holds across the two.
- Together/Each sits under the operation it qualifies rather than loose
in the middle of the strip, where it read as a peer of the operation
- The apply-mode explanation is gone; the detail is on each option's
tooltip. A sentence under a control is read once and skipped after,
and this one cost the strip its height on every render
- The plug, target, per-slice and clone hints are a few words each
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The panel said what it was doing only on the button that did it. The
operation tabs sat unlabelled in the middle column, the slice list held
a third of the dock to repeat cells you had just clicked, and the
ledger -- the thing being read and edited -- got whatever width was
left over.
- One strip across the top: operation, apply mode, slice summary, Post
- The slice list is a peek; the summary keeps the two facts not visible
elsewhere, the count and the pivot filter scoping the write
- The body is two grid tracks, ledger first, label second. Both used to
carry flex-1, so the ledger's table overflowed its shrunken box and
painted over the label column on a narrow window; the tables scroll
inside their own zone now
- "Apply Scale" is "Post". It renamed itself whenever the operation
changed, so the primary action never looked the same twice
- Target on: "Forecast" / "Total" rather than "Adjustable" / "Selected
total" -- what a rep is choosing is whether the number is the forecast
alone or the whole year including what has shipped
- The minor actions (clear, peek, unpin, request, collapse) were bare
buttons in the surrounding grey; they share one text-button style now,
and the segmented groups have rules between their segments
Also drops the bridge's "Whole version" scope.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nav. The source and version dropdowns sat in a status bar that is
otherwise read-only, so they did not read as the controls they were.
The forecasts are now listed in the sidebar above the three steps, each
row carrying its status and a star for the default. Not nested under
the Forecast button, which is where this started: Baseline works on the
same version, so hanging the list off one step would either
misrepresent the scope or duplicate it under two.
The source is gone from the nav entirely -- gs.osm_skinny means nothing
to someone editing a forecast. The sidebar lists every source's
versions and sets the source from the one picked, since a version
carries its source_id; `versions` stays scoped to the selected source,
because Baseline and Forecast are, so the sidebar gets its own list
rather than widening what versions means everywhere. The picker only
appears on Setup now, which is the one place the raw table name is the
right label.
The status bar keeps what follows FROM the selection -- the forecast's
name and its row count. The table it writes to moved into the hover
panel, still click-to-copy, since pasting it into psql is why it was
ever on screen.
Permissions. requireAdmin existed in lib/auth.js and was applied to
nothing, so all 26 non-admin accounts could call every Setup and
Baseline endpoint directly. It is now on source register/deregister,
col_meta writes, Generate SQL, dim refresh, version create/delete/
close/reopen, PUT /versions/:id, all of plans.js, and the baseline and
reference loads. Deliberately not on any read, nor on the forecast
operations, which carry their own owner and territory rules.
Both pages stay visible and go read-only, via one <fieldset disabled>
each rather than a flag threaded through forty-five controls, with a
banner saying why. The Tags panel on Baseline is excluded: its
permission is ownership, not admin, and a rep may rename the
initiatives they named themselves.
The table browser reads are open to everyone, because gating what a
page needs in order to render turned Setup into a 403 -- which it then
rendered as a crash, since the error body was passed to .map during
render and unmounting React blanks the app. Setup's list fetches now
coerce to an array, so an unexpected response costs an empty panel and
not the session. That fragility predated the gating.
Toolbar. The zone labels were the same visual weight as the buttons
they name, and the rules between groups were the same weight as the
zone borders, so nothing separated at the level it belonged to. Labels
are heavier and darker, group rules are stronger and taller, and the
forecast zone has a container of its own instead of floating.
Fit widths is removed, button and function. It measured the leaf header
over viewport rows only, so anything below the fold never counted; it
passed an option draw() does not have and raced draw()'s throttle,
leaving columns cleared but unmeasured at their floor widths; and the
persist that followed saved nothing, because saveColumnSizes returns
only overrides, which resetAutoSize had just emptied. Recoverable from
git if it is ever worth fixing rather than dropping.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
buildSteps keyed every untagged log entry by its own pf_logid, so a
version with two dozen routine untagged scale/recode passes drew two
dozen separate bars -- one per operation, none of them named. The
ledger in OperationPanel.jsx already collapses these into a single
"N untagged adjustments" line; Bridge now does the same, and groups
tagged entries case-insensitively too, carrying the most-used spelling
as the label, matching the ledger's own grouping exactly.
The old per-row "untagged"/"×N" captions are dropped where they'd now
just repeat what the collapsed label already says.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two corrections to the previous commit, both found from a real example:
a slice with pending_rep + pf_bucket, and a pivot scoped to sseas_e <= 2027.
The ledger and Bridge's ending point disagreed by a constant 1,495,062
across every step -- exactly the rows sseas_e <= 2027 excludes. Bridge's
"Selection" scope built filters from the slice alone and never picked up
the pivot's own view-level filter (what CLAUDE.md calls scope), the same
gap totalsFor in Forecast.jsx was written to close for the ledger. It's
now read off viewerRef.current.save() and applied alongside every
per-slice view.
Including pf_bucket in the per-slice filter (previous commit) was wrong
for Bridge specifically, unlike for the ledger: it fetched only the one
bucket the slice landed on, so "Compare to" had no other bucket's rows
left to compare against and always collapsed to one option. Which
bucket the walk starts and ends on is buildSteps's job, from
forecastBucket -- not something to pre-filter out of the fetch.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
BridgeView mounts once, up front, before anything has ever been
selected on the pivot -- so its scope defaulted to "Pivot's filters"
(effectively the whole version) regardless of a selection made
afterward. Scope now tracks the live selection until the user picks a
scope button themselves.
Even when scope was "Selection", the filter it built dropped
pf_segment/pf_bucket-keyed slice entries entirely and matched a blank
dimension value with `== null`, which this engine treats as a dropped
predicate rather than IS NULL -- both widen the bridged rows past what
was actually selected, the same failure mode the ledger's totalsFor in
Forecast.jsx was hardened against. Bridge's selection filter now
mirrors that logic.
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>
"Absorbed by" was rendered only while the edit was dollars-only, which made it
absent in two quite different states: before anything had been typed, and after
a measure had been pinned. Pinning includes a *click* -- clicking a cell pins
whatever it reads -- so an accidental click in the qty column had no visible
effect except that the control disappeared, and the way back was a small x in a
table header.
It now stays put and greys out, still showing which measure absorbs the change,
because the pinned inputs answer the same question the toggle does:
qty pinned -> price is what moves
price pinned -> qty is what moves
so the inert control reads as the truth rather than a stale choice. The hint
says which case it is in, and a pinned measure gets an "unpin" next to the
toggle rather than only the x in the header.
Nothing about what gets written changes: `plug` is still sent only when the edit
is dollars-only, which is still the only case where price and volume are both
unknown.
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>
A tag was only ever a value typed on a pf.log entry, so the only way to
change one was to find every entry carrying it in the change log and edit
each. Nothing showed what the list was, and the bridge groups on this
column -- so "Pull Forward" and "Pulled Forward" read as two initiatives
with no way to make them one.
PATCH /versions/:id/tags rewrites every entry carrying `from`. A `to` that
already exists merges the two, an empty one clears the tag; the panel
confirms both, since neither is visible as a diff afterwards.
Permission is the pf.log rule applied to every entry the tag is on rather
than most of them: a half-applied rename leaves the initiative split, which
is what the rename was for. GET /versions/:id/tags now returns owners and
can_edit so the panel can grey the row out instead of offering a click that
answers 403.
On the Baseline page, next to the other version-level settings -- the
Forecast page edits one entry's tag, this edits the column.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
App.jsx fell back to versions[0] when localStorage held no selection, and
the version list is ordered created_at DESC -- so a fresh browser landed on
whatever version was created last. That is a scratch scenario as readily as
the plan, and sales accounts, which never pick a version themselves, had no
way back to the one they were meant to read.
pf.version.is_default names the landing version, at most one per source by
partial unique index, the way pf.layout.is_default already works. Setting it
is admin-only and enforced in the route: it decides where everyone else
lands, so it follows the pf.log rule rather than being the version's own
setting like its name.
A stored selection still wins -- the default is the fallback, not an
override, so nobody building scenarios is thrown back to the plan on every
load.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The class fix rendered the `+` but the node still would not open, and the
caret did not light on hover. `tbody th:empty { pointer-events: none }`
makes the padding cells left of a tree label inert, and a label cell whose
group key is null or "" is `:empty` too — its caret is a `::before`, which
does not count as content — so the cell received no pointer events at all.
Exclude the tree classes from that rule. `row-hover.css` reads `:empty` the
same way in six border selectors; those are a hover tint, left alone.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`partgroup` is null on 93k rows of `gs.osm_skinny` and empty on another
111k, and the pivot showed those groups with no `+`: no way to drill into
them at all, while every named sibling opened.
The cause is upstream, in the datagrid's `cell_style_row_header`. A tree
row's header is the label cell padded on its left by one blank cell per
level above it, and it told padding from label by testing the cell's own
text — so a node whose group key is blank read as padding, got no
`psp-tree-label`, and therefore no caret. The click handler gates on the
same class, so the cell was not clickable either. The node was in the
traversal and its children existed; only the affordance was missing.
Tell them apart structurally instead: the label is the last defined entry
in `row_header`, which is how `is_collapse` two lines below already reads
the following row. Flat rollup has no padding to distinguish and keeps the
text test.
Rebuilt the vendored packages from fork branch `expand-blank-tree-nodes`,
which stacks this on the depth patch already carried. Note that
`npm install` on its own will not pick a rebuilt tarball up — the version
in the filename never changes and the lock pins an integrity hash, so npm
serves the old one from its cache and nothing reports a problem. The
README and the rebuild script now say to re-resolve by path.
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>
A slice as broad as a whole bucket reached every entry on the version, and
the walk stopped being a walk -- roughly 44 lines on the version this was
built against, where there are about a dozen things to say.
Three causes, three fixes.
Untagged adjustments had a line each, labelled "Scale #226" -- a row spent
to say nothing, 28 of them. They collapse to one line that counts them.
Tags grouped by exact text, so "Keystone reduction" and "Keystone
Reduction" reported as two initiatives, as did four spellings of moved to a
different sku. Grouping is case-insensitive now and the line shows whichever
spelling was used most. The tags themselves are untouched; wording variants
are still separate lines, and that is for whoever typed them.
What is left is capped: the loads stay whole, since they are the shape of
the forecast, and the adjustments keep the six largest with the rest rolled
into one line carrying its own subtotal. Still arithmetically the walk --
addition does not care about the order -- and the rollup expands.
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>
Clicking a held box pins it, and the only way out was to know that
emptying the field unpins it -- filled() is false on a blank either way.
Clicking into a greyed column to see what is in it and then wanting out
again is the ordinary case, not the awkward one.
An x on the column header clears that measure's edit, shown only while it
has one, and Escape in the box does the same and steps out. The panel's own
Escape handler already ignores events from inputs, so the two do not
collide.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
