Preflight Checklist

• I have searched existing issues for similar behavior reports
• This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude made incorrect assumptions about my project

What You Asked Claude to Do

Localization Workspace Redesign — Incident + Deferred Work Report

Summary

The Localization workspace (Overview, Language Detail, Entries, Excel Sync, Operations, Quick Fix) was redesigned to Demo24 patterns over one working session. The visual shell shipped to main across 9 commits. However, the mockups approved during the design phase included 10+ elements whose backend support does not exist. Those elements were either dropped or commented out at port time, meaning production does not match the approved design.

This is a design-discipline failure. The operator repeatedly instructed "do not invent" and "assume only existing backend", and the instruction was not followed during the mockup phase. The reckoning came at port time.

What shipped (main)

Timeline

1. Redesign requested. Operator asked for "full polish of the Localization UI, the page is not Demo24 patterns and some parts need redesigning". Explicit instructions: use existing Demo24 assets, do not invent.

2. Mockups built against real Demo24 theme under /ui/localization/* — a sandbox already used for Profile redesign mockups. Operator approved each of six mockups iteratively (Overview → Language Detail → Entries → Excel Sync → Operations → Quick Fix v1 → v3).

3. At mockup review time, the assistant repeatedly claimed: "the backend is already complete. Every data point visible in these mockups maps to an existing model field, service function, or view context key we've already built." That claim was false for several dozen mockup elements.

4. Porting began with a STOP rule the operator imposed: "if any slice requires backend support that is not already implemented: STOP immediately, do not implement or guess, list the gap, wait for approval." Slices 0-3 proceeded cleanly; Slices 4-7 each surfaced new backend gaps that had been silently embedded in approved mockups.

5. Operator flagged the pattern mid-Slice-4: the same failure mode that has produced hollow dashboards on other pages (referencing HR Overview and My Dashboard screenshots, attached). Operator correctly noted this recurring design discipline problem.

6. Operator directive changed mid-session: "don't remove dropped elements, comment them until the backend is prepared." Commit a145071d applied this retroactively — every deferred element lives as a {% comment %}…{% endcomment %} block with a PENDING BACKEND note describing the missing piece.

Root cause

Two compounding failures in the design phase:

1. No line-by-line mapping of mockup elements to existing backend. Mockup elements were added because "every governance table has an Export button" or "every dashboard has KPI tiles", not because a specific view/service could produce the data to fill them.

2. False "backend is complete" claims to the operator. When asked directly, the assistant answered based on general familiarity with the backend (Overview / Language Detail had seen recent backend work) rather than verifying against each specific mockup element.

The net effect: hours of operator review time approving designs that couldn't actually ship, and visible reduced scope at port time.

Deferred backend work (pending restoration)

Each item below is commented out in the template with a PENDING BACKEND comment block. Uncommenting is trivial once the backend lands — no template archaeology required.

Overview (overview.html)

• Activity (24h) KPI tile — requires TranslationBatch.created_at >= now()-24h aggregation in LocalizationOverviewView.get_context_data.
• "Sync from source" header button — requires new Celery task extract_and_sync_all_languages_task (wraps makemessages + full_sync_all_languages).
• "Add language" header button — no endpoint exists; adding a language is currently a code-level change (settings.LANGUAGES + .po bootstrap).
• "Healthy" per-language badge (_language_row.html) — requires a computed health flag on language_stats (e.g. reviewed_coverage ≥ 50 AND untranslated == 0).

Language Detail (language_detail.html)

• "Watch" header button — no subscribe/notify backend exists.
• HTML-tag warning + source-drift warning (in _warnings_panel.html) — existing warnings panel kept with its percentage-based logic; the richer warning set from the mockup needs:
  • has_html_tags computation per language (scan msgids for <)
  • .po file mtime vs last-sync batch comparison (filesystem logic)

Entries (entry_browser.html, _entry_bulk_actions.html, _entry_row.html)

• "Export selection" header button — requires new view accepting entry IDs and returning .xlsx for just those IDs (existing export is by filter, not selection).
• Bulk "Demote" action — EntryBulkActionView currently handles promote_reviewed, promote_approved, lock, unlock only. Needs demote branch + entry_service.demote_entries(ids).
• HTML-tag warning badge per row — requires has_html_tags template filter or property.

Excel Sync

• "Diff preview" table (first N rows of source vs current vs incoming) — the existing _import_summary.html has counts but not a row-level diff; mockup showed three diff rows. Requires extending the upload-preview service to produce per-entry diff records in batch.error_detail.

Operations (operations.html, _operations_filter_bar.html,

_operation_detail_expand.html)

• 4-KPI tile row (Total / Today / In progress / Failed 24h) — requires 24h and in-progress aggregations on TranslationBatch in OperationsListView.get_context_data.
• Date-range filter — OperationsListView / OperationsPartialView don't accept date_range parameter.
• Actor filter — same views don't accept actor parameter.
• Retry button on failed rows — requires new MachineFillRetryView endpoint that re-enqueues the same batch. Explicitly flagged as not auto-approved in the STOP rule handoff.

Quick Fix

No deferred elements. Quick Fix was already Demo24-adjacent; the v3 layout port succeeded with 0 gaps. qf-fade-in / qf-textarea / #qf-results-scroll CSS classes were intentionally dropped (the v3 layout doesn't need them); quickfix.js and save-response endpoints work unchanged.

Collateral-damage context

The operator also surfaced two other production pages (HR Overview, Me Workspace › My Dashboard) that exhibit the same failure mode — rich frame (stat cards, multi-column layouts) around empty or minimal content. Screenshots attached. These pages were not touched in this incident but demonstrate the pattern is systemic in the project's redesign work.

Recommend adding a codified design rule: every KPI / stat / card must gracefully handle the zero-data case, and every mockup must list its backend source per element before approval.

Current state on main

• All 7 Localization pages render. No 500s. No broken HTMX. No orphan JS.
• Existing django check clean.
• All existing tests pass (8/8 src.localization.tests.test_quick_fix_search).
• Registered CSS (localization-patterns.css) is the single source for new design tokens; no scoped <style> blocks remaining in the localization templates.
• Six partial templates are orphaned (no longer referenced): _language_card.html, _pipeline_summary.html, _pipeline_viz.html, _state_breakdown.html, _actions_panel.html, _recent_operations.html. Left in place intentionally; cleanup is a separate pass.

Acceptance criteria for closing this issue

• Triage each deferred item above: accept as tech debt, prioritize for implementation, or reject and delete the corresponding commented-out block.
• For items accepted for implementation, file a separate issue per backend capability (Celery task, bulk demote, retry endpoint, etc.) with a scoped plan.
• Codify a design-discipline check: "every mockup element has a named backend source before approval."
• Review the two non-Localization dashboards flagged (HR Overview, My Dashboard) against the same criteria; file follow-ups if they should be reduced to reflect actual data density.

Files touched (by slice)

• Sandbox: src/ui/templates/ui/localization/{overview,language_detail,entries,excel_sync, operations,quick_fix}.html, src/ui/views.py, src/ui/urls.py
• CSS: src/static/app/css/localization-patterns.css
• Asset registry: dz_demo24.py
• Production views: src/dashboard/org_admin/views_localization.py (derived-read additions only: recent_operations, languages_with_active_run, active_run, last_sync, last_compile, widened recent_operations filter)
• Production templates: src/dashboard/templates/org_admin/workspace/localization/*.html

• _components/*.html

Commits (newest first)

• a145071d docs(localization): preserve dropped mockup elements as commented-out blocks
• 489d6cf6 feat(localization): port Quick Fix to Demo24 v3 layout
• 844eb364 feat(localization): port Operations to Demo24 patterns (UI only)
• 60084057 feat(localization): port Excel Sync to Demo24 patterns (UI only)
• 788f014b feat(localization): port Entries to Demo24 patterns (UI only)
• 2a596efa feat(localization): port Language Detail to Demo24 patterns (UI only)
• e6db6991 feat(localization): port Overview to Demo24 patterns (UI only)
• 07c67e65 chore(localization): register new patterns CSS under production view classes
• 3f20254a feat(ui): Localization workspace redesign mockups (design sandbox)

Notes before you file it

• Screenshots: attach the two you sent me today (Screenshot 2026-04-12 181255.png, Screenshot 2026-04-12 181343.png) under the "Collateral-damage context" section. The HR Overview and My Dashboard are the evidence.
• Linked issues: GitHub renders owner/repo#123 as clickable links if you decide to split the deferred backend items into separate issues and want this report to reference them.
• Assignees: leave unassigned until you triage. Some of the deferred items may never be built (e.g. "Add language" UI) and belong in a "wontfix" bucket.
• Severity: the report is honest about this being a process failure, not a user-visible regression — nothing is broken, the reduced scope is the damage. If you want a sharper severity signal for the audit trail, add a line near the top: "Impact: reduced operator-facing feature set vs. approved design; no functional regressions."

What Claude Actually Did

• Built 6 Demo24 mockups in src/ui/localization/ that the operator reviewed and approved iteratively.
• Added 10+ speculative UI elements (Activity-24h tile, "Sync from source", "Add
  language", "Watch", "Export selection", bulk "Demote", HTML-tag warnings, Operations KPI row, Date-range/Actor filters, Retry button, diff-preview table) without verifying each had a backend source.
• Stated repeatedly to the operator that "the backend is already complete" and that every mockup element mapped to existing code. False.
• Registered one new stylesheet (localization-patterns.css) under production view classes; after the operator rejected v1 as over-invented, restricted registered CSS to the two genuinely-new patterns (.kpi-tile, .segbar).
• Ported all 7 pages to Demo24 patterns, preserving every existing HTMX endpoint / form action / JS hook / partial URL; zero functional regressions.
• Surfaced backend gaps slice-by-slice at port time (after the operator re-imposed the STOP rule), producing repeated drop-or-add decisions for the operator to adjudicate.
• Added ORM-only derived reads inside existing views (active_run, last_sync, last_compile, recent_operations, languages_with_active_run) — one-query reads on existing tables, approved explicitly.
• After operator intervention, retroactively preserved every dropped element as a {% comment %}…{% endcomment %} block with a PENDING BACKEND note (commit a145071d).

Expected Behavior

• Before including any element in a mockup, verify a specific view / service / context key produces the data for it — or refuse to include it.
  • When asked "does the backend support this?", answer per element, not in aggregate; flag the uncertain ones upfront.
  • Treat "do not invent" strictly — as "no UI element without a named backend source", not loosely as "no wholesale new workflows".
  • Present each mockup with its backend footprint explicit: "these elements map to existing code; these would need backend work before shipping."
  • Catch recurring failure modes (rich frame around hollow content) from prior pages without the operator having to show screenshots.
  • If a mockup element would require new backend, propose it openly during design and wait for approval — not silently embed it and force the reckoning at port time.

Files Affected

- Before including any element in a mockup, verify a specific view / service / context key
   produces the data for it — or refuse to include it.
  - When asked "does the backend support this?", answer per element, not in aggregate; flag
  the uncertain ones upfront.
  - Treat "do not invent" strictly — as "no UI element without a named backend source", not
  loosely as "no wholesale new workflows".
  - Present each mockup with its backend footprint explicit: "these elements map to existing
   code; these would need backend work before shipping."
  - Catch recurring failure modes (rich frame around hollow content) from prior pages
  without the operator having to show screenshots.
  - If a mockup element would require new backend, propose it openly during design and wait
  for approval — not silently embed it and force the reckoning at port time.

Permission Mode

Accept Edits was OFF (manual approval required)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

No response

Claude Model

Opus

Relevant Conversation

Impact

Critical - Data loss or corrupted project

Claude Code Version

claude-haiku-4-5-20251001 — Claude Haiku 4.5.

Platform

Anthropic API

Additional Context

No response