RBA Build Plan v1.0 — RBA Dev Team Portal v1.0.0

Build Docs · Gold

RBA Build Plan v1.0

Section-by-section build execution guide for the Texas RBA Case Management System. Covers all 10 components, build sequence, phase structure, and integration.

Project Brief

Project: Texas RBA Case Management System v1.0 Purpose: Browser-based arbitration case management — replaces Airtable workflow End User: John Gann (arbitrator, admin) + unlimited assistants Platform: Duda HTML widgets (Business plan) — all pages hidden from nav Database: Firebase Realtime Database — compat SDK only, NOT Firestore Firebase Proj: rba-mgr (separate from rba-dev-team-portal) AI: Claude API — image intake on Case Intake Form; key in Settings Email: Phase 1: mailto links; Phase 2: Claude API-generated drafts Auth: None in Phase 1 — no login required Design Spec: arb-implementation-plan-v05.html (authoritative source of truth)

Duda Rules — Every File

addEventListener() only — never onclick="" · !important on all CSS · Never document.body.innerHTML = · Hidden/visible div toggling for all state changes · Firebase compat SDK via CDN script tags only

File Naming Conventions

rba-[component]-mockup.html ← Phase 1 static prototype rba-[component]-v[X.X].html ← Phase 2+ working version rba-[component]-final-v[X.X].html ← Production ready
#
Component
Mockup File
Working File
C1
Firebase Setup
n/a (config only)
rba-firebase-config.js
C2
Settings Page
rba-settings-mockup.html
rba-settings-v1.0.html
C3
Case Intake Form
rba-intake-mockup.html
rba-intake-v1.0.html
C4
Case Dashboard
rba-dashboard-mockup.html
rba-dashboard-v1.0.html
C5
Case Detail View
rba-case-detail-mockup.html
rba-case-detail-v1.0.html
C6
Email Templates
rba-email-templates-mockup.html
rba-email-templates-v1.0.html
C7
Status Automations
n/a (JS module)
rba-automations-v1.0.js
C8
Communication Log
rba-comm-log-mockup.html
rba-comm-log-v1.0.html
C9
Resource Section
rba-resources-mockup.html
rba-resources-v1.0.html
C10
Reports Page
rba-reports-mockup.html
rba-reports-v1.0.html

Build Sequence & Dependencies

#
Component
Depends On
Why First
C1
Firebase Setup
Everything reads/writes to Firebase
C2
Settings Page
C1
Field toggles + API key needed before intake
C3
Case Intake Form
C1, C2
Creates cases — must exist before dashboard
C4
Case Dashboard
C3
Reads cases created by intake
C5
Case Detail View
C4
Drills into individual case records
C6
Email Templates
C5
Pre-populates from case data in detail view
C7
Status Automations
C5
Hooks into case detail save events
C8
Communication Log
C5
Lives inside case detail view
C9
Resource Section
C1
Independent — only needs Firebase for editable docs
C10
Reports Page
C4
Aggregates data from all cases

Phase Methodology

Every component follows the same three-phase build pattern. Never begin Phase 2 until Phase 1 is complete and reviewed.

Phase Structure
  • Phase 1 — Structure & Layout: Static HTML only. No JavaScript. All values in [bracket] placeholders. Brand styles applied. Mobile-tested at 400px.
  • Phase 2 — Interactivity & Logic: Firebase wired. All data reads/writes functional. Event handlers via addEventListener() . Form validation. Success/error states via div toggling.
  • Phase 3 — Polish & Edge Cases: Empty states handled. Loading indicators. Real data tested. Edge cases verified. Version stamped in 3 locations. Production-ready.

Components C1 – C10

C1 Firebase Setup config only

One-time setup. No HTML mockup phase — just Firebase console configuration and the config snippet included in every subsequent component file.

Phase 1 ✓
// Config snippet — paste into every component file const firebaseConfig = { apiKey: "[from console]", authDomain: "rba-mgr.firebaseapp.com", databaseURL: "https://rba-mgr-default-rtdb.firebaseio.com", projectId: "rba-mgr", storageBucket: "rba-mgr.firebasestorage.app", messagingSenderId: "[from console]", appId: "[from console]" };
C2 Settings Page /settings

Global configuration hub. Must be built before Case Intake because field toggle states and the Anthropic API key are read by the intake form at runtime.

Sections: arbitrator profile · Anthropic API key (localStorage, never Firebase) · field toggles → arbitrators/[id]/settings/fieldToggles/ · resource docs CRUD → resources/[id]/

Phase 1 ✓ Phase 2 ✓ Phase 3 ✓
C3 Case Intake Form /new-case

Creates new case records. Supports manual entry and AI image intake (Claude API reads PTAS screenshot → populates fields). Respects global field toggle settings. 29 fields across 5 groups: Property, Parties, Appeal, Hearing, Financials.

Key integrations: field toggles from Firebase on load · File # auto-generation ( counters/[id]/[year] , YYYY-### format) · Claude API image intake (base64 encode → API call → map response to fields) · saves to arbitrators/[id]/cases/[caseId]/

Phase 1 ✓ Phase 2 Phase 3
C4 Case Dashboard /cases

Lists all cases. Search, filter, sort. Status badges. Payment-due flags. Aggregate payment summary. Links to Case Detail View.

Table columns: File # · Arbitration # · Status · County · Property Owner · Tax Year · Hearing Date · Hearing Type · Arb Fee · Last Modified. Filters: status, county, hearing type, verdict. Row click → /case/?id=[caseId]

Phase 1 ✓ Phase 2 ✓ Phase 3
C5 Case Detail View /case/?id=

Full case record in 3 tabs mirroring PTAS structure: Tab 1 — Request Dashboard · Tab 2 — Hearing · Tab 3 — Award. 17 panels total. Most complex component.

Includes Rule 9.4212 trigger, compliance checklist, email log, payment tracking, and terminal status (Dismissed / Withdrawn Untimely) accessible from the case header at all times. Terminal status triggers a manual fee entry field.

Phase 1 Phase 2 Phase 3
C6 Email Templates modal in Case Detail

7 pre-populated mailto templates: E1 Schedule Request (×4 variants: In-Person/Teleconference × No Agent/With Agent) · E2 Schedule Confirmation & Procedures · E3 Pre-Hearing (×2: In-Person/Teleconference). Plus Rule 9.4212 pre-filled certified letter.

Phase 1: mailto links (arbitrator's own email client). Phase 2: Claude API-generated email drafts.

Phase 1 Phase 2 Phase 3
C7 Status Automations integrated in C5

14 triggers wired into Case Detail save events. Every status change auto-appends to statusHistory[] with timestamp. Terminal statuses accessible at any stage.

No fee auto-logic anywhere. Fee amounts, deposit amounts, party responsible, and all financial fields are manual entry only — as communicated by the Comp.

Phase 2 only
C8 Communication Log Tab 1 panel in C5

Per-case communication log panel inside Case Detail Tab 1. Fields: date, type (Email/Phone/Mail/Certified Letter), contact person, contact role, summary, follow-up required flag. Saves to arbitrators/[id]/cases/[caseId]/communications/[commId]/

Phase 1 Phase 2 Phase 3
C9 Resource Section /resources

Reference library. Static content: fee schedule (reference only — no auto-calculation), dismissal workflow, Withdrawn Untimely guide, status workflow reference, Comp portal links. Arbitrator-editable docs stored in resources/[id]/ .

Phase 1 Phase 2 Phase 3
C10 Reports Page /reports

10 charts and stat cards plus payment aggregate view. All data sourced from Firebase case records. Arbitrator only — read only. Charts: Cases by Status (donut) · Cases by Month (bar) · Cases by County (bar) · Hearing Type Split (pie) · Verdict Outcomes (donut) · Payment Source Split (pie) · Revenue Summary (stat cards) · Average Values (stat cards) · Cases This Year · Payment Aggregate table.

Phase 1 Phase 2 Phase 3

Integration Phase

Run after all 10 components are individually production-ready.

Integration Checklist
  • Confirm all component files are at their final versions
  • Consolidate shared CSS (color vars, typography, table styles) into a shared stylesheet
  • Consolidate shared JS (Firebase init, field toggle loader, color maps)
  • Deploy Duda pages in order: Settings → Intake → Dashboard → Case Detail → Resources → Reports
  • Test full end-to-end: create case → view in dashboard → open detail → update status → view in reports
  • Test Rule 9.4212 flow end-to-end with a real case
  • Test terminal status (Dismissed and Withdrawn Untimely) from different workflow stages
  • Test AI image intake with 5+ real PTAS screenshots
  • Test mailto templates — all 7 variants open correctly in email client
  • Verify payment aggregate totals match manual calculation
  • Check browser console — zero errors across all pages
  • Test on mobile (400px) — all pages usable
  • Update Firebase security rules for production (remove open test mode)

Versioning Rules

Update version in three places on every release: the <title> tag, the visible page header, and the changelog comment block at the top of the file.

Change Type
Version Bump
Major rebuild or new section added
v1.0 → v2.0
New feature added
v1.0 → v1.1
Bug fix or small tweak
v1.1 → v1.1.1
<!-- ============================================================ TEXAS RBA - [COMPONENT NAME] Version: v[X.X.X] Last Updated: [Date] ============================================================ CHANGELOG: v[X.X.X] - [Date] - [What changed] v1.0.0 - 2026-02-22 - Initial build DUDA RULES: - addEventListener() only — no onclick="" - !important on all CSS - Never document.body.innerHTML = - Hidden/visible div toggling for state changes ============================================================ -->