[UX Redesign] Move Registros into Configurações without changing audit behavior

[luandro]

Summary

After Issue #19 has built the Configurações skeleton (which deliberately hides the Registros Settings step button until this issue lands), populate the <section id="registros"> placeholder inside #view-settings with the existing Logs surface, reveal the Registros step button, and remove the Logs primary-nav surface. Use the tiny openSettingsSection("registros") helper and the shared showSettingsStep(n) step-activation mechanism (introduced by #19). State remains in-memory only.

Current state (after #19 has landed)

After Issue #19 lands, #view-settings contains the populated Operação / Detecção / Notificações / Sistema sections (each already showing its full form) plus the populated empty <section id="fr24"> and <section id="registros"> anchor containers. The Registros Settings step button is hidden (and remains hidden until this issue lands). The Settings step activation logic is the shared, externally-callable showSettingsStep(n) introduced by #19.

• #view-logs (app/static/index.html:242-275) currently contains:
  • Kind filter (all / call / observation / detection).
  • Provider filter (populated dynamically from PROVIDER_INFO).
  • Hex search input.
  • Inside-only checkbox.
  • Help button (#logs-help + #logs-help-text).
  • Error message area (#logs-error).
  • Summary (#logs-summary).
  • Table (#logs-body) with columns: time / kind / provider / region / detail / aircraft / disposition.
  • Pagination prev/next (#logs-prev, #logs-next).
• API: GET /api/logs returns rows with recorded_at, kind, provider, region_id, detail, aircraft_hex, inside, area_names, classification, disposition, plus pagination total / offset / limit.
• Filter and pagination state lives in appState.logsFilter / appState.logsOffset (in-memory only). There is no persistence across full browser reload — that behavior is unchanged.
• The current loadLogs() orchestrator (app/static/app.js:1264) is the existing logs data-loading path; it is reused by app/static/app.js:1563 / :1599 whenever the Logs tab is activated.

Prerequisite

Issue #19 (Configurações IA) has created the <section id="registros"> placeholder inside #view-settings, the shared showSettingsStep(n), and openSettingsSection(sectionId). The Registros Settings step button is hidden. This issue is the one that reveals it.

UX target

Inside #view-settings, the Registros section renders the same content the standalone Logs tab exposes today:

Registros
  ┌─ Filters ────────────────────────────────────┐
  │ [kind ▾] [provider ▾] [hex_____] [inside ☑] │
  │ [Aplicar]                                    │
  └──────────────────────────────────────────────┘
  ┌─ Summary ────────────────────────────────────┐
  │ 123 linhas · página 1 de 5                   │
  └──────────────────────────────────────────────┘
  ┌─ Table ──────────────────────────────────────┐
  │ time | kind | provider | region | detail |  │
  │ aircraft | disposition                        │
  │ ...                                          │
  └──────────────────────────────────────────────┘
  [Anterior]  [Próxima]

The structure is identical — only the location moves. Filter and pagination state remain in-memory only (no persistence across reload); this issue MUST NOT add persistence behavior that doesn't exist today.

Atomic reveal (this issue owns this)

Because Issue #19 deliberately hides the Registros step button until this issue lands, this issue MUST atomically:

• Populate <section id="registros"> inside #view-settings with the existing logs surface.
• Add / unhide the Registros Settings step button. It uses the shared showSettingsStep(n) mechanism for ARIA / visible state.
• Wire the Registros step activation to trigger the existing loadLogs() data-loading path.
• Remove the old Logs primary-nav surface (tab-logs, view-logs, the tab.dataset.view === "logs" branch in the tab activation handler).
• Remove the Logs entry from the #nav-overflow overflow menu.

Loading semantics

Merely moving Logs DOM into <section id="registros"> inside #view-settings does NOT cause the existing Settings tab activation to call loadLogs(). This issue wires the Logs loader explicitly:

• The shared step activation mechanism (showSettingsStep(n)) optionally invokes a section-specific loader. For Registros, attaching loadLogs() to step activation means opening Configurações › Registros — whether by clicking the Settings stepper, by openSettingsSection("registros"), or by any other activation path — triggers loadLogs().
• Other Settings step activations (#operacao, #deteccao, #notificacoes, #fr24, #sistema) do NOT trigger loadLogs(). They use their existing loaders.
• The Logs table may use a horizontal scroll on narrow viewports (preserved from the existing Logs surface). This is intentional inner-container scrolling, not page-level horizontal scroll.

Existing functionality to reuse

• GET /api/logs — unchanged.
• All existing filter inputs.
• Existing logRow() renderer (app/static/app.js:1230).
• loadLogs() orchestration + appState.logsOffset pagination (in-memory only).
• logsPopulateProviderSelect() (app/static/app.js:1172).
• logsRegionLabel() helper.
• translateDisposition() translation helper.
• Existing i18n keys (logs_*).
• The help-button toggle (aria-describedby).
• The openSettingsSection(sectionId) DOM helper and showSettingsStep(n) shared step activation mechanism introduced by Issue [UX Redesign] Reorganize Configurações into clear operational sections #19.

Scope

• Remove #view-logs container from index.html.
• Remove the Logs tab from primary navigation (and the Logs entry from the #nav-overflow overflow menu).
• Populate the <section id="registros"> placeholder inside #view-settings (created by [UX Redesign] Reorganize Configurações into clear operational sections #19) with the existing logs surface.
• Reveal the Registros Settings step button. It uses the shared showSettingsStep(n) mechanism.
• Wire Registros step activation to trigger the existing loadLogs() path.
• No new hash routes. No general hash router.

Out of scope

• New log retention, new log format, new log fields.
• New observability backend or new diagnostics infrastructure.
• New export / download action (none exists today).
• New filters or new pagination styles.
• Showing raw technical payload beyond what /api/logs already exposes.
• Persisting filter or pagination state across full browser reload. Today's behavior is in-memory only via appState; this issue does NOT change that. Tests assert in-memory behavior only.
• A general URL hash router.

Detailed behavior

Filters

• Identical behavior. Filter apply button (#logs-filter) calls loadLogs() with the current filter state.
• Hex search input accepts up to 6 hex chars (existing behavior).

Table

• Identical behavior. Same columns, same disposition translation, same classification badge.
• Inside-badged rows use the existing signal inside / signal outside classes.

Pagination

• Identical behavior. #logs-prev / #logs-next use appState.logsOffset.
• Filter and pagination state is in-memory only; full reload resets to defaults. Do not add localStorage / sessionStorage / URL hash query for these — the current behavior is the contract.

Help

• Identical behavior. The ? button toggles #logs-help.

Loading / error state

• Identical behavior. #logs-error shows server errors.
• On Registros step activation, loadLogs() runs and may produce its existing loading / error states.

Empty state

• Existing logs_no_rows translation — reuse.

Responsive behavior

Identical — table has horizontal scroll on narrow viewports (existing behavior). This is intentional inner-container scrolling, not page-level horizontal scroll.

Keyboard behavior

Native form order for filters. Table rows not focusable.

Data / API impact

No backend/API changes expected.

Routing / navigation impact

• Logs is no longer a top-level destination. #view-logs is removed from index.html.
• The Logs tab is removed from primary navigation. The Logs entry is removed from #nav-overflow. The overflow container may stay until [UX Redesign] Final responsive, accessibility, and consistency pass #22 removes it.
• openSettingsSection("registros") activates the Settings tab, calls showSettingsStep(n) to activate the Registros step, and triggers loadLogs().
• No new hash routes. No general hash router.

Security / privacy

• No new data exposure. /api/logs already returns the same rows.

Acceptance criteria

• Registros panel is reachable from Configurações (via the <section id="registros"> placeholder created by [UX Redesign] Reorganize Configurações into clear operational sections #19).
• The Registros Settings step button is visible alongside Operação / Detecção / Notificações / FR24 / Sistema.
• Opening Configurações › Registros (via stepper click or via openSettingsSection("registros")) triggers the existing loadLogs() data-loading path.
• The Registros step activation uses the shared showSettingsStep(n) mechanism (the one used by all other Settings steps). No duplicate stepper-state logic.
• All four filters (kind / provider / hex / inside) work unchanged.
• Pagination works unchanged.
• Filter and pagination state survive in-session tab/section navigation but are NOT persisted across full browser reload (current behavior).
• Help button toggles the existing help copy.
• Empty state shows the existing copy.
• No new logging behavior is introduced.
• #view-logs is no longer present in index.html.
• The Logs tab is removed from primary navigation; the Logs entry is removed from #nav-overflow.
• No new hash routes. No hash router introduced.

Test plan

• VM JS (tests/test_registros_vm.mjs): filter combinations, pagination, empty state, in-memory filter+page preservation across in-session tab/section navigation (NOT across reload); openSettingsSection("registros") activates Settings + Registros step (through showSettingsStep(n)) + triggers loadLogs(); the Registros step button is visible in the stepper.
• Integration: filter by hex + inside-only, navigate to another tab and back, assert filter state preserved; full browser reload, assert filter state resets to default (current behavior).
• Regression: existing logs round-trip tests pass unchanged.
• Accessibility: filters reachable via keyboard; table has caption for screen-reader.
• Responsive: screenshots at 1280, 768.

Visual QA

• 1280px Registros expanded with results.
• 1280px empty state.
• 768px table with horizontal scroll (intentional inner-container).

Dependencies

• Issue [UX Redesign] Simplify global shell and primary navigation #13 (shared shell labels) — required.
• Issue [UX Redesign] Reorganize Configurações into clear operational sections #19 (Configurações IA; <section id="registros"> placeholder + showSettingsStep(n) + openSettingsSection helper created here) — required.

Rollout / compatibility

• No saved configuration changes.
• No data migration.
• Logs data unchanged.

Open questions

None.