brain-of-reese/.agents/phases/complete/157_chat_chip_cap/00_phase.md

Phase 157 — hero suggestion chips cap their display at 90 characters

Source: owner UX audit 2026-10-03 (live interactive-browser pass): "hero suggestion chips — consider a char cap — long opening questions get hard-truncated mid-word… the chips stretch near full container width before clipping." Story: n/a (audit-derived phase; the chip machinery is phase 80's 80_history_suggestion_chips + phase 104's 104_chip_sizing_question_cap, both complete) Context: app.js::renderChips(container, items, onSelect) (L1272–1315) — the ONE shared chip component (the hero #suggestions + the deflection "Maybe try" chips). Phase 104's contract (owner-locked 2026-09-12, in-code): the single-line chip CLIPS long questions (CSS), title is the hover reveal, aria-label is the clipped-case accessible name (the source-chip pattern), and the click submits the FULL text (submitSuggestion(text) + onSelect(text, btn)). Today there is NO display-length cap — a 300-char opening question stretches its chip to near full container width before the CSS clip engages (the audit's observation: the hero's third chip ran the full reading-column width). Phase 104 also capped the COMPOSER (the input) — a different surface, untouched here. The chips' content is the 3 newest saved chats' opening questions (phase 80/103) — owner-derived, textContent-only (the house rule), so a display cap is a pure presentation change: the click payload stays full.

Objective

The chip's DISPLAYED text caps at 90 characters with a clean … (the chip stays compact — no more full-width hero chips), while the title hover reveal, the clipped-case aria-label, and the click payload all keep the FULL question (phase 104's contract, extended).

Dependencies

• 80_history_suggestion_chips (complete) — the hero chips' content contract (the 3 newest opening questions).
• 104_chip_sizing_question_cap (complete) — the single-line CSS clip + the title/aria-label idiom this phase EXTENDS (the cap makes the CSS clip a secondary guard, not the primary one).

Design (shared by all tasks — the executor reads this, not the chat)

• The cap (ASSUMPTION A1, owner-locked): CHIP_CAP = 90 — a named constant in app.js (the module's top, beside the other chip constants). Applied to the DISPLAYED text ONLY in renderChips: btn.textContent = text.length > CHIP_CAP ? text.slice(0, CHIP_CAP).trimEnd() + "…" : text. slice(0, 90).trimEnd() avoids the trailing-space-before-… artifact when char 90 is mid-word (the trimEnd is the pin). The title is UNCHANGED (the full text — the hover reveal, phase 104). The aria-label logic is UNCHANGED (the clipped-case accessible name is the full text — with the cap, a long chip is ALWAYS "clipped" in the visual sense, but phase 104's scrollWidth > clientWidth check still governs the aria-label: a 91-char display still overflows its single-line box at typical widths, so the aria-label lands; a SHORT string (< 90) is byte-identical to pre-phase in every respect — the no-cap case is unchanged).
• The click payload (the load-bearing invariant): submitSuggestion(text) + onSelect(text, btn) take the FULL text (the un-capped value) — UNCHANGED. The cap is display-only: a capped chip sends the full question (the user gets their full question submitted — the phase-80 contract). A unit pin asserts the handler receives the FULL string for a >90-char item.
• Scope: renderChips is shared (hero + Maybe-try) — the cap applies to both (a single code path; the Maybe-try chips are title-derived and short — the cap is a no-op there, and the byte-identity of short strings is the guard). NO other file changes (the CSS clip stays as the secondary guard; the composer's phase-104 cap is a different surface — untouched).

Tasks

1. 01_chip_cap.md — the CHIP_CAP constant + the display-only cap in renderChips + the comment in the phase-104 voice.
2. 02_unit_pins.md — the boundary pins (89/90/91), the full-text invariant, the short-string byte-identity.
3. 03_e2e_chip_cap.md — the dedicated Playwright suite.

Testing & Quality

• Unit: source-level pins — the 90-char boundary (an 89-char display is unchanged; a 90-char display is unchanged (the cap is >); a 91-char display is slice(0,90).trimEnd() + "…" — the exact string pinned); the title is the full text in all three cases; the click/onSelect payload is the FULL text for a >90-char item (the load-bearing invariant); a <90-char item is byte-identical to pre-phase in textContent/title/aria-label (the short-string guard).
• Integration: the /api/suggestions contract is untouched (no server change — a regression guard only).
• Coverage: >90% on the modified JS (the pins).
• The phase is "Complete" only when the entire project test suite passes 100% (every test in the project, not just this phase's).
• E2E: uv run pytest tests/e2e/test_chat_chip_cap.py -v --no-cov in isolation (DB up: podman compose up -d db; the deterministic tests/e2e/mock_llm.py).

Documentation & Consistency

• The final pass reviews README.md and AGENTS.md in full against the project as it stands after this phase — fixing every inconsistency found, including pre-existing ones not caused by the phase.
• Tasks update README.md/AGENTS.md immediately when their own changes are user-visible (the cap is a visible UI change — name it where the onboarding chips are described, if anywhere).

Completion Criteria

• a >90-char opening question renders a ≤91-char display (the cap + the …) — the E2E
• clicking the capped chip submits the FULL question (the user bubble shows the full text — the E2E's load-bearing assertion)
• the title hover reveal + the clipped-case aria-label carry the full text (the E2E)
• a <90-char question is byte-identical to pre-phase (the pin)
• uv run pytest green; the dedicated E2E green in isolation; uv run ruff check . && uv run pyright clean; app/ coverage >90%
• one atomic commit per AGENTS.md rule 8 (--no-gpg-sign)