# BidBrain project status, part 15: The decision card, more login automation, platform toggle (27 August 2026)

Moved unchanged from CLAUDE.md on 2026-09-18. The standing rules stay in CLAUDE.md, which lists every part of this log.

  - THE LIVE AUCTION CARD REDESIGNED, "THE DECISION CARD", 2026-08-27
    (Mark shared a live design mockup, "Card Density Mockups", built in
    an earlier Claude conversation, comparing today's card at 840 to
    1,027px tall against a proposed ~450px version; "make this change
    but keep the image 4:3"). Investigated the real mockup live first
    (the artifact tool itself could not read it as a shared, non member
    link, fell back to driving it directly in the Browser pane) and
    then the real current `_shortlist_card`/`_hf_gauge`/`_insight_rows`
    code via a research pass before writing anything, catching a real
    self correction along the way: an early reading of the mockup
    assumed a "platform pill" needed moving onto the photo, re checking
    the actual screenshot text found no such element was ever shown,
    only the already existing stock/gap and countdown badges, so
    nothing was built for that.
    - Title moved onto the photo itself, bottom left, with a new dark
      gradient scrim (`.hf-photo-scrim`) so white text stays legible
      over any colour car; the reg plate moved from bottom left to
      bottom right to share the same row (`.hf-photofoot`, a flex row,
      title `flex:1` with an ellipsis, plate `flex:none` so it never
      shrinks). The old `<h3>` row below the photo and its own
      `.hf-titlerow` CSS are gone outright. `.hf-photo`'s own
      `aspect-ratio:4/3` was untouched throughout, confirmed live
      afterward via a real rendered card's own bounding box (360.5 by
      270.375px, exactly 1.333).
    - `_hf_gauge` rebuilt from a two row layout (a floating max bid
      label above the track needing tight/normal/wide branching so it
      never collided with the retail figure, depending where the dot
      landed) into one fixed 3 column row, Reserve / Max bid (with the
      room pill) / Retail, left to right, above the track. A fixed
      layout can never collide regardless of where the dot sits, so
      the wide branch is gone entirely; tight is kept only for the
      track's own dot spacing at the very left edge. CompMatch's own
      purple suggested bid dot stays on the same track unchanged, its
      own figure now sits in a small line under the track instead of
      in the old bottom row.
    - Flags (already icon only with hover tooltips from the 2026-08-20
      traffic light redesign), Valuations (renamed from "Valuation
      detail", its own trigger shrunk from a full width row to a small
      pill) and the CTA (shrunk from a big black full width button to
      a small pill, "View on" prefix text dropped, an aria-label kept
      for accessibility) now sit together in one utility row
      (`.hf-utility`, pinned to the bottom of the card the same way
      `.hf-foot` used to). "Hide this car" moved out of a permanent
      text link into a new "..." overflow menu (`.hf-more`, `_HF_MORE_
      SVG`), a rarely used action that no longer needs its own row.
    - A REAL PRE EXISTING BUG FOUND AND FIXED, confirmed by the
      mockup's own framing ("no more one click silently changing every
      card on the page"): `toggleFlags()`/`toggleVals()` took no
      argument and operated on `document.querySelectorAll('.hf-flags')`
      /`.hf-vals` GLOBALLY, so opening one card's own flag notes or
      valuation chips silently opened every card on the page at once,
      via two page level booleans persisted to `localStorage['bidbrain_
      display_prefs']`. Fixed by having each chevron pass itself
      (`onclick="toggleFlags(this)"`) so the handler can act on
      `this.closest('.hf-card')` alone. Verified live: opening one
      card's own chevron left an adjacent card genuinely untouched
      (`card0Open: true, card1Open: false`), confirmed directly against
      the real DOM, not assumed from the code alone.
    - A NEW Comfortable / Compact density control replaces what those
      two booleans used to do on their own: two pill buttons in the top
      control bar (`.densitybtn`, same `.tabs`/`.tab` visual pattern as
      the platform tabs), remembered in `localStorage['bidbrain_
      display_prefs']` under a new `density` key. Clicking one is a
      real, deliberate bulk action, `applyDensityToAllCards()`, setting
      EVERY card's own flags and valuations to that state at once and
      repainting the buttons; a card's own chevron only ever touches
      that one card afterwards, never the saved default, never any
      other card, so the two mechanisms cannot fight each other.
      Verified live: Comfortable correctly opened all 248 currently
      visible cards' own flag sentences and valuation chips at once
      (`allOpenFlags: true, allOpenVals: true`); a genuinely fresh page
      load (not just a JS call) correctly defaulted to Compact with
      every card collapsed and the right button marked "on".
    - Cards / List (a fast, table style view for "the morning cull",
      per the mockup's own framing) was deliberately NOT built in this
      pass: a full parallel list/table rendering of the live auction
      grid is a genuinely separate, large feature (its own columns,
      sorting, filtering) rather than a density variant of the existing
      card, and building it half attentively alongside this redesign
      risked doing both pieces less well. Flagged here rather than
      silently dropped; ask for it as its own piece of work if wanted.
    - Verified live end to end throughout on the real cockpit, not just
      the unit tests (none of `_shortlist_card`/`_hf_gauge`'s own
      markup ever had dedicated coverage beyond `_hf_gauge`'s existing
      Carwow/Motorway label text checks, which still pass unchanged):
      a real card rendered with the title and plate correctly sharing
      the photo's own bottom row, the gauge's three columns and track
      all correct against real Reserve/Max bid/Retail figures, the
      "..." menu opening "Hide this car" and closing again on an
      outside click, the Valuations dropdown revealing real Cazana
      figures, and the held/rejected slim cards (`_plain_card`, a
      wholly separate function, untouched) still rendering normally (22
      of them on the same real page). No console errors on load. 556
      tests pass (render only, no gate or pricing logic touched, no
      dedicated new tests, matching this whole area's established
      pattern of live verification over unit coverage).
  - THE "..." MENU WAS GENUINELY INVISIBLE, FOUND AND FIXED THE SAME
    DAY, 2026-08-27 (Mark: "the meatball icon the pop isnt viewable").
    Checked live rather than guessed: `.hf-more-menu` opened downward
    from the button (`top:calc(100% + 6px)`), but the "..." button sits
    right at the bottom of the card's own utility row, and `.hf-card`
    itself needs `overflow:hidden` for the photo's own rounded top
    corners, so the menu was being clipped clean off the bottom of the
    card, confirmed directly (`menuRect.bottom` 919.9 against the
    card's own `cardRect.bottom` 892.1, a real 27.75px cut off). Fixed
    by opening the menu UPWARD instead (`bottom:calc(100% + 6px)`),
    which keeps it inside the card's own box, always tall enough to
    hold one small menu. Verified live, not just geometrically: a real
    `document.elementFromPoint` check at the menu item's own centre
    confirmed a genuine click there would actually hit the item, not a
    same looking element sitting on top of it (the same rigorous check
    already used elsewhere in this project for exactly this class of
    bug, see the DealerKit automation entries), and clicking it for
    real correctly opened the hide reason box. 556 tests pass (render
    only, no new tests).
  - AUC STATUS MOVED OFF NATIVE HOVER TOOLTIPS ONTO THE SAME CLICK
    OPENED POPOVER AS EVERY OTHER FIGURE ON THIS PAGE, 2026-08-27
    (Mark, back on the purchases page: "i have told you to have tool
    tips, i want to remove the rollover on the status and make the
    tool tip infos appear like this"). His message referenced an image
    that never actually came through, so asked one quick confirming
    question rather than guess at what "like this" meant: matching the
    Winning bid and Retail est. columns' own existing `_infoCell`
    popover exactly, confirmed.
    - Every `title="..."` attribute on the 3 stage icons and the group
      itself is gone, replaced by wrapping the whole `.au-stages` group
      in `_infoCell`, the same click (or tap) opened popover already
      used elsewhere on this page. The popover lists Bid, Documents,
      Delivery (each coloured green "good" once reached, amber "est"
      while known but not yet, matching the icons' own traffic light
      colours exactly), the real underlying Status word, and Payment
      "Estimated breakdown" when `payment_estimated` is set, all in one
      place rather than scattered between a tooltip and a conditional
      popover the way it was before.
    - A REAL VISUAL BUG CAUGHT BEFORE SHIPPING, not assumed fine just
      because it reused the existing helper: `.info-trigger`'s own CSS
      draws a dotted underline, built for a plain text figure like
      "£12,495", not a row of 3 icon circles, so reusing it verbatim
      would have left a stray dotted line sitting under the icons for
      no reason. Checked live (`getComputedStyle` confirmed `border-
      bottom-style: dotted`) before it ever reached a screenshot, fixed
      with a scoped `.info-trigger:has(.au-stages) { border-bottom:
      none; cursor:pointer; }` override, verified afterward to read
      `none`.
    - Verified live end to end across all three real states on file:
      a real "Collection arranged" row opened to "Bid Accepted" /
      "Documents Checked" / "Delivery arranged" / "Status Collection
      arranged", all green; a real "Reviewing documents" row opened to
      the same Bid line green but "Checking" / "Delivery needs
      arranging" both amber (`info-row est`); a real row with an
      unconfirmed Motorway payment breakdown (KF66GJZ) correctly added
      a 5th "Payment, Estimated breakdown" row. 556 tests pass (render
      only, no new tests, matching this whole page's own established
      pattern).
  - DUE IN MADE EDITABLE, THE SAME WAY AS RETAIL EST., 2026-08-27 (Mark:
    "make the due in editable like the retail est"). Built as a direct
    mirror of the 2026-08-26 Retail est. work: a new nullable
    purchases.collection_date_override column, db.set_collection_date_
    override(purchase_id, value), applied in db.list_purchases the same
    way the retail cap and override already are, so every reader of a
    purchase row, the page itself, the Due in view, and the DealerKit
    due in date push (dealerkit_write.push_purchase reads purchase.get
    ("collection_date"), unchanged) all agree on the same effective
    date. A new /api/set-collection-date endpoint, validated with a
    real datetime.date.fromisoformat check rather than a bare regex, so
    a calendar-invalid date (31 February) is refused, not silently
    accepted. render.py's new _dueInCell(r)/editDueIn/saveDueIn mirror
    _retailCell/editRetail/saveRetail exactly, reusing the same .retail-
    wrap/.retail-edit-btn/.retail-flag "M" badge styling, only the input
    itself changes, type="date" instead of type="number", widened from
    80px to 135px so the real date text and the browser's own calendar
    icon both fit without clipping. The real, stored collection_date
    column (whatever the platform itself read) is never touched by an
    override, exactly like retail_estimate never is by its own cap or
    override, so clearing it always reverts to the true last read
    value, or a plain dash if the platform never gave one at all.
    Verified live end to end: GU68XPP's real collection_date (2026-08-
    28) stayed on file untouched in the database while a manual
    override (2026-09-15) took over the page's own display and the
    live /api/purchases response, then Reset correctly reverted to
    2026-08-28 with the override column back to NULL; BU16WZB, a real
    row with no collection_date on file at all ("Not confirmed" in the
    Due in view), correctly took a fresh manual date (2026-09-02) with
    nothing to revert to but the override itself, confirmed via both
    the database directly and a live /api/purchases read. 556 tests
    pass (render only, no gate or pricing logic touched, no dedicated
    new tests, matching the Retail est. work this mirrors).

  - AUTOMATED LOGIN EXTENDED TO AUCTION4CARS, DEALER AUCTION AND LE
    CAPITAL, 2026-08-27 (Mark: "in settings page we need to update DA,
    A4C, LE to use the auto login that DK, Cazana & MW & Carwow use").
    Three new scripts, same keychain based pattern as auto_login_
    carwow.py/cazana.py/motorway.py/dealerkit.py (setup_credential.py
    stores the login once via a hidden getpass prompt, the script reads
    it back at run time via the macOS `security` tool, the password is
    never printed, logged or written anywhere, cleared from memory the
    moment it is typed into the page). setup_credential.py's SITES
    dict gained auction4cars/dealerauction/lecapital's real hostnames.
    - auto_login_auction4cars.py: real fields #username/#password, a
      real `button[type=submit]` reading "Log in", checked live
      2026-08-27. One real thing the other four scripts never had to
      handle: a Termly cookie consent banner visually sits on top of
      the username field (Playwright itself reports the field
      "visible", but a real hit test at its own coordinates lands on
      the banner, not the input), so the script clicks Preferences
      then Decline All first, the same most privacy preserving choice
      this project's own standing rule on cookie banners already
      calls for, confirmed live afterward that the hit test then
      correctly lands on the real field. Verifies success the same
      real way login.py's own existing auto detect for this site
      already does, landing on the real host with either /home or
      /live-auctions in the path.
    - auto_login_lecapital.py: real fields #username/#Password (note
      the capital P, checked live, not a typo), a real button (class
      de-auth-primary-button, type="button" not submit) reading
      "Login". Verifies success the same real way daily_run.
      lecapital_funding_pass() already does, off /auth/login with
      "Displaying all" somewhere in the real page text, LE Capital
      gives no simpler DOM hook for this.
    - auto_login_dealerauction.py, the one with two genuinely
      different, worth remembering things found live: (1) its login
      page sits behind Cloudflare bot management, the very first
      headless attempt with Playwright's own default fingerprint came
      back "Sorry, you have been blocked" (Cloudflare Ray ID and all),
      confirmed live with a plain fetch, not guessed at from a timeout.
      A real desktop Chrome user agent string plus the same
      --disable-blink-features=AutomationControlled flag every other
      script here already passes was enough to get through, proven
      live, still headless, no visible window needed for normal runs.
      (2) bidbrain.browser.py's own SITES entry already documented,
      from the original 2026-08-20 build, "Login has an SMS 2FA step
      sometimes, so the first login... needs Mark actually present". A
      script cannot ever supply a one time SMS code, so this one does
      not try: it watches for a real OTP/code style input appearing
      after submitting the form and, if one shows up, fails loudly
      with a clear message pointing at the existing manual fallback
      (python3 login.py dealerauction manual) rather than hang
      forever waiting on a code nobody can give it. In the testing
      done this session the Cloudflare block was the only real
      obstacle actually hit, never the SMS step, but the safety net is
      there either way. Real fields once past the block: input[type=
      email]/input[type=password], a real submit button (data-testid=
      "login-button", no visible text of its own, an icon only
      button). Verifies success the same real way bidbrain.readers.
      dealerauction.read_live() already does, a real advert link
      (a[analyticslabel="view-advert"]) on the real filtered stock
      list.
    - bidbrain.render._SITE_AUTO (the Settings > Integrations page's
      own map of which sites log themselves back in, and when) gained
      all three at 17:00, alongside Cazana, Carwow and DealerKit's
      existing slot; Motorway stays alone at 06:00 for the reason
      already on record (it shares the persistent browser profile
      every other Motorway read and write depends on, so it has to run
      well clear of the day's own reads, not alongside these three).
      The stale comment above the dict, which used to say Dealer
      Auction "needs a person" because of the SMS step, was corrected
      to say plainly it is now automatic too, with the SMS case
      handled as a loud, safe failure rather than a reason to leave it
      manual.
    - None of the three actually have a stored keychain credential on
      this Mac yet (checked live, `security find-internet-password`
      finds nothing for any of the three hosts), matching the fact
      that no launchd login job exists on this Mac for any of the
      four ALREADY automated sites either, only the code itself. That
      one time setup (running setup_credential.py, then scheduling a
      launchd job the same way com.bidbrain.cazana-login/carwow-login/
      dealerkit-login/motorway-login are documented elsewhere in this
      file) is Mark's own to do when he is ready to actually rely on
      these, this session built and live verified the mechanism, not
      the account level setup.
    - Verified live end to end for what could be verified without a
      real stored credential: every real login form's own field
      selectors and submit control confirmed by direct page inspection
      (not guessed), the Auction4Cars cookie banner dismissal proven to
      genuinely unblock the username field via a real elementFromPoint
      hit test, the Dealer Auction Cloudflare block reproduced then
      proven passable with the fixed user agent. The live Settings >
      Integrations page (restarted com.bidbrain.serve, fetched fresh)
      now shows a real "Auto, 17:00 daily" badge on all three rows,
      confirmed directly in the served HTML; Auction4Cars and Dealer
      Auction both currently show red (a genuine, pre existing read
      failure already on file from before this session, unrelated to
      login), LE Capital shows green (a real, currently healthy
      session from earlier work). 556 tests pass (this whole area is
      live browser automation with no stored account to complete an
      actual login against yet, verified live the way described
      above, matching every other auto_login_*.py script's own
      established pattern, no dedicated unit tests).

  - PLATFORM TOGGLE MOVED OFF THE NAV BAR ONTO REAL AUCTION HOUSE
    LOGOS, WITH THE SORT AND FILTER CONTROLS CONSOLIDATED ONTO THE
    SAME ROW, 2026-08-27 (Mark: "move the current toggle for the
    auction house from the nav bar and move it to where the icon of
    the auction house is, move the amount of cars to the right of the
    new toggle location, use the auction house logos on the toggle",
    then, mid build: "move the filter, ending soonest etc on the same
    line as the toggle"). The plain text All/Motorway/Carwow/
    Auction4Cars/Dealer Auction/DealerWay tabs are gone from the top
    `.controls` bar entirely. New `render._platform_toggle_bar(
    controls_html)` builds the same real tabs (same id="tabs", same
    .tab/data-tab markup, same setTab() JS, zero logic change there)
    but now shown as the real captured platform LOGOS (the same
    `_SECTION_LOGO` dict a section's own heading already used), All
    and DealerWay (no captured logo yet) falling back to plain text
    same as `_platform_heading` already does. Rendered at the very top
    of `.content`, right where a section's own icon used to sit, with
    a live car count pill (`#platcount`) immediately after it, then
    the sort and view dropdown, Cazana price sort, ending soonest sort
    and Filters button (the existing `_section_controls(summary)`,
    passed in rather than built inside the new function since it is
    defined further down the file) sharing the same row.
    - Since the sort/filter controls now live once, they were removed
      from being repeated on every platform section's own heading in
      `_platform_sections`, leaving each `.platset`'s own `.section-
      head` as just the small logo+count divider, still useful when
      All groups more than one platform's cars, otherwise hidden.
    - A REAL BUG CAUGHT LIVE before calling this done, not assumed
      correct from the code alone: the first version wrote `counts.
      all` into the new count, the same tally the sort/view dropdown's
      own "All (N)" option label already used, which deliberately
      IGNORES search, every sidebar filter and the price ceiling (by
      design, so the dropdown always shows a stable potential total).
      That is the wrong figure for a count sitting directly under the
      real cards on screen: with the cockpit's own default price
      ceiling filter pre applied, the toggle read 180 while only 151
      cards were actually visible, caught by comparing `document.
      querySelectorAll('.card')` filtered to genuinely on screen
      cards against the number the toggle showed. Fixed with a new
      `visibleTotal` accumulator inside `applyView()`'s existing per
      section loop (adding each section's own already computed
      `shown`, the real post filter, post search count, plus the held
      section's own `shown` when Held back view is active), written to
      `#platcount` instead. Verified live end to end after the fix:
      Motorway alone read 151, matching all 151 visible cards genuinely
      carrying `data-platform="motorway"`; All read 248, matching the
      real total visible card count at that moment.
    - To avoid showing the same logo twice in a row once a specific
      platform is picked (the new toggle above, highlighted, plus that
      platform's own small per section logo+count divider directly
      below it, now redundant), `setTab()` toggles a new `single-plat`
      class on `#appshell` whenever `currentTab !== 'all'` (a specific
      platform can only ever leave one `.platset` section visible, by
      construction, so this is a safe, simple rule, no counting
      needed), and a new CSS rule (`.single-plat .platset .section-
      head { display:none; }`) hides that now controls free divider
      entirely in that state. `.section-controls` gained `margin-left:
      auto` so it stays pinned to the right of the toggle row. The old
      `.content > .platset:first-of-type .section-head { margin-top:
      0; }` rule (zeroed the very first section's own top margin so it
      lined up with the old sidebar) was removed, no longer needed now
      the new toggle row is genuinely the first thing in `.content`,
      its own real top margin now gives a proper gap below the toggle
      row instead.
    - Verified live end to end in a real browser against the running
      server (restarted com.bidbrain.serve, `daily_run.py --render-
      only` to pick up the change): every logo (Motorway, Carwow,
      Auction4Cars, Dealer Auction) renders as a real, fully loaded
      image (`naturalWidth` confirmed nonzero on each, not just present
      in the markup) inside its own toggle button, DealerWay correctly
      falls back to plain text; clicking Motorway then Carwow correctly
      narrows the grid to real, genuinely matching platform cards (151
      Motorway, 96 Carwow, each confirmed against `data-platform` on
      every visible card), hides the redundant per section divider and
      shows the sort/filter controls alone on their own row, and
      updates the count; clicking All restores every platform, the
      grouped per section dividers and the controls back on the same
      row; confirmed the whole row wraps cleanly rather than
      overflowing at a real 1000px viewport. 556 tests pass (render
      only, no gate or pricing logic touched, no dedicated new tests,
      matching the established pattern for this kind of pure layout
      change).

  - COMFORTABLE/COMPACT MOVED TO ICONS, NEXT TO FILTERS, 2026-08-27
    (Mark: "make the comfortable / compact have icons instead of
    words and move to the right of the filter button"). New
    `render._density_toggle_btns()` (called from `_section_controls`,
    right after `_filters_btn()`, so it now lives on the same
    platform toggle row as Cazana price, Ending soonest and Filters,
    not the top nav bar) replaces the plain text pill (previously its
    own `.tabs.densitytabs` sitting alone on the left of `.controls`,
    now removed from there entirely) with two small icon only
    buttons: three evenly, generously spaced horizontal lines for
    Comfortable, four tightly packed lines for Compact, reading as
    spacious versus dense at a glance the same way this row's other
    icon buttons already do, each carrying its own hover title for
    the word itself. Same `.densitybtn`/`data-density`/`setDensity()`
    JS underneath, zero logic change, only the markup and its
    position moved. Verified live: both icons render with the right
    line counts (3 and 4), the correct one starts highlighted on
    load, clicking Comfortable genuinely sets `cardDensity` and
    re-paints every card, and the empty top nav bar's own actions
    (search, Run now, the icon row) still sit correctly pinned right
    with nothing left of them. 556 tests pass (render only, no gate
    or pricing logic touched, no dedicated new tests, matching the
    established pattern for this kind of pure layout change).