Files
Oleksandr Bezdieniezhnykh 510df68bcf [AZ-447] autodev Steps 1-4 baseline: docs, tests, refactor specs
Captures the full output of autodev existing-code Phase A through
Step 4 (Code Testability Revision) for the Azaion UI workspace:

- Step 1 Document: _docs/02_document/ (FINAL_report, architecture,
  glossary, components/, modules/, diagrams/, system-flows,
  module-layout) plus _docs/00_problem/ + _docs/01_solution/ +
  _docs/legacy/ + _docs/how_to_test + README.
- Step 2 Architecture Baseline: architecture_compliance_baseline.md.
- Step 3 Test Spec: _docs/02_document/tests/ (environment,
  test-data, blackbox/performance/resilience/security/
  resource-limit tests, traceability-matrix), enum_spec_snapshot,
  expected_results/results_report.md (98 rows), plus the
  run-tests.sh + run-performance-tests.sh runners.
- Step 4 Code Testability Revision: 01-testability-refactoring/
  run dir (list-of-changes C01-C07, deferred_to_refactor,
  analysis/research_findings + refactoring_roadmap) and the 7
  child task specs AZ-448..AZ-454 under _docs/02_tasks/todo/
  plus _dependencies_table.md.
- _docs/_autodev_state.md pins the cursor at Step 4 / refactor
  Phase 4 entry so /autodev resumes cleanly.

Epic AZ-447 (UI testability gates) tracks the 7 child tasks that
will land in subsequent commits.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-05-11 00:38:49 +03:00

2.7 KiB
Raw Permalink Blame History

10 — App Shell

1. High-Level Overview

Purpose: Application bootstrap. main.tsx mounts React + StrictMode + BrowserRouter; App.tsx defines the top-level routing tree and provider stack.

Architectural Pattern: Composition root.

Upstream dependencies: every other component (this is the wiring root).

Downstream consumers: none (top of the tree).

2. Internal Interfaces

src/main.tsx

  • Imports ./i18n/i18n for side-effect (00_foundation).
  • Imports ./index.css.
  • Mounts <StrictMode><BrowserRouter><App /></BrowserRouter></StrictMode> into #root.

src/App.tsx

Routes:

Route Wrapping Component
/login (public) 04_login/LoginPage
/flights (default authenticated) AuthProvider → ProtectedRoute → FlightProvider → Header 05_flights/FlightsPage
/annotations same 06_annotations/AnnotationsPage
/dataset same 07_dataset/DatasetPage
/admin same — no role guard 08_admin/AdminPage
/settings same 09_settings/SettingsPage
* same redirect → /flights

5. Implementation Details

State Management: provider stack only (AuthProvider, FlightProvider).

Findings (5 items from src__App-and-main.md):

  1. No role-based route guards on /admin (PRIORITY — security). /settings is more nuanced (no SETTINGS permission code in spec; server-enforced via 403).
  2. Mobile bottom-nav route layout — confirmed present (Header.tsx:113129). Earlier draft incorrectly listed this as missing; corrected per state.json 02:01Z.
  3. No ErrorBoundary — any uncaught render throw crashes the whole app to a white screen.
  4. No lazy chunks / code-splitting — every route is in the initial bundle. Compounds the chart.js bloat from 05_flights.
  5. /flights is the default landing for everyone — user-specific landing per role would require 00_foundation permission types + 02_auth.permissions.

Key Dependencies: react-router-dom 7.

7. Caveats & Edge Cases

  • No ErrorBoundary is the highest-impact gap; even one runtime null deref in any feature kills the app.
  • /admin open to any authenticated user at the UI level (PRIORITY).
  • No lazy loading — initial bundle is ~all of the SPA.

8. Dependency Graph

Must be implemented after: every other component (composition root).

Can be implemented in parallel with: nothing.

Blocks: nothing.

Module Inventory

Path Module Doc
src/App.tsx _docs/02_document/modules/src__App-and-main.md
src/main.tsx _docs/02_document/modules/src__App-and-main.md