fix(chat): replace the shattered wordmark with a font-independent one

[ndemianc]

The wordmark from #82 shattered into disconnected bars in the editor. This reverts it and installs a mark that does not depend on the font filling its character cells.

What went wrong in #82

I claimed the art "cannot develop seams in any monospace font" because it was drawn entirely from █.

Half the reasoning was sound — ▀ above ▄ does leave a full cell of gap, and I verified that. The conclusion did not follow: whether █ FILLS its cell is a property of the FONT, not of the character.

font	old mark
SF Mono, Menlo, Courier New, Andale Mono, Consolas, generic	solid
Monaco	shattered

My harness ran SF Mono, so it looked perfect everywhere I checked — and none of those checks were the editor.

Why this mark survives

╭──────────────────────────────╮
│                              │
│  ▁▃▅█  L E V E L C O D E     │
│                              │
╰──────────────────────────────╯

It asks for neither property that failed:

• the frame is box-drawing rules — connector glyphs designed to join across cells in every monospace family
• the letters are real text, not pixels
• ▁▃▅█ is the only block run left, and it is decorative — an ascent, "level" made literal — so a font that renders it slightly short costs nothing

Verified before shipping this time, which is the part I skipped: rendered in Monaco, SF Mono, Menlo, Courier New, Andale Mono, Consolas and the generic fallback, plus the real empty state in Monaco in both themes. Legible in all seven; Monaco leaves hairline gaps at the frame corners and nothing else.

The two numbers are one number

The mark is 32 columns where the old one was 41, so the container-query factor moves with it: clamp(5px, 3.6cqi, 13px) → clamp(5px, 4.6cqi, 13px).

41 × 3.6 and 32 × 4.6 both land the mark at ~88% of its container. The test now pins that relationship rather than either number, because changing the art without the factor is exactly how this breaks — widen it and it overflows, narrow it and it becomes a stamp floating in white space. The failure message reports the computed fill percentage.

The old guard is gone

It required "full blocks only", encoding the false belief as a rule. It would have blocked this fix and waved through the bug it was written for. That is worse than no test, and the replacement says plainly that ASCII art has to be looked at in the target font — a static test cannot do it, so it no longer pretends to.

Guards

Each bypass-verified by reverting the fix:

bypass	caught
cqi left at the old 41-column value (69% fill — a stamp)	✓
cqi raised too far (115%)	✓
art widened without touching the cqi (127%)	✓
sizing no longer container-relative at all	✓
role="img" dropped	✓
the accessible name dropped	✓

33 tests in webviewCss, 34 suites green.

[Copilot]

Pull request overview

Reverts the empty-state chat wordmark in the LevelCode AI webview back to the prior (figlet-style) mark to avoid the Monaco rendering artifact, and updates the CSS/webview test to stop asserting an untrue “full blocks only” rule while preserving layout and accessibility checks.

Changes:

• Restore the previous multi-line wordmark in the chat empty state (media/chat.html).
• Remove the “full blocks only” glyph guard from webviewCss.test.js, keeping container-fit + a11y assertions.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
extensions/levelcode-ai/test/webviewCss.test.js	Drops the incorrect “full blocks only” assertion; keeps width/height bounds and role/aria-label checks.
extensions/levelcode-ai/media/chat.html	Replaces the empty-state <pre.lc-ascii> art with the prior wordmark content.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.