INTERIM. T3.4 removes the duplicate token underneath this; the job here is only
the appearance, and no token consolidation is started.
The wizard filled its inputs with var(--bg) - which in this sheet is the PAGE
BACKGROUND, #f4f4f4 - on a #e0e0e0 border. An empty required field was
indistinguishable from a locked one, which is why people were not typing in
them. The cause is the one the review named: this sheet redeclares its own
tokens, so it never saw --cds-field: #ffffff, even though theme-light.css has
been supplying that to this page all along.
Fields now consume --cds-field, and take the same --border-strong the creator's
inputs already use, so a field looks like a field on both pages. No new value is
introduced - both tokens already existed.
That inverts a signal if left there, so it needed the other half: there was no
disabled rule at all on this page, meaning locked fields would have turned white
too. Disabled and readonly fields now take --cds-field-02, the theme's own
secondary field surface, matching .locked-field in the creator. Enabled #ffffff
against disabled #f4f4f4, verified by computed style rather than by eye.
The border is deliberately the same on both states. I first wrote
`border-color: var(--border)` on the disabled rule and could not demonstrate it
taking effect - the rule matches, is more specific than the base rule, and its
background applies, but the computed border stayed --border-strong. Rather than
ship a declaration whose effect I cannot show, it is gone: a consistent border
is what "consistent with inputs elsewhere" asks for, and the fill is what
carries the state.
Screenshot diff is limited to the wizard, but establishing that took a control
run. admin and users appeared to change too, until capturing twice with NO code
change showed they differ from themselves - the console pages render live
timestamps and are not byte-stable. login, launcher, sop, creator and field are.
Recorded in the baseline README so the next task with a "no layout change"
done-when does not chase it.
The F5 probe now also fails if enabled and disabled fields become identical,
which is the way this fix could silently go wrong.
f_items: F1-F5 FIXED, F6 untouched as wave 1 requires. browser_check 71/71.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Containing block first, as the task asks. The drawer is a body child with no
transformed ancestor, so its containing block was already the viewport - the
positioning context was never wrong. What was wrong was `top: 0` with
`height: 100vh`: the drawer started at the very top of the viewport, and the
creator's .header is sticky with z-index:100 against the drawer's 61. The
header won, so the drawer's own head - its title and its close button - was
roofed over and unreachable. It read as "off-screen" because the part you
needed was covered, not because the box had escaped the viewport.
That is why raising z-index would have been the wrong move: it does not remove
the collision, it just swaps which element is on top, and then the drawer
covers the header instead. The fix is to stop them occupying the same band.
The drawer now starts at var(--rail-top) and is that much shorter. --rail-top
is the header's measured height, set by wp-creation-app.js:1328 and already
used by .wp-nav for exactly this purpose, so "below the header" has one
definition on this page rather than two.
The iframe boundary is NOT implicated. position:fixed inside the embedded
creator resolves against the iframe's own viewport, which is self-consistent,
and the drawer behaves identically framed and unframed. T7.1 can dissolve the
boundary without revisiting this.
The probe was checking one width, one mode, and placement only. It now checks
390 and 1440, standalone and embedded, that the close button is genuinely
hit-testable via elementFromPoint rather than merely present, that the drawer
reopens after closing, and that opening it does not move the page's scroll
position. All pass.
One honest caveat, attributed rather than hidden. At 390px the drawer sits at
the right edge of a 485px layout viewport while the screen is 390px, so 95px of
it is off-screen. That is not the drawer: the creator forces its containing
block to 485px, and while chasing it I found BL-001's root cause -
wp-creation-app.js:1389 injects `body{--nav-w:288px}` with no media query,
which lands after wp-creation-styles.css:815's
`@media (max-width:860px){body{--nav-w:56px}}` and overrides it, so the page
reserves 288px of rail that is not there at any width. Every `right: 0` fixed
element on the page is displaced by it, not only this one.
Left unfixed on purpose - it is the creator's layout, T7.1 rebuilds it, and
CLAUDE.md is explicit about not fixing things noticed in passing. BL-001 now
carries the exact cause and the five rules that consume the token, so T7.1 does
not have to find it again. The probe reports it as an attributed note naming
BL-001, so nobody is sent to the wrong file.
browser_check 71/71. f_items: F1, F2, F3, F4 FIXED.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
.header-left and the injected chrome were in a dead tie. Both were
`flex: 1 1 auto` with `min-width: 0`, so both claimed the same run of the bar
and both were allowed to shrink to nothing. The chrome's content is wider, so
it won every time: .header-left computed to clientWidth 0 while its
flex-shrink:0 logo kept its 106px and overflowed underneath the project
switcher. With the real project name that meant "2667008" rendered on top of
the PRIME wordmark and the name itself clipped to "on EUV Cleanroom En...".
The bar now has an order of giving way rather than a tie:
.header-left flex: 0 1 auto, min-width: auto sizes to content, floors at
the logo plus the gap
.wp-chrome flex: 1 1 auto (unchanged) the only one that grows
.header-right flex: 0 0 auto keeps its buttons
min-width:auto restores the content-based floor the explicit `min-width: 0` had
removed. The inner title block keeps its own min-width:0, so the project name
still gives way first, through the ellipsis .header-subtitle already carries -
truncation policy stays B2's, and nothing here silently truncates.
Two things the review did not name were colliding on the same bar and are fixed
with it. .header-right was being squeezed below its buttons, so "Load Sample"
ran underneath "Feedback". And the header was a fixed 48px holding FOUR groups,
not two - the markup's two plus what wp-chrome.js and auth-guard.js inject - so
at 1024px the overflow had nowhere to go but on top of its neighbours, and
T1.2's user-menu wrap turned that into three rows spilling onto the tab row
below. min-height plus flex-wrap lets the bar grow instead.
Header height at 1440px with a normal project name is still exactly 48px, so
desk layout is unchanged; sop-1440 differs from the wave 0 baseline only
because T1.1 gave the switcher a name to show in place of "(unnamed)". With the
long name it grows to 62px at 1440 and 82px at 1024 - wrapping rather than
overlapping, which is the point.
The F3 probe was too narrow to have caught the right-hand collisions: it
compared the logo against the chrome and nothing else. It now checks every pair
of groups sharing the bar, plus anything spilling out of it, and still reports
FIXED at 390, 768, 1024 and 1440 with the long name.
Verified at all four widths with "Micron EUV Cleanroom Enable 2667008": no
overlapping pair, nothing spilling, logo fully visible.
browser_check 71/71. f_items: F1, F2, F3 FIXED.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
BL-001 updated: its 1440px half was resolved as a side effect of the F2 fix,
not by intent. Left open, scoped to the creator at 390px, so T7.1 still checks
it.
BL-003 added: user-menu links are 16px tap targets. T1.2 made them reachable;
it did not make them comfortable. Deferred to T2.2, which replaces the markup.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
INTERIM. T2.2 is the real fix: wave 2 replaces this markup with the existing
drawer. Nothing here is meant to survive that, so it is the smallest change
that makes every control reachable, not a redesign - no hamburger, no
responsive menu, no avatar dropdown.
The bar already wrapped at 720px, so the wrap rule was not the problem. The
problem was #wp-usermenu, built in auth-guard.js with an inline
white-space:nowrap on the container: "Root . Admin . Users . Language & time .
Password . Sign out" became one unbreakable 412px run inside a 374px bar. Being
inline and unclassed, no stylesheet media query could reach it. At 390px that
put "Sign out" at x382-432 - half of it past the edge, exactly as the review
described.
The container now wraps and each link carries nowrap instead, so "Language &
time" still breaks as a unit rather than mid-phrase. Bar scrollWidth at 390px
goes 424 -> 374, and "Sign out" moves onto its own row, fully visible.
The truncated search is the other half of F2. The control was always usable -
what was cut was the placeholder - so below 620px, the breakpoint wp-chrome.css
already uses for this element, it reads "Search..." instead of "Search work
packages, projects, SOPs...".
Verified at 390px on all 7 pages: no bar control crosses the viewport edge, and
"Sign out" is fully within it everywhere. At 1440px the screenshot diff against
the wave 0 baseline is byte-identical for login, launcher, SOP wizard and field
view. Three pages differ, all intended: admin and users because T1.1 gave their
bar a project to show, and the creator because this change removed its
horizontal overflow.
That last one is worth flagging: the same unbreakable menu run was the cause of
four of the five overflows recorded in wave 0, including BL-001, the creator
scrolling sideways at 1440px. Overflow at capture is now 1 of 14 shots rather
than 5 - only the creator at 390px remains, which is its own layout and is
T7.1's to resolve. BL-001 is updated rather than closed, so T7.1 still checks
it.
Tap targets in this menu are 16px tall. Not touched here - it is C1's, audited
in wave 9 - and logged as BL-003.
f_items F2 FIXED. browser_check 71/71.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Completing T1.1. My first verification primed localStorage before loading each
page, which made both sources of truth agree and hid two remaining cases. Re-run
with genuinely cold storage, the app bar still showed "(unnamed)" on the field
view and "Select a project" on the console pages.
Two causes, both the same F1 shape - a page holding a copy the shared store
does not have:
1. field.js could only write {id} at boot (it needs the id synchronously, for
the per-project storage namespace), then resolved the full record into a
local PROJECT variable, rendered "Project: Job A" from it, and never
published it. The store kept the stub, so the bar read "(unnamed)".
setActive now fills a nameless record in from the cached project list, or
from the API when the cache has not loaded yet, and re-checks the id before
applying a slow response so it cannot overwrite a project the user has since
switched to. That fixes every caller of this shape rather than the one that
was caught - work-package-suite-app.js and wp-creation-app.js write the same
stub. field.js also publishes the record it already fetched, so the common
path costs no extra request.
2. admin.html and users.html have no project-resolution logic of their own, so
nothing read ?project= and a deep link left the bar on whatever was last
stored. The bar is the one component every chromed page has, so it resolves
the parameter once in wp-chrome.js rather than being taught to five pages.
Verified with localStorage cleared before every navigation: a cold deep link
now shows the project on field, SOP wizard, launcher, admin and users, and the
stored record carries the name rather than a stub.
The creator remains the one page with no app bar - it loads no chrome because
it renders as the iframe child. T7.1.
browser_check 71/71. f_items F1 FIXED.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The hero, the picker and the create-user card showed the active project while
the app bar still read "Select a project". Three separate causes, all of them
the same shape - a reader with its own copy of the value.
1. Nothing told the bar. wp-chrome.js rendered projectLabel() once at build
time and refreshed it only when /api/projects came back, so selecting a
project updated the hero and left the bar behind. ProjectData.setActive now
notifies, and the bar subscribes through ProjectData.onActiveChange instead
of holding a copy. A plain array of callbacks - this is one value with a
handful of readers, not a reason for a state library.
2. admin.html and users.html load wp-chrome.js but never loaded
project-data.js, so window.ProjectData was undefined and their bar could
NEVER show a project - it read "Select a project" permanently, whatever was
selected. Both now load it, ahead of wp-chrome.js.
3. setActive({id}) erased the name. field.js, wp-creation-app.js and
work-package-suite-app.js all set the id first and the full record second;
writing that stub verbatim left the bar rendering "(unnamed)". setActive now
merges onto the stored record when the id matches, so a partial write cannot
lose fields it did not mean to touch.
Also: index.html never honoured ?project=<id>, though every other page does, so
a deep link on a browser with nothing stored showed "Select a project" while
the URL said otherwise. It now resolves the parameter before reconciling.
setActive is the only code path that writes wp_active_project /
wp_active_project_obj - project-data.js:83-105, noted there in a comment so it
stays that way. A storage listener keeps a second tab from showing a project
the user has since switched away from.
Verified, all at 1440px and against the wave 0 baseline:
- bar shows the project on launcher, SOP wizard, admin, field, users
- survives a hard refresh on each of them
- selecting a project updates hero and bar in one interaction, no reload
- with nothing selected the bar reads "Select a project" and both the
launcher picker and the bar's own switcher are reachable
- deep link ?project= works on a cold browser, hero and bar agree
- setActive({id}) after a full record keeps the name
The creator is the one page with no app bar to fix: it loads neither
wp-chrome.js nor wp-chrome.css, because it renders as the iframe child of the
SOP wizard. Giving it chrome is T7.1's work once B7 dissolves that boundary -
adding it here would put a second app bar inside the embedded view. This is the
"all 6 pages" wording in the plan meeting the 7 pages that exist; see file-map
D1.
tests/f_items.py F1 now reports FIXED. F2-F6 still reproduce, untouched.
browser_check.py 71/71.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Runs the app from a clean database, captures the before images, and records
which of F1-F6 actually still reproduce. All six do.
Rather than eyeball screenshots, each defect is measured in a browser by
tests/f_items.py, which reports REPRODUCES / FIXED / INCONCLUSIVE and never a
silent pass. That makes it both the wave 0 record and the wave 1-3 regression
check: an item is done when its probe flips to FIXED.
F1 hero says "Job A", app bar still says "Select a project", no reload
F2 "Sign out" spans x382-432 in a 390px viewport - cut in half, 3 rows
F3 chrome paints over the logo by 106x32px; .header-left collapses to 0
F4 comments drawer overlaps the header by 380x91px in the standalone creator
F5 5 of 5 ENABLED wizard inputs compute #f4f4f4 on #e0e0e0
F6 11 cards in one 5,017px scroll, 0 tabs (review said ~4,700px; it grew)
Three probes needed care to avoid reporting a false pass, and the traps are
worth knowing before anyone verifies a fix:
F1 disappears if localStorage is primed first, because then both sources of
truth agree. The probe clears it and drives the real picker.
F3 needs a long project name that is long IN THE DATABASE - any page reached
with ?project= re-pulls it and overwrites a locally-faked one. It also cannot
be measured by comparing .header-left to the chrome: under the long name
.header-left (flex:1, min-width:0) collapses to clientWidth 0, so that
comparison reports a tidy zero gap while the chrome paints across the logo.
It measures against .logo, which is flex-shrink:0. My first two attempts at
this probe both reported FIXED for those reasons; the screenshot did not.
F5 must ignore genuinely disabled inputs or a fix looks done while real
fields stay grey.
14 screenshots, not the 12 the plan asks for, because there are 7 pages
(file-map D1). Capture also measures horizontal overflow, which is how BL-001
was found.
Tooling: cdp.py gains viewport() and screenshot() - it could do neither, and
T0.2 requires 390px and 1440px images. 390px sets the mobile flag rather than
just narrowing the window, since every page declares width=device-width and
Chrome otherwise lays out at 980px and no media query under test fires. Both
new scripts reuse browser_check.py's seed() and start_server() instead of
growing a second fixture. Existing browser_check still passes 71/71.
No application code changed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Wave 0 exists because the plan's line numbers came from a review of
users/directory-super-user rather than a fresh read. This is the fresh read:
7 pages, 6 stylesheets, 11,867 lines, with each page's stylesheets, scripts and
iframe role recorded, and all seven baseline counts captured with the command
that produced them.
Four discrepancies, one of which matters a great deal:
D2 - CLAUDE.md's "logged-override path for predecessors stays (A1). See
wp-creation-app.js:1962-1972" cites the wrong function. That range is
dashIssue(), which REFUSES to issue and says "open the package to release it
early with a logged reason". The reviewer read that sentence and correctly
inferred an override exists, but cited the mention rather than the code. The
audited path is confirmEarlyRelease() at 967-984 plus seven satellites (state
at 392, call sites at 998 and 1149, persisted at 1117, rendered at 1215,
rehydrated at 1674, reset at 481/488/1744). A T7.3 that preserved only
1962-1972 would delete the business rule while believing it had protected it.
D1 - "6 pages, 4 stylesheets" is 7 and 6; wave-0's own parenthetical lists
seven names. Every "all 6 pages" done-when is off by one.
D3 - four documents the plan reads from are deliverables not yet written.
D4 - the creator overflows horizontally at 1440px, which no F item covers.
Logged as BL-001 rather than fixed, since T7.1 rebuilds that layout anyway.
BL-002 records that outline:none appears three times in the wizard sheet, not
once, so T3.4 fixes all three.
Counts confirmed against the review: 79 dialogs (43 in the creator), 12 div and
2 span onclick, 15 help-tip badges, 0 aria-live, 0 pushState. The "4
declarations of #0f62fe" needed a definition - there are 31 occurrences and 14
custom-property declarations; the 4 is the number of stylesheets declaring
their own accent token, which is the number wave 9 should drive to 1.
No application code changed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The plan was delivered as wp-suite-implementation-spec.zip and lived only in
Downloads, so every "read CLAUDE.md first" instruction in it pointed at a file
the repo did not have. Bring it in unchanged: CLAUDE.md, IMPLEMENTATION.md, and
docs/waves/wave-0 through wave-9 plus backlog.md.
UX-REVIEW-2026-08-14.md is committed alongside it. It is the review that
produced F1-F6, S1-S13 and the A/B/C assessments, and item IDs throughout the
wave files cite it, so it belongs under version control rather than sitting
untracked in the working tree.
No application code changes here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
server/smoketest.py proves the API works; nothing proved the PAGES work. That gap
is why users.js, wp-sidenav.js and the extracted console.css shipped unexecuted and
had to be written up as a known issue instead of verified. This closes the gap with
a tool rather than a one-off, so the next front-end change is cheap to check.
tests/cdp.py a minimal DevTools Protocol client — hand-rolled stdlib
WebSocket (handshake, masked frames), browser discovery for
Edge/Chrome across platforms, and process teardown.
tests/browser_check.py the fixture and 71 assertions.
Stdlib only, matching smoketest.py's rule: these have to run on a plain Python
install on whatever machine is to hand. No pip, no Selenium, no node.
Self-contained — it builds a throwaway database, seeds a fixture, starts its own
uvicorn on a free port, drives the browser, and tears everything down. The real
database is never touched. Sessions come from minting a token with the app's own
auth.create_token() rather than scripting the login form.
What it asserts, beyond "no JavaScript errors on boot" (the thing that actually
went unverified): the three role-dependent renderings of the directory, one-line
rows and no sideways scroll, the roles each caller may grant, the project-access
dialog opening and closing, the drawer's open/Escape/scrim/focus/aria behaviour and
its role gating, ?project= carried only onto project-scoped links, and — the reason
this matters most — that admin.html still has its tokens, cards, headings and dense
sticky tables after console.css was lifted out of its inline <style>.
Three things the build had to get right, each learned the hard way:
- Teardown kills the browser's whole process tree AND sweeps anything still
holding the unique temp profile, matched on that path so a browser window the
user has open is never touched. proc.kill() alone left 98 strays.
- Launching retries with a fresh profile and port: a browser can hand off to
another instance and exit rc=0 without ever binding the debugging port.
- Cleanup waits for the server to exit and disposes the harness's own SQLAlchemy
engine before removing the temp directory, or the open SQLite file blocks the
delete and ignore_errors hides it.
The fixture includes an account on a project the super user cannot see, without
which the admin and the super user would see the same number of rows and the
scoping assertion would prove nothing.
Documented in DEPLOYMENT.md next to the smoke test. 71/71 across repeated runs,
leaving no stray processes or temp directories.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Deletes known issue 3. users.js, wp-sidenav.js and the extracted console.css had
never been executed, because there is no node/deno on the machine they were written
on. Edge is, so the pass was driven through the DevTools Protocol with a hand-rolled
stdlib WebSocket client, signing in by minting a session with the app's own
auth.create_token() rather than scripting the login form.
70 checks, twice, all passing — covering the five steps that entry listed:
1. users.html as an admin: 9 columns, one-line rows, no sideways scroll, all four
grantable roles, the project-access dialog opening and closing on Escape, and
your own permissions cell locked to a tag while your job function stays editable.
2. As a Project Super User: banner naming the project, only in-scope accounts
listed, out-of-scope rows read-only with the reason on hover, and exactly the
two roles they may grant.
3. As an ordinary project user: 6 columns, no create form, zero controls, emails
still reachable as mailto links.
4. field.html: drawer opens, closes on Escape and on the scrim, aria-expanded and
aria-current correct, focus moves inside, 44px tap targets, Admin Console hidden
from non-admins, and ?project= carried onto project-scoped links only.
5. admin.html: console.css loaded, --ctl resolving, cards and headings and sticky
dense tables intact after the extraction, user administration gone and replaced
by a link, and the admins-only gate still holding for a non-admin.
Every page boots with no JavaScript errors, which was the actual unknown.
Two things the pass surfaced, neither a defect: a 404 on /api/sops/latest is the
API's designed answer for a project with no SOP ("No SOP found") and the browser
logs every 4xx, so the fixture now seeds one; and role pills only appear where a row
is rendered read-only, since an editable row shows a dropdown instead.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Closes known issue 3. server/smoketest.py predated the login portal and had no
login step at all, so auth_gate refused every route after /api/health and the
documented way to verify a deploy reported a wall of failures against a healthy
stack.
- Signs in first, holding the session in an http.cookiejar on a shared opener.
urlopen() has no cookie support, which is why the session was dropped.
- Credentials from WP_SMOKE_USER / WP_SMOKE_PASSWORD, or --user/--password, so
a password need not land in shell history. Refuses to start without them
rather than running headlong into 401s.
- Checks the signed-in role up front and warns when it cannot archive or delete
a project, instead of failing six checks later for an unexplained reason.
- New exit code 2 for "could not run" (unreachable, or credentials missing or
rejected), kept distinct from 1 "ran and found problems".
- Also asserts the session is accepted on an authenticated route and refused
after sign-out; signs out at the end so a run on a shared host leaves none.
The working smoke test immediately caught a real bug: SQLite ships with foreign
keys disabled and the pragma is per-connection, so every ondelete="CASCADE" was
silently a no-op on dev while working on Postgres. Deleting a project orphaned its
SOPs, work packages and membership rows; deleting a user orphaned theirs. db.py
now sets PRAGMA foreign_keys=ON for SQLite, so dev matches production.
Enforcing them exposed two things that had been getting away with it:
- create_user adds an account and its ProjectMember rows in one flush, and the
ORM takes flush order from relationship() declarations. models.py has none by
design, so it emitted the child INSERT first and the database rejected it.
Fixed with a db.flush() after the account, and documented at the top of
models.py so the next same-flush pair does not rediscover it. The other three
call sites already commit the parent first.
- A write aimed at a since-deleted project used to leave an orphan row; with FKs
enforced it would have been an IntegrityError surfacing as a 500, which the
browser outbox retries forever (it only retires 4xx). require_project_writable
now refuses a vanished project with 409, like the archived case beside it.
Verified: smoke test 27/27 exit 0 against a live server (the cascade assertion now
passes on SQLite, which is what used to fail); credentials missing and credentials
rejected both abort cleanly with exit 2 and no stray PASS lines; a project_user run
warns up front and fails as described. Scope tests 93/93, live HTTP checks 29/29,
static JS checks 33/33. No orphan rows left in the database afterwards.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two things surfaced while building the User Directory that are worth a decision
rather than a mention in a handover.
3. server/smoketest.py has no login step, so auth_gate 401s every check after
/api/health. DEPLOYMENT.md presents it as the way to prove the stack works
end-to-end, including a docker compose exec invocation, so the documented
verification path reports failure on a healthy system -- the failure mode most
likely to be believed. Rated Medium for that reason. Predates the login
portal; confirmed unrelated to this branch by stashing it and re-running. The
Admin Console's in-browser smoke test is the working equivalent today.
4. users.js and wp-sidenav.js have never been executed -- no JS engine on the
machine they were written on. Logged as a verification gap, not a defect, with
what WAS checked (server tests, delimiter balance, handler resolution, id
targets) and what only a browser can settle (layout, transitions, focus trap).
Includes the five-step manual pass that closes it, and the hard-reload note,
since sw.js bumped to wp-suite-shell-v6 and a soft reload serves the old
shell.
Both entries follow the file's existing shape: what is wrong, what it costs, why
it is still open, what closing it takes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
User accounts lived in the Admin Console, which is admins-only. Project admins
need to create the accounts on their own jobs without an app admin on the phone,
so accounts move to a new User Directory page and a new role carries the right.
server/auth.py, server/app.py
New permissions role `project_super_user`, between admin and project_admin:
everything a project admin may do, plus user administration SCOPED to the
projects they hold the role on. Four limits make it safe to hand out, all
enforced server-side:
* Scope comes from projects, not the job title. It resolves per membership
(managed_project_ids), so an ordinary account can hold it on one job via
ProjectMember.role, and a super user demoted on one job administers
nobody there. No projects, no authority.
* Account-level changes (password, disable, rename, permissions, delete)
require EXCLUSIVE scope: refused when the target is also on a project the
caller does not administer, because those changes are global. The
directory renders such rows read-only with the reason.
* No admin or super-user targets, and neither role can be granted by a
super user -- that is the line that stops it becoming app-wide control.
* PUT .../projects rebuilds only the caller's own slice; memberships on
projects they do not administer are left untouched. A payload that simply
omits them must not cut someone off a job the caller cannot see.
Creating requires naming at least one of your own projects: an account with
none would be one the creator instantly cannot manage.
/api/auth/users is now scoped rather than admin-only, and carries a per-row
`manageable` verdict plus the reason. Non-managers get a contact card only --
a project user has no business reading colleagues' login history. New
/api/auth/user-scope tells the page what it may offer. Administrative
password resets are now audited; they were the one account change that left
no trace. Settings, feature flags and the auto-add rule stay admin-only.
While here: one definition of "is a user manager", derived from the managed
set. An account-role-only version disagreed with the scoped one and locked
per-project super users out of routes they were entitled to.
html/users.html, html/users.js
The directory: three renderings from one page -- admin (everything), super
user (controls per row, read-only where scope is shared), everyone else (a
read-only directory of the people on their own projects).
html/console.css, html/console-util.js
Extracted from admin.html/admin.js so both console pages share them. A
divergent jsq() is an XSS and a divergent role list offers permissions the
server refuses, so neither may exist twice.
html/wp-sidenav.{js,css}
Global nav drawer, role-gated, carrying ?project= across links. Mounted on
the field view (which had no way to anywhere) plus both console pages.
No migration: users.role is already String(20) and the new value fits.
Verified: 93 scope/gate tests, 29 live HTTP tests through the real dependency
stack, 33 static JS checks. Not verified in a browser -- no JS engine on this
machine -- so users.html and field.html want one manual load.
server/smoketest.py still fails with 401s. Pre-existing: it has no login code,
so auth_gate refuses it. Confirmed unchanged by stashing this work.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Brings in the 2026-08-05 work plus the deploy runbook and KNOWN-ISSUES.md.
Carries migration a7c31f9e5b02 (additive, with server defaults). No overlap with
the entrypoint/backup-script changes already on main.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
It is a real hole and we are shipping without fixing it, so it needs to be written
down somewhere that outlives the conversation it came up in.
Discipline names are rendered into inline handlers in the WP creator escaped with
esc(), which maps ' to '. That is right for text and wrong here: the browser
decodes entities in an attribute before the JS parser sees it, so the entity
becomes a bare quote and closes the handler's string literal. Escaping for a
handler argument has to go backslash, then quote, then HTML — esc() only does the
last part. Same bug, same ordering, as the two fixed on 2026-08-05 (jsq() in
admin.js, escHandlerArg() in work-package-suite-app.js); this one predates that
work and sits in a file it did not touch.
Left open rather than fixed because the suite is internal, behind a login, with
named employee accounts and no anonymous input path — the likely cost is a
discipline named "Owner's Equipment" silently breaking its own pill, not an attack.
The entry records the conditions that change that judgement (exposure outside the
corporate network, accounts for subcontractors or clients, self-registration), so
the rating cannot go quietly stale if the deployment story changes. Neither CSP nor
the CSRF gate mitigates it, and both are noted so nobody re-derives that hopefully.
Also records the archived-project rough edge from the same day: the server refuses
writes with 409, but the two big apps still present Save and Issue buttons, so the
failure is safe but late. data-wp-archived is already on the document element for
whoever closes it.
Each entry says what closing it takes, and entries get deleted in the commit that
fixes them — otherwise this file becomes a museum instead of a queue.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Three things asked for together, plus the migration they share (a7c31f9e5b02 —
additive, with database defaults for existing rows, so unlike the users.role
rewrite it is safe under a code-only rollback).
ARCHIVE A PROJECT. A finished job leaves every picker, switcher and search, and
freezes read-only, without losing anything. Hiding is free: GET /api/projects
defaults to archived=exclude, so the home picker and the app-bar switcher drop it
without either of them changing. Freezing is require_project_writable(), which
every write that lands on a project now goes through — SOP and WP upserts (both
ends, so a package can be moved neither into nor out of an archived job), deletes,
issue, status, WP archive, and comments on its WPs/SOPs. It answers 409, not 403:
nobody lacks a permission, the project's state is the objection, and the browser
outbox in project-data.js retires 4xx ops instead of retrying them against a job
that will never accept them. Unarchive and delete stay allowed on purpose —
unarchive is the one write an archived project must take, and archive-then-delete
is a normal sequence.
DEFAULT MEMBERS ON NEW PROJECTS. users.auto_add_projects / auto_add_role flag the
people who belong on every job, so an admin says it once instead of remembering it
at each project creation. It runs on the is_new branch of upsert_project, which is
the single road into project creation, so the home page, the sample project and the
demo seeder are all covered and an update never re-runs it. Note the interaction
with the existing creator-grant: that row commits first and add_default_members
never overwrites an existing membership, so the creator grant now carries the
creator's own auto_add_role — otherwise someone flagged "Project Admin on every
job" would land as a plain member on the one job they started themselves.
ADMIN CONSOLE. The user table had outgrown .wrap{max-width:860px}: nine columns in
an 860px card meant every cell wrapped, so one user occupied a ~100px band, the
action buttons stacked, and the table spilled outside its own white card. Now
1240px, with wide tables scrolling inside .tscroll so the page itself never scrolls
sideways, and one spacing/control scale across all twelve cards. Truncation hangs
off a span inside the cell rather than max-width on the td, which table-layout:auto
treats as advisory — the usual reason cell ellipsis works in the stylesheet and not
on the page.
Found in review and fixed here rather than later:
- Stored XSS in the new Projects card, reachable by any signed-in user, landing in
an admin's session. The uesc(v).replace(/'/g,"\'") idiom this file already used
in eight places escapes in the wrong order — uesc leaves backslashes alone, so a
stored name containing \' closes the JS string literal and the rest executes.
jsq() does backslash, then quote, then HTML, and all thirteen handler bindings go
through it. The same bug, unescaped entirely, was in the SOP builder's custom
constraint names (escHandlerArg there). Three of seven test payloads escaped the
literal under the old idiom — one of them a plain name ending in a backslash, so
it was breaking buttons for innocent input too.
- _save_comment resolved wp_id and sop_id with if/elif but stored both, so a
payload naming a WP you may touch and a SOP you may not was authorised on the WP
alone and still wrote into the other project's thread. Both are checked now.
- Promoting an account to admin left its default-member flag set but invisible,
ready to take effect again on demotion — cleared, as set_user_auto_add already
does for the role.
smoketest.py and the console's own smoke test both assert the archive round trip:
out of the default list, present with archived=all, writes refused with 409, and
all of it undone by unarchiving.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- scripts/entrypoint.sh (new): prefers the live bind-mounted backup-cron.sh, but falls back to a copy baked into the image at build time if the mount is missing. If neither exists, it stays up and idle (instead of crash-looping) so the container remains reachable via console/exec for diagnosis.
- scripts/backup-cron.sh (updated): resolves db-backup.sh the same live-or-fallback way, re-checked on every loop iteration, so if the bind mount comes back healthy later, this container picks up the live scripts on its next backup run with no restart needed.
- scripts/backup.Dockerfile (updated): bakes all three scripts into the image under /app/scripts-default/ as the fallback, and sets the new wrapper as ENTRYPOINT.
A step-by-step deploy procedure for someone who administers the Docker host
but does not know this app. Two things about this deploy need spelling out for
them, and neither is obvious from DEPLOYMENT.md:
- nginx's config and all of html/ are baked into the image, so the stack has to
be re-pulled and re-built. A restart deploys nothing and looks like a success.
- the pending users.role rewrite (b41c7ae9) is one-way as far as the app is
concerned: rolling the API image back after it commits breaks logins, because
the old code doesn't recognise 'project_user'. So the runbook records
`alembic current` and both image IDs up front, and splits rollback by symptom
— an nginx-only failure is a safe code-only rollback they can do alone, a
failed migration is escalate-don't-improvise.
Backups go through the existing sidecar rather than an ad-hoc pg_dump: it works
from Portainer's console without SSH, writes an encrypted timestamped dump to
backups/ on the host, and prints a success line worth checking. Commands use
`docker exec <name>` throughout, since `docker compose` from an SSH session
can't find a Portainer-managed stack's compose project.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Cache-Control rule I added in the previous commit used a nested
`location ~* \.(html|css|js|webmanifest)$`. nginx does NOT inherit add_header into a
block that declares its own add_header, so every HTML, CSS and JS response would have
been served WITHOUT the CSP, HSTS, X-Frame-Options, Referrer-Policy and nosniff headers
from the Phase S hardening — the headers dropped for exactly the files that matter most,
and silently, since the pages would still work.
Now computed by `map $uri $wp_cache_control` at http level and applied with one
server-level add_header alongside the security headers, so nothing is scoped away. An
empty value makes nginx omit the header entirely, so images and fonts stay cacheable.
Applied to both the Docker config (nginx/conf.d/wp-suite.conf) and the bare-metal one
(nginx-wp-suite.conf), which carries the same header set.
Caught while checking whether the stack was safe to redeploy. Not verified with
`nginx -t` — this machine has neither nginx nor docker — so DEPLOYMENT.md now records
the rule and the one-line curl that confirms both headers are present after a deploy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A 55-agent audit of the last few commits confirmed 32 findings. The high and medium
ones are fixed here; the ranked leftovers are listed at the end.
Boot-order crash (my regression, wave 2)
- wp-format.js loaded AFTER wp-creation-app.js on every page, but the creator boots
synchronously at parse time and its comment renderer calls wpFormatDateTime(). With
any review comment present that threw a ReferenceError and aborted the rest of boot.
The formatter now parses before the app scripts on all five pages. Verified with a
comment seeded: the date renders and boot completes.
The network-first fix didn't actually work
- `fetch(req)` inherits the request's default cache mode, so it consults the browser
HTTP cache — the previous commit's "network-first" still allowed a page to run
against a stale sibling. Code is now fetched with cache:'no-cache' and precached
with cache:'reload'.
- Nothing pinned freshness on the wire either: no Cache-Control anywhere, so browsers
applied heuristic caching (~10% of a file's age) and each file expired at a
different moment. NGINX and the dev server now send no-cache for html/css/js/
webmanifest; images stay cacheable. Verified on the wire.
- Non-ok responses were returned verbatim, so a 502 broke pages the cache could have
served; they now fall back to the cache. Cache keys drop the query string, which
fixes both the offline miss on every in-app link (?project=…&tab=…) and unbounded
cache growth. respondWith can no longer resolve to undefined. Cache bumped to v5.
Embedded creator
- Dropped the &t=Date.now() cache-buster and made the frame's identity the PROJECT.
The view and which package to open are now applied by calling into the loaded
document, so switching tabs no longer reloads it — that reload discarded unsaved form
edits, made the creator unreachable offline, and stored a fresh copy per click.
- ?view=dashboard was re-read on every tab switch, so after one deep link the
"Work Package Creation" tab kept opening the Dashboard for the rest of the session.
Deep-link params are consumed once now.
- ?wp=<id> — which the global search has been emitting since wave 2 — was read by
nothing, so picking a work package in search opened a blank one. The creator now
exposes openWpById() and the shell applies it after a new 'wp-creator-ready' event,
because the frame's load fires before pullProject() resolves.
- Math.max(320,…) could make the frame taller than the space available while page
scrolling was disabled, pushing content off a window that couldn't scroll. Full-bleed
is now only used when at least 460px remains, and the SOP-incomplete gate never runs
inside it. A ResizeObserver re-measures when wp-chrome.js grows the app bar.
Contract drift
- .field-hint and .user-pick are used on the SOP suite page but their only rules lived
in wp-creation-styles.css, which that page doesn't link — the CM hint and the
sign-off pickers had no styling at all. Rules added to the suite's stylesheet.
- The creator's critical floor now also hides modal overlays (a stale stylesheet
rendered their contents inline in the form) and gives the jump bar a sane sticky top.
- login.js dereferenced ids unguarded where the old version guarded, so a cached older
login.html would break sign-in itself. Guarded.
- The "Language & time" menu item was added only if wp-format.js had already parsed;
the check now happens at click time.
Verified: 157 API checks across five suites on a clean database, plus 22 driven UI
checks — boot-with-comment, tab switching with a no-reload probe, short-viewport
fallback, and the search deep link landing on the right package.
Not done, ranked: ~50 dead CSS rules across three stylesheets; dead .team-pick and
.constraint-option contracts; wp-chrome.js's documented '.header' mount branch is
unreachable because the creator loads neither wp-chrome.js nor its CSS; the squeeze
half of the embed layout (.content-area.embed-full) is still CSS-only, which degrades
to the old narrow column rather than breaking; fingerprinted asset URLs would make a
mismatched pair unrepresentable rather than merely unlikely.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The auto-hiding drawer was the wrong model — a list you navigate by shouldn't appear
and disappear under the pointer, and its vertical text tab read as a stray artifact.
Replaced with a persistent side panel following the Planner reference:
- Collapse toggle at the top (the panel glyph, arrow flips), remembered across visits.
Collapsed leaves a 56px icon rail where the coloured package badges are still
clickable, rather than hiding the list entirely.
- One primary action: "+ New work package" with a split caret for Duplicate, Split by
discipline and Export all.
- Icon nav with counts: My packages (owned by you), All packages, Needs attention
(on hold or not release-ready), Dashboard. These filter the list below.
- Packages as rows with a colour-coded initial badge, number, subject and readiness
state, still grouped by status, with a left accent bar on the current package.
The badge colour is hashed from the WP number, so a package keeps its swatch
instead of shuffling when another is added or deleted.
- The panel sits IN the layout: the form and the full-width chrome shift beside it
rather than being overlaid.
Also, the reason it appeared as loose unstyled widgets in the middle of the form: the
panel's markup and its stylesheet are cached independently, so a browser can run new
markup against old CSS. Its essential layout (fixed position, width, the row/badge
flex, the collapsed rules) is now injected by wp-creation-app.js as a floor, inserted
first in <head> so the stylesheet still wins on everything it defines. Same lesson as
the iframe: a component whose CSS-missing state is "broken" rather than "plain" must
carry its own critical layout.
Verified with 25 driven checks in headless Chrome: persistence, the four nav links,
badge colours and text, view filtering, collapse/expand, the split menu, row selection
and highlighting — and, with wp-creation-styles.css removed from the page entirely, the
panel is still a fixed 288px side panel with the form shifted beside it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Creator rendered as a tiny double-scrolling square in the WP tab. My fault, and
the mechanism matters more than the symptom:
I had moved the iframe's sizing (width:100%, border:0, min-height) out of its inline
style attribute and into work-package-suite-styles.css. The service worker cached the
HTML and the stylesheet as INDEPENDENT entries, cache-first — so a browser could hold
the new HTML together with the old CSS. With the inline sizing gone and the new rule
absent, the iframe fell back to the HTML default 300x150 box and the whole tool
collapsed. Moving self-contained markup into a separately-cached file created that
window; nothing about the layout itself was wrong.
Three layers so it cannot recur:
- The iframe's width/border/min-height are inline again, on purpose, with a comment
saying why. An iframe with no intrinsic size has a catastrophic failure mode, so its
sizing must not depend on another file being in step.
- applyEmbedLayout() now sets the fill height and width as INLINE styles via
sizeWPFrame(). Inline beats any stylesheet, including a stale cached one, so the
class is a refinement rather than a requirement.
- sw.js: HTML/CSS/JS are now fetched NETWORK-FIRST with the cache as offline fallback;
images/icons/manifest stay stale-while-revalidate. These files reference each other,
so a page must never run against a stale sibling — this same staleness had already
masked two other fixes during development. Cache bumped to v4.
Verified: at 2560x1440 the tool spans the window with a single scrollbar; with
work-package-suite-styles.css removed entirely (strictly worse than stale) the frame
still measures 1469x662 instead of 300x150, and re-running the layout pass keeps it
there; 12 checks across sop -> wp -> dashboard -> sop confirm body.embed-full, the
content-area class, the fill class and the inline height are all cleared on the way
out, so the wizard never ends up unscrollable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The field list judged readiness from open constraints alone, so a package whose
predecessor isn't Closed showed a green Ready pill even though the server would
refuse to issue it. It now shows "waits on N", matching the form, the dashboard and
the navigator drawer. A deleted predecessor still doesn't block.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Layout — the reported "skinny scrolling windows"
- .content-area capped the whole suite at 1000px, so on a 1920 screen the embedded
Work Package Creator ran in a ~930px column with its own scrollbar inside the
page's. The wizard now caps at 1700px and the Creator/Dashboard tab goes
full-bleed: the iframe fills the window below the app chrome and owns the only
scrollbar. Needed `flex: none` on the content area — as a `flex: 1` item its
flex-basis overrode `height`, leaving the used height indefinite so the child's
`height: 100%` collapsed the iframe to its 150px default.
- The SOP wizard's fields were one per row; they now flow into ~340px columns.
Navigator — now an auto-hiding drawer
- It was a fixed 262px column that stole width from the form AND was hidden below
1100px, so embedded (the normal path) it never appeared at all — that's the
"broken side menu". It's now an overlay drawer behind a slim always-visible edge
handle: hover or tap to open, move away / Escape / pick a package to close, or pin
it to keep it open (pinned shifts the form and the page chrome across, and is
remembered). A gutter keeps the handle off the section-nav chips.
Bugs found while checking the site over
- collectStepData() still read the SOP team fields as text inputs, but wave 1 made
them account pickers — so it wrote a user ID into state.team.pm where the display
NAME belongs, and the SOP would print `user_ab12…` as the PM. Now synced properly
from the pickers.
- loadSampleData() set .value on those selects with fictional names; setting an
unmatched value on a <select> silently does nothing, so the sample lost its team.
It now stores them as names without an account, which the picker shows as
"(no account)".
- My earlier CSS block replacement had deleted the SOP-chip, people-picker and
critical-tag styles. Restored.
Same picker everywhere the SOP names someone
- Sign-off roles (step 3, required and optional) are account pickers now, storing
userId alongside the name, so a signature belongs to an account that can be
notified. Titles stay free text.
Per-project permissions (asked for: "change project permissions for individual users")
- project_members.role overrides the account's role on that project, so a PM on one
job can be a Project User on another. Empty = inherit; app admin is admin
everywhere. effective_role() feeds require_project_admin, so WP delete, completed-
SOP edits and project delete are all judged per project.
- Project access is now its own column in the admin console (it was buried among the
action buttons, which is why it couldn't be found), showing the project count per
account; the dialog sets access plus the role on each project.
- The members endpoint reports each person's effective role on that project.
Verified: 157 API checks across five suites on clean databases (44 permissions +
22 password reset + 34 search/localization + 39 gates/notifications + 18 new
per-project permission checks), 16 drawer-behaviour + 4 pinned-mode UI checks driven
in headless Chrome, and probes confirming the team/sign-off pickers populate and no
longer corrupt state.team on step navigation. Screenshots reviewed at 1920x1080.
Service-worker cache bumped to v3 so browsers pick up the new shell.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Predecessors are real references now
- data.predecessors holds work-package ids, replacing a free-text SOP phase label
that couldn't express "WP04 waits on WP02" and gated nothing. The SOP phase
survives beside it as the descriptive "Sequence phase" field.
- readiness() has two gates: constraints clear AND every predecessor Closed. The
banner, sticky bar, left rail, dashboard Gates column and the ready counters all
reflect the second one.
- Enforced server-side by enforce_release_gates() on every path that sets a status
— the plain upsert included, since that's how the browser and the offline outbox
save. /issue and /status would otherwise have been ways around it.
- Cycles are refused directly and through a chain, with a message naming the
package that already waits on this one. The Creator's picker also hides itself
and its own descendants, so a cycle is hard to build in the first place.
- A deleted predecessor does not block: it would freeze everything downstream of a
package someone removed.
- The gate is refusable, on purpose. Planners release ahead of upstream close-out,
so an explicit reason (data.gateOverride) allows it, gets a gate_overridden audit
event naming what was skipped, and prints on the package. A blank reason is not
an override, and changing the predecessor set clears it. The dashboard won't
release a blocked package at all — it points at the form where the reason is
captured.
Critical constraints reopened after release
- Reopening a SOP-critical constraint on a released package emails the owner, PM,
CM and the package's distribution list (minus whoever did it) and writes a
constraint_reopened audit event.
- Detected by diffing the incoming constraints against the stored ones inside the
normal upsert rather than via a new endpoint: the sync outbox only replays
POST /api/wps, so a dedicated route would be lost offline. It fires only on a
real cleared→open transition, so re-saving an already-open constraint doesn't
re-announce, and never before release or for a non-critical constraint.
- Bodies carry the constraint name, WP number and a link — never package contents.
Verified: 139 API checks on one fresh database (44 permissions + 22 password reset
+ 34 search/localization + 39 gates/notifications), including every bypass path,
cycle shapes, the deleted-predecessor case, blank-reason overrides, and the four
recipients confirmed both in the outbox and on the wire against a local SMTP sink.
27 driven UI checks against the real Creator page in headless Chrome covering the
picker, the override prompt (accept and cancel), override invalidation, the cycle
exclusions and the dashboard refusal. Screenshots reviewed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Site comments (8/3)
- BIM card: LOD removed, IFF # added next to the coordination status, and required
once that status is "Signed off (IFF)" — an unnumbered sign-off isn't traceable.
A LOD already stored on a package is preserved and shown as legacy, not blanked.
- The blue "from SOP types" subtext under a field is now a SOP chip on the label
with the detail in a tooltip. The chip stays visible rather than hover-only:
field tablets have no hover, and "this came from the SOP" is the part that
matters. The hint elements stay in the DOM (hidden) so the code writing to them
keeps working; an observer mirrors their text into the tooltip.
- Specification Section is no longer typed per package. Each WP type carries a
spec section on the SOP; the field is read-only in the Creator and follows the
type, with the SOP's spec folder linked underneath. This reads both spec
comments as one intent — stop typing it, derive it.
- Assignees and Distribution are multi-selects over the SOP project team, showing
each person's job function, with the CM pre-added to Distribution (removable per
package) and a free-text option for people with no account. The stored display
strings are unchanged so print/export/dashboard keep working; account ids ride
alongside for the notification work in wave 3.
Localization + time
- Per-user locale/timezone (Language & time in the user menu), an app-wide default
in the admin console, then the browser. Timezones are validated against the
server's zoneinfo and the picker is fed from it. Calendar dates are formatted
from their parts so a due date never reads a day early in another zone.
- Every displayed timestamp now goes through the shared helpers.
Top-bar chrome
- Project switcher beside the logo and a centered global search, injected into
either generation of top bar; skipped in an iframe so the embedded Creator
doesn't get a second one. Ctrl/Cmd-K focuses search.
- GET /api/search covers work packages, projects and SOPs, scoped to the caller's
projects, hiding archived packages, with LIKE wildcards escaped.
Fixed along the way: showForm() cleared every card's inline display, which undid
applyKind() — so the Package Type and BIM cards reappeared on an install-only
project. Split out applyKindVisibility() and re-apply it there.
Verified: 100 API checks on a fresh database (44 permissions + 22 password reset +
34 search/localization), 24 driven UI checks against the real Creator page in
headless Chrome (SOP chips, both people pickers, spec auto-fill, critical tags,
BIM suppression), and the chrome harness on both bar styles. Screenshots reviewed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Acts on the site comments from 8/3 plus the follow-ups. Foundation work first —
four of the comments all needed the project team to resolve to real user accounts.
Permissions vs project role (new)
- User.role is now the PERMISSIONS role: admin | project_admin | project_user.
project_admin may delete work packages, change a SOP after it is complete, and
delete a project; project_user may not (archiving a WP is still open to them).
Enforced by require_project_admin() server-side; the UI only hides dead ends.
- New User.project_role holds the person's JOB FUNCTION on the project. It grants
nothing — it feeds the SOP team pickers and notification routing.
- Admin console shows both columns and explains the difference. Migration rewrites
the legacy role 'user' to 'project_user'.
- Deleting a project was previously open to any member and unaudited; it now needs
project_admin and writes an audit event. ProjectData.remove no longer drops the
project from the local cache when the server refuses.
SOP project team from user accounts
- PM/APM/CM/QM and additional team members are pickers over the project's members,
storing the account id next to the display name. A name from an older SOP with no
matching account is kept and flagged rather than dropped.
- The WP Creator lists the SOP team first in the Owner picker, and a new package
defaults to whoever is creating it.
Critical constraints
- SOP constraints carry a Critical flag; buildConstraints() now copies the whole
definition through to the package (it previously reduced them to names, losing
description too), and critical rows are marked in the WP form. The email on
reopen-after-release is wave 3.
Password reset by email
- login.html gains Forgot password and a set-a-new-password view, offered only when
the server reports email is actually configured.
- Single-use signed token (AUTH_RESET_MINUTES, default 60) bound to token_version,
sent immediately rather than through the notifications outbox so a reset link is
never persisted. Identical response for unknown accounts; per-account send
cooldown; a completed reset clears any login lockout.
- Session and reset tokens are no longer interchangeable.
BIM kill-switch
- New admin Features card with bim_enabled, OFF by default. The SOP creator hides
the BIM section and the Creator treats every package as install-only while it is
off; a SOP that already has BIM keeps its data untouched.
Verified with two throwaway-database test scripts: 44 checks on the permissions
matrix and token handling, 22 on the reset flow end-to-end against a local SMTP
sink (real message captured, link extracted and used). Front-end files parse-checked
in headless Chrome. Not yet exercised in a browser against a real login.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Work Package form was capped at a 1000px column, which wasted most of a
desktop screen, and the only way to reach another package was to scroll to the
Saved table at the bottom.
- Put the form in a wide two-column shell (max 1760px); ctx-bar, mode-wrap and
the release banner widened to match.
- Above 1200px the two-up field grids flow to 3-4 columns instead of stretching
two fields across the whole card. Narrow layouts are unchanged.
- New sticky left rail listing every saved package, grouped by status in field
order, with WP number, subject, readiness dot and type. Click to open it in
the form; the package being edited is highlighted. Filter box, + New and
Dashboard shortcuts, collapsible (state persisted), hidden under 1100px where
the Saved table still covers navigation.
- The rail re-renders from renderSavedList(), so saves, deletes, splits,
archive/restore and the project pull all keep it current.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Brings the Work Package Suite from a browser-local prototype to a
multi-tenant, SQL-backed deployment hardened for customer IP.
Auth & access control
- Local username/password login (bcrypt + JWT in an HttpOnly cookie),
admin-managed users, per-project membership, and project-scoped API access.
- Admin console: change user roles, view the audit trail, manage settings.
Security hardening
- CSP / HSTS / X-Frame-Options / nosniff headers in nginx; Secure cookie via
X-Forwarded-Proto; CSRF Origin check; attribute-safe output escaping.
- Login lockout, token_version session revocation, stronger password policy,
fail-closed secret loading, encrypted (AES-256) database backups.
Persistence & schema
- SOPs and Work Packages are now DB-backed and shared across users, written
through a durable client sync outbox that queues offline edits.
- Alembic migrations applied automatically on container start.
New capabilities
- Phase 2 dashboard (progress, gating, pagination, archive).
- Phase 3 PWA "Field View" with offline caching and auth fallback.
- WP owner assignment with OPTIONAL email notifications, OFF by default and
toggled from the admin console. SMTP password is read only from the
SMTP_PASSWORD env var (never stored); emails carry a WP number + deep link,
never customer IP.
Also: IBM Carbon restyle, Help section, and DEPLOYMENT.md brought up to date.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
That deliverable is a BIM/EWP output (and on install-only jobs Prime
often doesn't own it), so it no longer appears in the default IWP
sequence. It now lives in the BIM sequence as the hand-off step, so it
only shows on BIM-enabled projects.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Reintegrates C-West8's "storing data in DB instead of client only"
(commit e5102446 on shared-data) on top of the BIM / per-package work.
localStorage becomes a per-browser cache; the server is authoritative.
- project-data.js: pullProject() hydrates the apps' existing localStorage
keys from the API on load; pushSOP()/pushWP()/removeWP() write through
on save/delete. WPs store the whole flat object in `data`, so BIM
fields, kind, and projectLinks round-trip intact.
- index.html: home pulls the project before showing SOP status; feedback
loads from /api/comments (server-authoritative, local fallback).
- work-package-suite-app.js: pull-then-restore on boot; completeSOP
pushes the SOP to the server.
- wp-creation-app.js: save/duplicate/issue/setStatus push; delete/clear
remove; boot pulls from the server first, then boots off the cache.
- server/app.py: /api/sops and /api/wps take full=true to return the
data JSON for one-request hydration (list stays lean by default).
Co-Authored-By: C-West8 <125926137+C-West8@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- enableBIM() prepends the BIM steps (BIM precedes construction) instead
of appending them.
- Default construction sequence updated to the agreed flow (2D sheets /
spool drawings -> conduit -> tray -> QC hold -> wire pull -> device ->
termination -> QC hold -> commissioning -> as-built), with QC-hold gates.
- Sample project now enables BIM/VDC so it demonstrates the full
BIM -> construction sequence.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Replace the whole-project BIM 'mode' with an opt-in capability + a
per-package kind, so a single project can produce both model and
install packages (and install-only projects are unaffected).
SOP tool:
- Step 4 "Include BIM / VDC work packages" checkbox (state.bimEnabled).
Enabling adds BIM package types + BIM release gates (flagged bim) plus
BIM roles/sources/process steps alongside the construction defaults;
disabling strips the bim-flagged items.
- Generated SOP carries bimEnabled and a per-type / per-constraint bim flag.
- Required sign-off role titles stay editable (no longer force-renamed).
Work Package Creator:
- Shows a Package Type selector (Install IWP / BIM EWP) only when the
SOP has bimEnabled; kind is saved per package and labeled in the output.
- WP types and release gates are filtered by kind (BIM types+gates for
EWP, install types+gates for IWP).
- EWP reveals the BIM Details card and hides controls.dev Assets /
Materials / Kitting-MIMO; IWP shows those plus the "Enabled by - BIM
package" traceability link.
Supersedes the earlier whole-project BIM mode.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
SOP tool:
- "Load BIM / VDC template" (Step 4): one click sets BIM deliverable
types, install-phase disciplines, BIM release-gate constraints (with
EN06 citations), the BIM process sequence, reference sources, BIM
sign-off roles, and MWP##-[Area]-[PHASE] numbering. Tags the SOP mode
as 'bim'.
- Step 3 required sign-off role titles are now editable (default
Superintendent/Foreman); the BIM template sets them to BIM Coordinator
and Construction Lead (CRS).
- Step 7: capture a project-homepage link for the chosen tracking and
commissioning platforms.
Work Package Creator:
- BIM mode (SOP.mode==='bim'): hides controls.dev Assets, Material List,
and Kitting/MIMO; shows a BIM Details card (LOD, model area, clash /
coordination status, linked scan).
- Project tracking/commissioning links are copied onto every WP and
shown in the WP output.
- "Enabled by - BIM package(s)" field links a field IWP back to the BIM
package that enabled it (EWP -> IWP traceability).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Logged-in users can change their own password from a "Password" link
in the top-right pill (dialog -> POST /api/auth/password, which requires
the current password).
- Login page gains a "Forgot password?" link explaining that resets are
admin-assisted (admins reset from the console). No SMTP, so no email
reset flow yet.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Access control:
- project_members table; non-admins only see/operate on assigned
projects (enforced across projects, SOPs, work packages — 403 else),
admins bypass. Creating a project auto-grants its creator access.
- Admin API to get/set a user's project assignments, plus a checkbox
assignment dialog in the Admin Console user list.
UI / workflow:
- Login page: drop the "Prime Controls" wordmark next to the logo.
- SOP tool: remove emoji icons from buttons and nav tabs.
- Rename "Step Comments" to "Feedback"; the author auto-populates
(read-only) from the signed-in user.
- Move usage-log viewing to the Admin Console; add an admin card that
lists all feedback/comments (who, what, page + step, when).
- Sample project name -> "Micron FMCS Install (sample)".
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Standalone instructions for the Portainer admin: set AUTH_SECRET_KEY,
rebuild + redeploy the stack, and bootstrap the first admin account.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Gate the suite behind a self-contained login (no external IdP):
- User model with bcrypt-hashed passwords; admin/user roles
- /api/auth endpoints: login, logout, me, change-password, and
admin-only user management (list/create/delete/reset/enable)
- Stateless JWT session in an HttpOnly, SameSite=Lax, auto-Secure
cookie; middleware refuses every /api data route without a session
- login.html + auth-guard.js: login page and per-page guard with a
top-right "name / Admin / Sign out" pill
- Admin Console now gated on admin role (passphrase gate removed) with
a User administration card
- manage_users.py CLI to bootstrap the first admin
- Rebuilt help.js into a searchable, multi-topic help center
- Local-dev convenience: app serves html/ so the site + API share one
origin under uvicorn (inactive in the prod container)
- Docs/env: AUTH_SECRET_KEY, requirements (bcrypt, PyJWT), README
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
With 2 workers, both ran Base.metadata.create_all() at import on an empty DB,
racing on CREATE TABLE (duplicate pg_type for "projects"). --preload imports
the app once in the master before forking, so tables are created a single time.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The api crash-looped because DATABASE_URL had an un-encoded special-char
password (@/!), so SQLAlchemy parsed part of the password as the host
("...@db" → name resolution failure).
db.py now prefers building the connection from POSTGRES_USER/PASSWORD/DB via
SQLAlchemy URL.create(), which encodes the password automatically — any
password works with no manual escaping. DATABASE_URL remains an optional
override (still must be hand-encoded if used). docker-compose now passes the
POSTGRES_* vars to the api container; DEPLOYMENT.md updated (incl. a Portainer
env-vars note).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Adds /admin.html — a passphrase-gated, in-site admin console for diagnostics
and testing: API connectivity check, DB snapshot, browser smoke test, and
demo-data seed/clean. Gate is SHA-256 obfuscation only (default passphrase
"prime-admin"); restrict at the network/proxy for real protection.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
html/admin.html + admin.js — a passphrase-gated console served at /admin.html:
- API connectivity check (clearly flags the /api/ 404 if the proxy isn't routing).
- Database snapshot (project/SOP/WP/comment counts via the API).
- End-to-end smoke test in the browser (mirrors smoketest.py: issue gate,
status, metrics, comments) with self-cleanup.
- Demo data: seed a DEMO project + clean DEMO-/SMOKE- projects.
Gate is SHA-256-based (default passphrase "prime-admin"; documented how to
change) — obfuscation only, not real auth; restrict at the network/proxy for
real protection. Not linked from the main nav.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
