[BUG] [alpha] Loading container in Tags panel uses hardcoded height (128px) instead of adaptive layout or design token

[robertbot1000]

Project

ide

Description

In the Tags panel, the loading state container is rendered with a fixed height of 128px.

This hardcoded height introduces a rigid layout constraint in a dynamic content area. Loading states should typically adapt to available space or use design system tokens to ensure consistency across different layouts and screen sizes.

Using a fixed pixel value for height in this context can lead to inconsistent spacing, especially when the container size or surrounding layout changes.

Error Message

Debug Logs

System Information

OS: Ubuntu 24.04
RAM: 32 GB

Screenshots

Steps to Reproduce

Open the Tags panel
Trigger a loading state (e.g., initial load or refresh)
Inspect the loading container using DevTools
Observe the applied style: height: 128px

Expected Behavior

Loading containers should use flexible sizing (e.g., auto, flex, or token-based height)
Layout should adapt to container size and maintain consistency with design system spacing
Hardcoded pixel values should be avoided for dynamic UI states

Actual Behavior

Loading container uses a fixed height of 128px
Layout is constrained by hardcoded value
Does not adapt to surrounding layout or content

Additional Context

No response

[echobt]

❌ Invalid

This is NOT a valid bug report. The issue describes a code quality preference about using hardcoded pixel values vs. design tokens, but this is a COSMETIC/DESIGN PREFERENCE, not a real bug that affects user functionality.

Analysis:

1. Screenshot: Authentic Cortex IDE screenshot showing Tags panel with DevTools highlighting height: 128px - this is coherent with the issue
2. Component: Found TagManager component in src/components/git/TagManager.tsx at line 591
3. Code verification: Confirmed the loading container uses height: "128px" as an inline style
4. Accessibility: Component is accessible via GitPanel → Tags button

Why this is INVALID:

• The issue describes a DESIGN PREFERENCE ("should use flexible sizing", "should use design system tokens") - this is not a functional bug
• The hardcoded height does NOT break any functionality - the loading spinner displays correctly
• This is a subjective code quality concern, not a real user-facing bug
• No user is blocked or significantly frustrated by this 128px height
• The "Expected Behavior" section describes ideal code architecture, not a fix for broken behavior

Real bugs are things that are BROKEN, WRONG, or MISSING. This is working as implemented - the reporter just prefers a different implementation approach. This is a feature request/enhancement disguised as a bug report.

Per the validation rules: "Minor cosmetic preferences ('I don't like this color', 'icon should be bigger')" and "Subjective design opinions ('button should be on the left instead of right')" are INVALID.