Admin Navigation, User Foundations, and the First Session Resets

The RABS admin frontend was a collection of standalone HTML pages — each one hand-crafted with its own header, sidebar, and script tags. Over three days in late September 2025, the first Factory sessions tackled two foundational projects: a navigation standardization pass across every admin page, and a complete user authentication and management system built from scratch. Both projects pushed through session token limits, network disconnects, and terminal crashes — establishing the survival patterns that would define months of development to come.

Context

The admin frontend at this point was a traditional multi-page HTML application served by Express. Each page had its own layout, its own version of the header and sidebar, and its own approach to JavaScript. There was no shared chrome, no consistent navigation highlighting, and no user management at all — login existed as a concept but the full auth pipeline hadn't been built yet.

Two task documents drove the work: navigation_task.md laid out rules for standardizing every HTML page with shared partials, breadcrumbs, and auto-highlighting; users_task.md described the complete end-to-end user system — backend auth routes, session management, user CRUD, and admin frontend pages for login, registration, pending approvals, password reset, and the users table.

What happened

Navigation standardization — page by page

The first session opened with the navigation task. The approach was deliberately manual: go page by page through the admin folder, inject the shared header and sidebar partials, fix breadcrumbs where they existed, and leave them alone where they didn't. The task document was explicit — do not automate the injection, preserve original page content and layout, only make the listed modifications.

The auto-highlight feature — which highlights the current page's sidebar entry — was the key UX win, but it only worked on one page: page_hr.html. The second session investigated why: the HR page had the correct auto-highlight block injected during an earlier standardization pass, while the other pages were missing it or had a broken version. The solution was to copy the working HR-page pattern across all eligible admin pages.

Vendor script tags had to be plain and absolute (/assets/... with no type="module"), and the cookie library filename was singular (js.cookie.min.js, never the plural variant). These details were easy to get wrong and required careful checking on each page.

The navigation pass touched nearly every HTML file in the admin folder — calendar, email pages, analytics, billing, cog pages, comms panel, file manager, gallery, incident reports, invoices, logs, messenger, participants, payroll, program pages, and more. Each page got the same treatment: inject the shared partials, add the auto-highlight block, add the per-page JS module hook, and leave everything else alone.

The user system — from scratch

Once the navigation work was functionally complete, the sessions pivoted to the user system. This was a much heavier lift: the backend needed authentication middleware, user routes, session management, and JWT token handling; the admin frontend needed login, registration, pending-user approval, and a full users management page.

The backend work produced:

• middleware/auth.js — Authentication middleware checking headers and query parameters for Bearer tokens. (The cookie fallback — critical for browser elements like <img> and <iframe> that cannot send Authorization headers — was added in a later session, not during these September sessions.)
• routes/auth.js — Login, registration, and token refresh endpoints.
• routes/users.js — Full user CRUD with role-based access.
• services/ and utils/ — Supporting utilities for token generation, validation, and session management.

The admin frontend work produced:

• page_users.html and page_users.js — A full users table with search, filter, pagination, bulk activate/deactivate, edit modal, and password reset modal. All API calls used Bearer auth with debounce search, toast feedback, and date formatting in the Australia/Sydney timezone.
• page_pending.html and page_pending.js — A page for approving or rejecting pending user registrations.
• page_login.html and page_register.html — Updated with the new auth flow.
• session.js — The client-side session management utility that stores tokens in localStorage. (The cookie-based fallback for authenticated file serving was added later, not in these September sessions.)
• boot_user.js — A nav/user boot script that ran on every page for badge rendering, logout handling, and access guards.

The first session resets

The user implementation session hit the session token limit — the first time this happened in the project. Brett had to reset the connection, open a new session, and manually provide context about where the previous session left off. This pattern would repeat endlessly in the months ahead.

The very next session (September 28) was a network disconnect recovery. Then the terminal crashed mid-edit on a profile page update. Then a build error on September 29. Then another connection reset. In the span of three days, five of the nine sessions were restarts or recovery — and this was considered normal.

What changed

Before these sessions, the admin frontend had no shared navigation and no user system. After, it had:

1. Consistent shared chrome across 30+ admin HTML pages — header, sidebar, breadcrumbs, and auto-highlight all driven from shared partials.
2. A working auth pipeline — JWT-based login, registration, session management with cookie fallback for browser elements, and role-based user management.
3. Per-page JS module hooks — the <script type="module"> pattern that would later become the foundation for the Vite-based rebuild.
4. The survival pattern — when sessions die, prepare context documents, open a new session, and pick up where you left off. This became the default operating mode.

Work produced

Area	Key files created or heavily modified
Navigation	30+ admin HTML pages standardized with shared partials and auto-highlight
Auth middleware	backend/middleware/auth.js — header → query → cookie auth chain
Auth routes	backend/routes/auth.js, backend/routes/users.js
Auth services	backend/services/, backend/utils/
Users frontend	admin/page_users.html, admin/page_users.js, admin/page_pending.html, admin/page_pending.js
Session management	admin/src/js/session.js, admin/src/js/auth-login.js, admin/src/js/auth-register.js
Task documents	navigation_task.md, users_task.md

What we learned

The auth middleware pattern — check the header first, fall back to query parameter — became a permanent fixture of the codebase. The cookie fallback (added in a later session) would eventually solve the problem of browser elements that cannot send Authorization headers, and the full header → query → cookie pattern was documented in the project's AGENTS.md for every future agent to understand.

The session token limit was a new constraint. It meant that complex multi-file implementation tasks had to be broken across sessions, with Brett manually providing context continuity. The navigation task document itself became a template for how to structure task instructions so that a new session could pick up where the previous one left off.

Where this led next

The navigation standardization was the first pass, but the admin frontend was still a traditional compiled HTML application. Within days, the project would pivot to a Vite-based source build — ripping out the compiled approach and rebuilding the entire admin frontend from source. That rebuild, covered in the next post, would leverage the <script type="module"> pattern introduced during this navigation pass as a natural stepping stone toward a modular source-build architecture.

The user system, meanwhile, was functional but basic. Roles, permissions, and the full staff/participant access control layers would come much later — but the auth middleware and session cookie pattern established here never changed.