File Manager Access Control, Participant Files, and the Type2 Broker Tools Review

The second week of April 2026 marked a convergence point in the RABS build. Multiple feature arcs that had been developing in parallel — the file manager's access control layer, the participant files system, the TokenWatch monitoring integration, and the Type2 agent broker tools — all landed in the same three-day window. This wasn't a planned convergence; it was the natural result of a project where the frontend, backend, agent layer, and documentation were all being built simultaneously.

Context

By April 2026, the RABS admin frontend had matured significantly from its early navigation-standardization days. The Vite-based source build was well established, the DB2 cutover was mostly complete, and the Type2 agents (Reggie and Henry) were live and handling broker-mediated tool calls. But several systems were still at different stages of completion:

• File Manager — functional for browsing and editing files, but without granular access control on exec folders
• Participant Files — mostly scaffolding and ideas, far behind the staff files system which had a working tab/file framework
• TokenWatch — the API monitoring system needed to be wired to multiple backend routes (incidents, finance, SMS, AI generation, email, HR, YP3000, 11labs)
• Type2 Agent Broker Tools — both droids and claws instances of Reggie and Henry were ready, but the implementation plan for switching features over to them was delicate and needed careful assessment

What happened

April 8: TokenWatch wiring and file manager access control

The day opened with a batch of worker sessions that wired TokenWatch to specific route groups:

Worker session	Routes wired
TokenWatch → incidents + resolution	Incident reporting and resolution tracking routes
TokenWatch → finance routes	Billing, invoicing, payment request routes
TokenWatch → SMS services	Outbound SMS dispatch and webhook routes
TokenWatch → AI gen + chat + prefs	AI generation, chat, and user preferences routes
TokenWatch → email + HR + YP + 11labs	Email dispatch, HR endpoints, YP3000, and ElevenLabs voice routes

TokenWatch was the project's API health and token usage monitoring system. Wiring it to each route group meant that any API call through those routes would be tracked — recording token consumption, response times, and error rates. This was essential for cost tracking across the AI-powered features.

The main session then tackled the file manager's exec folder access control. The file manager needed a permissions system that controlled which users could access specific exec folders — the executive-level document storage that required tighter access restrictions than general file storage.

The implementation involved:

• Access control middleware — verifying that the requesting user had the right permissions for the target folder before allowing read, write, or delete operations
• Permission buttons in the UI — a Permissions button (with key icon) that enabled when exactly one folder was selected, opening a modal to configure access
• Action gating — download, rename, permissions, and view buttons all disabled by default, only enabling based on selection state and user permissions
• OnlyOffice callback handling — the OnlyOffice integration callback route was placed before auth middleware because the OnlyOffice server calls back without browser credentials, requiring a separate authentication strategy for that specific endpoint

April 9: Rebuilding participant files on the staff files framework

The participant files system was the most substantial rebuild of the arc. Brett's instruction was clear and characteristically direct: "the participant files is still mostly scaffolding and ideas of what would be needed but now let's get them really ready. so firstly staff files are a lot further along I would suggest looking at those the tabs etc get an idea of that framework as participants will be similar."

The approach was systematic:

1. Study the staff detail page — examine page_staff_detail.html and page_staff_detail.js to understand the tab structure, file upload patterns, document categories, and the overall framework
2. Assess the current participant files — review what scaffolding existed in the participant detail page and identify gaps
3. Compare backend routes — check what API endpoints existed for staff files versus participant files
4. Implement the rebuild — bring participant files up to the same level as staff files

The staff files framework provided a clear template: tab-based navigation for different document categories (documents, training, compliance), file upload with type validation, document listing with metadata, and download/delete actions. The participant files rebuild went beyond simply matching the staff files framework — it created a participant_documents system, a participant_addresses system with multi-address support (primary, mailing, pickup/dropoff flags, date ranges for temporary addresses), expanded the edit modal from ~13 fields to ~45+ fields across 7 sections covering contacts, NDIS plan details, clinical information, and addresses. These were novel designs not present in the staff files framework.

This session was one of the largest in the archive — over 46,000 lines. It also included a major pivot into payroll system work: fixing Xero rate limiting, filtering Deputy discarded shifts, resolving Xero date format bugs, seeding classification rules, fixing public holiday detection, building a pay run creation system with allowances management, and implementing a comprehensive UX overhaul with a 7-step workflow indicator. The payroll work occupied roughly half the session's technical output, reflecting how the project interleaved feature arcs even within a single session.

April 10: Type2 agent broker tools status review

The third day shifted focus from implementation to assessment. Brett wanted to understand where the Type2 agent broker tools stood: "Can you please take a look in docs/docs and admin/tasks as well as the admin frontend and see if we can determine where we are up to on the type2 agents broker tools etc. both droids and claws instances of Henry's and Reggie's are ready but implementation is going to be delicate because we will need to switch some features over to them."

The review examined:

• Documentation — docs/docs and docs-originals contained Type2 agent session architecture documents, CLI multistep agent manuals, and broker tool specifications
• Active task files — admin/tasks/tasks_active/type_2_agents/ had the implementation tracker and agent manual
• Admin frontend — agent chat pages, configuration UI, and the broker integration points
• Broker readiness — the approval queue for agent-initiated actions (SMS, tool calls) was functional, with human-in-the-loop review for sensitive operations

The key finding was that both the droid (Factory-based) and claw (OpenClaw-based) instances of Reggie and Henry were technically ready, but the transition from the current system to agent-mediated features required careful sequencing. Switching a feature over to an agent meant that the agent became responsible for that feature's API calls, and any failure in the agent pipeline would block the feature entirely.

The review identified several areas where the broker tools needed further work before features could be safely switched:

• Approval pipeline completeness — some tool types had approval queues but no executors
• Fallback mechanisms — if an agent was unavailable, the feature needed a direct-access fallback
• Rate limiting — agent-mediated API calls needed rate limiting to prevent runaway tool usage
• Audit trail — brainframe.tool_calls needed to capture every broker-mediated action for compliance

What changed

Before	After
File manager had no exec folder access control	Permissions middleware with UI gating based on user roles and folder access
Participant files were scaffolding	Full tab-based file framework rebuilt on the staff files pattern
TokenWatch was disconnected from most routes	Wired to incidents, finance, SMS, AI generation, chat, preferences, email, HR, YP3000, and ElevenLabs routes
Type2 broker readiness was unknown	Comprehensive status review identifying approval pipeline gaps, fallback needs, and rate limiting requirements

Work produced

Area	Key files created or heavily modified
TokenWatch wiring	Worker sessions wiring monitoring to 5 route groups
File manager access control	page_file_manager.js — permissions button, action gating, access middleware
OnlyOffice auth	Callback route placed before auth middleware for server-to-server calls
Participant files rebuild	page_participant_detail.html/js — tab-based framework matching staff files
Type2 broker review	Status assessment with identified gaps and next steps

What we learned

The participant files rebuild reinforced a pattern that would repeat throughout the project: when two features share a conceptual structure (staff files and participant files), build the first one fully, then use it as the explicit template for the second. Brett's instruction to "look at staff files first" was direct and effective — it avoided the trap of designing a parallel structure from scratch when a working reference already existed.

The OnlyOffice callback authentication issue was a subtle but important lesson. Some endpoints need to sit outside the standard auth middleware chain because they're called by servers, not browsers. Placing them before auth middleware in the route mounting order solved this — but it meant those endpoints needed their own authentication strategy (typically a shared secret or signed callback validation).

The Type2 broker review revealed that "ready" and "production-ready" are different states. The agents could handle tool calls, but the infrastructure around them — approval executors, fallback paths, rate limiting, audit completeness — needed work before features could safely be delegated to agent control.

Where this led next

The TokenWatch wiring continued into the following weeks, expanding to cover more route groups and adding alerting thresholds. The participant files framework became the foundation for the care profiles work that would dominate late April. And the Type2 broker readiness gaps identified in this review became the roadmap for the agent architecture upgrades that followed — including the approval pipeline executors that eventually made end-to-end agent-mediated SMS and tool calls possible.

This three-day convergence — access control, file framework rebuild, and agent readiness assessment — was a microcosm of the RABS build as a whole: frontend, backend, and agent layer all advancing in parallel, each informing the others, and each requiring its own kind of careful implementation before the whole system could move forward.