2 Commits

Author	SHA1	Message	Date
n.siegfried	9ab7b48de2	T3.2 - C3/S5: one source of truth for colour; page sheets alias only ... theme-light.css is now the only file in html/ that contains a colour literal. The five page stylesheets and all four inline <style> blocks declare names and nothing else. theme-light.css 191 declarations, 175 with a literal value console.css 28 declarations, 0 work-package-suite-styles.css 16 declarations, 0 wp-chrome.css 14 declarations, 0 wp-creation-styles.css 24 declarations, 0 wp-sidenav.css 0 declarations, 0 #0f62fe is declared in one sheet, down from five. The eleven occurrences left inside theme-light.css are Carbon's own v10-to-v11 alias layer, which the inventory records as deliberate and not the S5 defect. Names were kept, because 111 var() references live in .js files across 23 token names and a rename there fails silently - no build error, no console warning, just an unstyled element. The rule the refactor was built on: consolidation is not unification. Where two sheets declared the same value, they collapse. Where they declared DIFFERENT values for one role - the two shadows, the eight status borders doing four jobs, the three mono stacks - each value got its own canonical name and the pair is recorded for T3.5. Picking a winner between two near-identical greys is a rendered change, which this task forbids. The console's zebra stripe is the one that would have bitten: #fafafa is six points from #f4f4f4, and merging them erases the striping on the nine-column user table. Collecting the one-offs in one place made two things countable that were not before: twelve distinct shadows, and a ninth amber (#8a6d00 on the field view, four points from #8e6a00 and doing the same job - BL-009). VERIFICATION - the screenshot done-when could not do the job, so it was replaced. Captured against wave 2, 11 of 14 shots were pixel-identical and 3 were not. Capturing wave 2 against ITSELF produced the same 3 differences at the same bounding box, so those shots cannot distinguish a regression from the clock. Trap 2 in the brief is half wrong: users.html is stable at both widths; the unstable third is the creator at 1440px, and admin's captured page height varies by ~600px between runs (BL-012). So tests/token_check.py was added. It checks what wave 3 actually claims: that every custom property resolves to the same literal, and every element computes the same colours, shadows and type. That is stronger than a screenshot - it covers the hover, focus and disabled rules a screenshot never exercises, and it is deterministic. wave 2 vs T3.2, all 7 pages: 178/178 wave-2 token names resolve identically, +213 new 3,500 elements compute identically, zero added, zero removed 16 tokens differ in notation only (#fff -> #ffffff), which is the duplicate class this task existed to collapse Two detours worth not repeating: the element walk was first keyed by sibling index and reported 55 phantom differences on the SOP page, where three JS-injected overlays append in whichever order their async work finishes (BL-011); and the comparator now normalises notation before reporting, because otherwise it fails on its own success. f_items 5 FIXED / F6 REPRODUCES as expected. browser_check 71/71. ONE DONE-WHEN NOT MET, recorded rather than skipped: "no page stylesheet declares a raw color, spacing or type value". The colour half is met in full. 483 raw spacing values, 281 font-sizes and 65 radii remain inside rules, 492 of them in the creator. That is arithmetic, not effort: the creator's spacing is every integer from 1px to 14px, so no token exists that padding:9px 11px maps to without changing one of the numbers - and this task forbids changing a rendered value. The two requirements are mutually exclusive. Logged as BL-010 for T5.x and T7.1, where those pages are re-laid-out and the values get chosen again. New backlog: BL-009 (ninth amber), BL-010 (raw spacing/type in rules), BL-011 (overlay append race), BL-012 (unstable screenshot targets). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-15 18:50:30 -05:00
n.siegfried	4ace2afb1c	Move user administration to its own page; add Project Super User ... 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>	2026-08-05 17:36:14 -07:00