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>
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>
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 server had no authentication: every /api route was open, CORS
allowed any origin, and the identity written to the audit log came from
the request body — the UI sent a hardcoded pf_user: 'admin', which any
client could have set to anything it liked.
Accounts live in pf.app_user with scrypt hashes from node's own crypto,
so there is no native build step and the parameters travel with each
hash. Sessions are express-session over connect-pg-simple in pf.session:
a restart no longer signs everyone out, and a session can be revoked by
deleting its row, which is how disable-user cuts off access immediately
rather than at cookie expiry.
Everything under /api except login/logout/me now requires a session, and
the React app is mounted only once there is one — its load effects call
the API on mount, so a logged-out mount would just fire a burst of 401s.
A session that expires while the app is open lands back on the login
screen: auth.jsx wraps fetch once rather than teaching every call site
to check.
Identity is now read from the session for pf_user, created_by and
closed_by, and the body values are ignored.
Hardened for an internet-facing deployment: trust proxy so req.ip and
secure-cookie detection are right behind TLS termination, httpOnly +
SameSite=Lax + Secure cookies, ten login failures per IP per fifteen
minutes, one error message for unknown, wrong and disabled alike, and a
fresh session id on success. CORS is off entirely unless CORS_ORIGIN
names an origin — a wildcard alongside a session cookie would be CSRF by
construction. The server refuses to boot without SESSION_SECRET rather
than falling back to a guessable default.
pf.sh grows add-user, passwd, list-users, disable-user and enable-user;
passwords are read on stdin and hashed before they reach psql, so no
plaintext in argv or shell history. install.sh generates the secret,
applies 02_auth.sql, and creates the first account.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Forecast operations could only act on one clicked row at a time, and the
panel that drove them separated the numbers you were reading from the
inputs that changed them. This reworks both, and adds initiative tags so
a version's history can be read as a bridge.
Operations
- Accept `slices` (array) alongside the legacy single `slice`, with
apply_mode 'prorate' (one pool) or 'each' (independent per slice).
- buildWhereAny() ORs the slices into one predicate. A union of slices
cannot be flattened into per-column IN lists without over-selecting,
and the result is parenthesised so the appended exclude clause does not
bind wrong.
- resolveIncrs() now resolves each measure independently: target, percent
or change amount per measure, so a target on value and a percent on
units can be submitted together. Replaces the single global `mode`.
- target_basis chooses what a target measures against: only the rows an
operation can write, or everything the pivot shows for the slice.
Excluded iters are visible in the grid but immovable, so a target set
against the visible total previously overshot by their contribution.
Two latent bugs surfaced by the above, both pre-existing:
- A slice naming no filterable column reduced to TRUE and applied the
operation to the entire version. Now rejected on all three operations.
- Prorating across a pool that nets to ~zero multiplies each row's share
by an exploding factor, sending rows to extreme opposite values to hit
the target. Refused when the net falls below 1% of gross.
Tags and the bridge
- pf.log gains a nullable `tag`, written by a follow-up UPDATE rather
than through the generated SQL: those templates are stored per source
in pf.sql, so a {{tag}} token would strand any source that had not
re-run "Generate SQL".
- Tag is editable after the fact in the change log, with completion from
tags already used on the source. PATCH branches on whether a field was
sent, so a tag can be cleared as well as set.
- BridgeView renders the walk from baseline to current as a waterfall,
one step per tag, scoped to the selection, the pivot's filters, or the
whole version. Computed from the loaded Perspective table so the
figures always reconcile with what is on screen; overlapping slices are
deduped by pf_id to match the OR semantics operations use.
- Colour is a polarity job, so it uses the validated diverging pair
(blue/red, CVD dE 21.6) with neutral anchors, not categorical hues.
Every bar is directly labelled and a table view is available.
Panel
- Extracted to OperationPanel; the scale form is one continuous ledger:
baseline, each adjustment, current, then New value / Change / % change
as three interchangeable editable rows. Typing in any one derives the
others, which removes the target/delta/percent mode toggle entirely.
- Dockable bottom, right, or floating (drag to move, grip to resize), and
closable via header, Esc, or the toolbar. Placement persists.
- Controls no longer stretch to the dock width, and text contrast now
clears WCAG AA against white throughout.
Also: the status bar names the physical table writes land in, with live
row counts; and the pivot's expand depth is re-applied when the tab
regains focus, since Perspective rebuilds its view on redraw and a
ROLLUP view with no depth set renders fully expanded.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W1TQiBYZbbWWkMNoCtUd8M
Replace Bootstrap fill icons with Feather-style stroke SVGs (sun with
rays + crescent moon) in StatusBar toggle.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
App.jsx owns sources/sourceId/versions/versionId and persists them
across reloads. StatusBar renders the dropdowns plus a status badge —
Source-only on Setup, Source · Version · status on Baseline/Forecast.
The duplicate in-view selector bars in Forecast and Baseline are gone;
Baseline keeps its version actions (New/Close/Reopen/Delete) inline.
Setup reports source-list mutations up via refreshSources so the bar
stays in sync after register/deregister.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- ui/: React + Vite + Tailwind app (Setup, Baseline, Forecast views, collapsible sidebar, status bar, canvas timeline)
- server.js: serve built UI from public/app/
- package.json: add build script (cd ui && npm run build)
- routes/sources.js: default new col_meta role to 'dimension' instead of 'ignore'
- .gitignore: exclude public/app/ build output
- pf_spec.md: update tech stack, nav, frontend section, and project status to reflect current implementation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
