/* =========================
   My PotterForm account page (Phase E1)
   Read-only My Shapes library layout only - built entirely on
   potterform-design-system.css tokens (.potterform-scope), no new
   colour/typography system, no dashboard chrome.
   ========================= */

.pf-account{
  max-width: 960px;
  margin: 0 auto;
  padding: 24px 16px 48px;
  color: var(--pf-color-text);
}

.pf-account-title{
  font-size: 26px;
  margin: 0 0 8px;
}

.pf-account-intro{
  color: var(--pf-text-muted, #625B5F);
  font-size: 15px;
  line-height: 1.5;
  margin: 0 0 20px;
}

.pf-account-login-unavailable{
  color: var(--pf-text-muted, #625B5F);
  font-size: 14px;
}

/* UI-2B: guest login wrapper - only the container PotterForm owns.
   VentraConnect's own widget markup inside .pf-account-login is never
   targeted here (its internal classes are private/unstable, and its
   Google/Magic Link/registration buttons keep whatever styling
   VentraConnect itself gives them) - this only gives the widget a warm,
   framed PotterForm card to sit inside, so it visually belongs to the
   account page instead of floating unstyled on the canvas background. */
.pf-account-login{
  max-width: 480px;
  margin-top: 4px;
  padding: 24px;
  background: var(--pf-white, #FFFDFC);
  border: 1px solid var(--pf-color-primary-border, rgba(110,59,91,0.28));
  border-radius: var(--pf-radius-panel, 20px);
}

.pf-account-section-title{
  font-size: 18px;
  margin: 24px 0 12px;
}

.pf-account-library-nav{
  margin: 0 0 20px;
}

.pf-account-library-tabs{
  display: inline-flex;
  align-items: stretch;
  gap: 0;
  max-width: 100%;
  padding: 3px;
  border: 1px solid var(--pf-color-primary-border, rgba(110,59,91,0.28));
  border-radius: var(--pf-radius-small, 8px);
  background: var(--pf-color-surface-soft, #F4F0F2);
}

.pf-account-library-tab{
  min-height: 44px;
  padding: 9px 14px;
  border: 1px solid transparent;
  border-radius: var(--pf-radius-small, 8px);
  background: transparent !important;
  color: var(--pf-color-text, #2E292C) !important;
  font: inherit;
  font-size: 14px;
  font-weight: 600;
  cursor: pointer;
}

.pf-account-library-tab[aria-selected="true"]{
  border-color: var(--pf-color-primary);
  background: var(--pf-color-primary, #6E3B5B) !important;
  color: #fff !important;
}

.pf-account-library-tab:hover,
.pf-account-library-tab:focus-visible{
  border-color: var(--pf-color-primary);
}

.pf-account-library-tab:focus-visible{
  outline: 2px solid var(--pf-color-focus-ring);
  outline-offset: 2px;
}

.pf-account-library-panel[hidden]{
  display: none;
}

@media (max-width: 480px){
  .pf-account-library-tabs{
    display: flex;
    width: 100%;
  }

  .pf-account-library-tab{
    flex: 1 1 0;
  }
}

.pf-my-shapes-status{
  font-size: 13px;
  color: var(--pf-text-muted, #625B5F);
  min-height: 1.4em;
  margin: 0 0 12px;
}

.pf-my-shapes-grid{
  list-style: none;
  margin: 0;
  padding: 0;
  display: grid;
  grid-template-columns: 1fr;
  gap: 14px;
}

@media (min-width: 641px){
  .pf-my-shapes-grid{
    grid-template-columns: repeat(2, 1fr);
  }
}

@media (min-width: 961px){
  .pf-my-shapes-grid{
    grid-template-columns: repeat(3, 1fr);
  }
}

/* Phase E4: My Shapes -> Compare toolbar --------------------------------- */

.pf-my-shapes-toolbar{
  margin: 0 0 14px;
}

.pf-my-shapes-compare-btn{
  font: inherit;
  font-size: 13px;
  font-weight: 600;
  padding: 8px 14px;
  border-radius: var(--pf-radius-small, 8px);
  border: 1px solid var(--pf-color-primary);
  background: var(--pf-color-primary);
  color: #fff;
  cursor: pointer;
}

/* UI-2B/UI-2B.1/UI-2B-final: staging found these turning theme/browser
   blue on hover. The #pf-account id-scoping alone (UI-2B.1) was verified
   insufficient on live staging - textContent is set directly on each
   interactive element (confirmed in sb-shape-account.js, no nested label
   span to target instead), so the remaining explanation is a runtime rule
   elsewhere (Astra/WordPress/a plugin) winning via !important, which only
   !important on our side can reliably beat. Scoped as narrowly as
   possible: only the `color` property carries !important, only on these
   exact PotterForm-owned selectors, only inside #pf-account - never a
   blanket button/a rule. */
#pf-account .pf-my-shapes-compare-btn:hover:not(:disabled){
  background: var(--pf-color-primary-hover);
  border-color: var(--pf-color-primary-hover);
  color: #fff !important;
}

#pf-account .pf-my-shapes-compare-btn:focus-visible{
  outline: 2px solid var(--pf-color-primary, #6E3B5B);
  outline-offset: 2px;
  color: #fff !important;
}

.pf-my-shapes-compare-btn:disabled{
  opacity: 0.5;
  cursor: default;
}

/* UI-2B: card family convergence with Archive/Single Shape - warm white
   surface, soft Plum-family border (the same --pf-color-primary-border
   token Archive/Single now use for their own cards/panels) and the shared
   panel radius token. Padding/gaps stay compact - the density difference
   from Archive comes from sizing, not from a different visual family. */
.pf-my-shape-card{
  border: 1px solid var(--pf-color-primary-border, rgba(110,59,91,0.28));
  border-radius: var(--pf-radius-panel, 20px);
  background: var(--pf-white, #FFFDFC);
  padding: 12px;
  display: flex;
  flex-direction: column;
  gap: 8px;
  transition: box-shadow .16s cubic-bezier(.22,1,.36,1);
}

/* Restrained hover, same shadow language as Archive's card hover - no
   translateY/scale. */
.pf-my-shape-card:hover{
  box-shadow: 0 4px 12px var(--pf-color-primary-soft-active, rgba(110,59,91,0.13));
}

/* Phase E4: selected state - never colour alone (the checkbox itself stays
   the primary indicator); border + a faint background wash on the card
   reinforce it without a redesign of the card itself. */
.pf-my-shape-card--selected{
  border-color: var(--pf-color-primary);
  background: var(--pf-color-primary-soft);
}

.pf-my-shape-card-select{
  display: flex;
  align-items: center;
  gap: 6px;
  font-size: 12px;
  color: var(--pf-color-text-soft);
  cursor: pointer;
}

.pf-my-shape-card-select-input{
  width: 16px;
  height: 16px;
  accent-color: var(--pf-color-primary);
  cursor: pointer;
  margin: 0;
}

.pf-my-shape-card-select-input:focus-visible{
  outline: 2px solid var(--pf-color-focus-ring);
  outline-offset: 2px;
}

.pf-my-shape-card-select-input:disabled{
  cursor: default;
}

.pf-my-shape-card-select-text{
  user-select: none;
}

/* UI-2B: the silhouette previously rendered edge-to-edge in this box (the
   svg is width:100%/height:100% of the content box below) - adding
   padding here shrinks that content box instead of touching the svg or
   its preserveAspectRatio="xMidYMid meet" behaviour, so the silhouette
   gets ~10px of breathing room on every side without ever being
   stretched, cropped, or resized itself. The 120px outer height is
   unchanged - this is framing, not a larger box. */
.pf-my-shape-card-preview{
  display: flex;
  align-items: center;
  justify-content: center;
  height: 120px;
  padding: 10px;
  box-sizing: border-box;
  background: var(--pf-color-background);
  border: 1px solid var(--pf-color-border);
  border-radius: var(--pf-radius-small, 8px);
  overflow: hidden;
}

.pf-my-shape-card-preview-svg{
  width: 100%;
  height: 100%;
}

.pf-my-shape-card-preview-path{
  fill: none;
  stroke: var(--pf-color-shape);
  stroke-width: 2;
  vector-effect: non-scaling-stroke;
}

/* Staging polish: My Lid thumbnails' Inner wall - thin/dashed/subdued,
   clearly secondary to the solid 2px .pf-my-shape-card-preview-path above,
   mirroring the same thin/dashed/subdued convention
   .sb-sg-lid-assembly-inner already established for the Lid Inner on the
   main Generator canvas. Shared by both consumers of this SVG (the
   Generator's own My Lids picker cards and the Account My Lids cards),
   since both build through the same NS.lidPreviewV1.buildLidPreviewSvg(). */
.pf-my-shape-card-preview-inner-path{
  fill: none;
  stroke: var(--pf-color-shape);
  stroke-width: 1;
  stroke-dasharray: 3 2;
  opacity: .6;
  vector-effect: non-scaling-stroke;
}

.pf-my-shape-card-preview-placeholder{
  width: 40%;
  height: 40%;
  border-radius: 6px;
  background: var(--pf-color-border);
}

.pf-my-set-card-preview{
  height: 120px;
  display: flex;
  align-items: flex-end;
  justify-content: center;
  gap: 8px;
  padding: 12px;
  box-sizing: border-box;
  background: var(--pf-color-background);
  border: 1px solid var(--pf-color-border);
  border-radius: var(--pf-radius-small, 8px);
  overflow: hidden;
}

.pf-my-set-card-preview svg{
  width: 28%;
  height: 100%;
}

.pf-my-set-card-preview path{
  fill: none;
  stroke: var(--pf-color-shape);
  stroke-width: 2;
}

.pf-my-set-card-placeholder{
  color: var(--pf-color-text-faint);
  font-size: 12px;
}

.pf-my-shape-card-name{
  font-weight: 600;
  font-size: 14px;
  line-height: 1.3;
  word-break: break-word;
}

.pf-my-shape-card-meta{
  font-size: 12px;
  color: var(--pf-color-text-faint);
}

/* Phase E2: management actions ------------------------------------------ */

.pf-my-shape-card-body{
  display: flex;
  flex-direction: column;
  gap: 4px;
}

.pf-my-shape-card-rename-form{
  display: flex;
  flex-direction: column;
  gap: 6px;
  margin-top: 4px;
}

/* The unconditional display: flex above has the same specificity as the
   browser's native [hidden]{display:none} rule, and an author rule beats a
   UA rule on a specificity tie - so without this override, setting
   .hidden = true in JS left the (empty) rename form visibly on screen at
   the same time as the normal action row. Scoped to just this selector
   rather than a global [hidden] rule, to avoid touching hidden behavior
   anywhere else on the page. */
.pf-my-shape-card-rename-form[hidden]{
  display: none;
}

.pf-my-shape-card-rename-input{
  font: inherit;
  font-size: 14px;
  padding: 6px 8px;
  border: 1px solid var(--pf-color-border-strong);
  border-radius: var(--pf-radius-small, 8px);
  color: var(--pf-color-text);
  background: var(--pf-color-background);
  width: 100%;
  box-sizing: border-box;
}

.pf-my-shape-card-rename-input:focus-visible{
  outline: 2px solid var(--pf-color-focus-ring);
  outline-offset: 1px;
}

.pf-my-shape-card-actions,
.pf-my-shape-card-rename-actions{
  display: flex;
  flex-wrap: wrap;
  gap: 6px;
  margin-top: 4px;
}

/* Same [hidden]-vs-author-display conflict as the rename form above - the
   normal action row must actually leave the layout when hidden = true. */
.pf-my-shape-card-actions[hidden]{
  display: none;
}

/* Phase E3: My Shapes -> Open - the card's primary action, styled more
   prominently than the secondary Rename/Duplicate/Delete row below it. */
.pf-my-shape-card-open{
  display: block;
  text-align: center;
  font: inherit;
  font-size: 13px;
  font-weight: 600;
  padding: 8px 10px;
  border-radius: var(--pf-radius-small, 8px);
  border: 1px solid var(--pf-color-primary);
  background: var(--pf-color-primary);
  color: #fff;
  text-decoration: none;
  margin-top: 4px;
  cursor: pointer;
}

/* WordPress theme link colour rules can outrank the card class at rest.
   Override only the text colour here so the existing [hidden], busy,
   hover, and focus states retain their established cascade. */
#pf-account .pf-my-shape-card-open{
  color: #fff !important;
}

/* Open is a real <a> (see sb-shape-account.js's openEl =
   document.createElement("a"), textContent set directly - no nested label
   to target instead) - see the compare-btn comment above for the full
   !important reasoning. Rest state (color:#fff above) was never reported
   broken on staging, so it stays unescalated; only hover/focus-visible
   need it. */
#pf-account .pf-my-shape-card-open:hover{
  background: var(--pf-color-primary-hover);
  border-color: var(--pf-color-primary-hover);
  color: #fff !important;
}

#pf-account .pf-my-shape-card-open:focus-visible{
  outline: 2px solid var(--pf-color-primary, #6E3B5B);
  outline-offset: 2px;
  color: #fff !important;
}

/* aria-disabled while a Rename/Duplicate/Delete action on this same card is
   in flight (setCardBusy()) - real anchors have no native `disabled`.
   pointer-events: none blocks mouse activation at the browser level; the
   matching JS click guard in buildCardNode() blocks keyboard/programmatic
   activation, which pointer-events cannot. */
.pf-my-shape-card-open[aria-disabled="true"]{
  opacity: 0.5;
  cursor: default;
  pointer-events: none;
}

/* Same [hidden]-vs-author-display conflict as the rename form/actions row
   above (E2.1) - the primary Open action must actually leave the layout in
   rename mode, not just visually disappear. */
.pf-my-shape-card-open[hidden]{
  display: none;
}

/* UI-2B: Rename/Duplicate stay the lowest routine-emphasis tier (tertiary)
   - a quiet Plum-family border at rest (matching the card border language)
   rather than the previous neutral grey, turning fully Plum on hover. */
.pf-my-shape-card-action,
.pf-my-shape-card-rename-save,
.pf-my-shape-card-rename-cancel{
  font: inherit;
  font-size: 12px;
  font-weight: 600;
  padding: 6px 10px;
  border-radius: var(--pf-radius-small, 8px);
  border: 1px solid var(--pf-color-primary-border, rgba(110,59,91,0.28));
  background: var(--pf-color-background);
  color: var(--pf-color-text-soft);
  cursor: pointer;
}

/* Rename/Duplicate/Cancel are real <button> elements (see
   sb-shape-account.js) - #pf-account scoping alone was verified
   insufficient on live staging (still theme blue), so `color` also
   carries !important here - see the compare-btn comment above for the
   full reasoning. Once one rule in this cascade uses !important on a
   property, every rule that must still be able to override it (Delete,
   below) needs !important on that same property too, or it would lose
   even at matching/higher specificity - !important comparisons ignore
   normal specificity entirely except as an important-vs-important
   tiebreak.

   Live computed-style evidence (UI-2B final correction) showed `color`
   was already correctly Plum (rgb(110,59,91)) - the actual remaining
   leak was `background` (rgb(4,92,180), Astra's own button:hover
   background), which this rule never set at all, so it fell straight
   through to the theme default. background-image:none guards against
   the same theme rule instead supplying a gradient. rename-save (a
   filled-Plum button, also named in this group) keeps its own later,
   equally-important background override further below, which still
   correctly wins by source order. */
#pf-account .pf-my-shape-card-action:hover,
#pf-account .pf-my-shape-card-rename-save:hover,
#pf-account .pf-my-shape-card-rename-cancel:hover{
  border-color: var(--pf-color-primary-border);
  color: var(--pf-color-primary) !important;
  background: var(--pf-color-primary-soft-hover, rgba(110,59,91,.05)) !important;
  background-image: none !important;
}

#pf-account .pf-my-shape-card-action:focus-visible,
#pf-account .pf-my-shape-card-rename-save:focus-visible,
#pf-account .pf-my-shape-card-rename-cancel:focus-visible{
  outline: 2px solid var(--pf-color-primary, #6E3B5B);
  outline-offset: 2px;
  color: var(--pf-color-primary) !important;
  background: var(--pf-color-primary-soft-hover, rgba(110,59,91,.05)) !important;
  background-image: none !important;
}

.pf-my-shape-card-action:disabled,
.pf-my-shape-card-rename-save:disabled,
.pf-my-shape-card-rename-cancel:disabled{
  opacity: 0.5;
  cursor: default;
}

.pf-my-shape-card-delete{
  color: var(--pf-color-error);
  border-color: var(--pf-color-error-border);
}

/* Must stay #pf-account-scoped with a matching !important on `color` like
   .pf-my-shape-card-action:hover above - Delete carries both classes, and
   the shared action:hover rule's color is now !important, so without an
   equally-important, correctly-ordered override here Delete would lose
   its red hover entirely and turn Plum instead of staying destructive. */
/* background now needs !important too - the shared action/rename-save/
   rename-cancel :hover group above now sets background !important as
   well (the UI-2B final correction), so without a matching !important
   here Delete's own error-soft background would lose the tie and show
   the Plum soft-hover wash instead of staying destructive red. */
#pf-account .pf-my-shape-card-delete:hover{
  background: var(--pf-color-error-soft) !important;
  color: var(--pf-color-error-hover) !important;
  border-color: var(--pf-color-error-border);
}

/* Restored-focus completion: the shared action:focus-visible rule above
   also matches Delete (it carries both classes) and sets background and
   outline to the neutral Plum treatment with !important - only `color`
   was overridden here before, so a keyboard/programmatic focus restored
   to Delete (e.g. after cancelling the Delete confirmation dialog) still
   showed a Plum/theme-default background and outline instead of staying
   in the destructive red family. Mirrors .pf-my-shape-card-delete:hover
   above, plus its own outline override. */
#pf-account .pf-my-shape-card-delete:focus-visible{
  background: var(--pf-color-error-soft) !important;
  color: var(--pf-color-error-hover) !important;
  border-color: var(--pf-color-error-border);
  background-image: none !important;
  outline: 2px solid var(--pf-color-error, #AA1111);
  outline-offset: 2px;
}

.pf-my-shape-card-rename-save{
  background: var(--pf-color-primary);
  border-color: var(--pf-color-primary);
  color: #fff;
}

/* rename-save is also named inside the shared action/rename-save/
   rename-cancel :hover group above (a filled-Plum "Save" button sharing
   the same tertiary hover selector as neutral Rename/Duplicate/Cancel) -
   now that that shared rule's `color` is !important, this standalone rule
   needs !important too, or the shared rule's Plum text would win over
   this white text on Plum background and become unreadable. */
/* background now needs !important too, matching the color fix already
   here - the shared action/rename-save/rename-cancel :hover group above
   now sets background !important as well (the UI-2B final correction),
   so without a matching !important here this rule's own background
   would lose the tie and rename-save would show the soft-hover wash
   instead of solid Plum-hover. */
#pf-account .pf-my-shape-card-rename-save:hover{
  background: var(--pf-color-primary-hover) !important;
  border-color: var(--pf-color-primary-hover);
  color: #fff !important;
}

.pf-my-shapes-empty{
  grid-column: 1 / -1;
  list-style: none;
  color: var(--pf-text-muted, #625B5F);
  font-size: 14px;
  line-height: 1.5;
}

.pf-my-shapes-empty p{
  margin: 0 0 6px;
}

/* Phase E2: shared Delete confirmation dialog ---------------------------- */

.pf-delete-confirm-dialog{
  border: none;
  border-radius: var(--pf-radius-panel, 20px);
  padding: 20px;
  max-width: 360px;
  width: calc(100% - 32px);
  box-shadow: 0 12px 32px rgba(17, 17, 17, 0.18);
  color: var(--pf-color-text);
  font-family: var(--pf-font-family);
}

.pf-delete-confirm-dialog::backdrop{
  background: rgba(17, 17, 17, 0.45);
}

.pf-delete-confirm-heading{
  font-size: 17px;
  margin: 0 0 8px;
}

.pf-delete-confirm-message{
  font-size: 14px;
  color: var(--pf-color-text-soft);
  line-height: 1.5;
  margin: 0 0 18px;
  word-break: break-word;
}

.pf-delete-confirm-actions{
  display: flex;
  justify-content: flex-end;
  gap: 8px;
}

.pf-delete-confirm-cancel,
.pf-delete-confirm-delete{
  font: inherit;
  font-size: 13px;
  font-weight: 600;
  padding: 8px 14px;
  border-radius: var(--pf-radius-small, 8px);
  cursor: pointer;
}

.pf-delete-confirm-cancel{
  border: 1px solid var(--pf-color-border-strong);
  background: var(--pf-color-background);
  color: var(--pf-color-text);
}

/* Shared Delete confirmation dialog (My Sets and My Shapes both use it -
   see sb-shape-account-my-sets.js and sb-shape-account.js). This rule was
   never given the #pf-account scope + !important treatment
   .pf-my-shape-card-action:hover above already needed to beat the theme's
   own (Astra) blue button:hover/:focus-visible styling, so Cancel here
   still showed theme blue instead of the neutral Plum treatment. */
#pf-account .pf-delete-confirm-cancel:hover,
#pf-account .pf-delete-confirm-cancel:focus-visible{
  border-color: var(--pf-color-primary-border);
  color: var(--pf-color-primary) !important;
  background: var(--pf-color-primary-soft-hover, rgba(110,59,91,.05)) !important;
  background-image: none !important;
}

#pf-account .pf-delete-confirm-cancel:focus-visible{
  outline: 2px solid var(--pf-color-primary, #6E3B5B);
  outline-offset: 2px;
}

.pf-delete-confirm-delete{
  border: 1px solid var(--pf-color-error);
  background: var(--pf-color-error);
  color: #fff;
}

/* Same theme-override reasoning as Cancel above, staying in the
   destructive red family (never Plum, never theme blue) on hover and
   focus-visible alike. */
#pf-account .pf-delete-confirm-delete:hover,
#pf-account .pf-delete-confirm-delete:focus-visible{
  background: var(--pf-color-error-hover) !important;
  border-color: var(--pf-color-error-hover);
  color: #fff !important;
  background-image: none !important;
}

#pf-account .pf-delete-confirm-delete:focus-visible{
  outline: 2px solid var(--pf-color-error, #AA1111);
  outline-offset: 2px;
}

/* ==========================================================================
   Shared PotterForm account button state system - staging hardening pass
   (2026-08-26)
   ==========================================================================
   Staging evidence (screenshot) showed the Delete Set? dialog's Cancel
   button still rendering blue (background AND hover/focus), despite the
   #pf-account-scoped !important fix above, and My Set/My Shapes card
   Delete still not reliably staying red after focus is restored following
   a cancelled Delete. Two gaps in the prior fix, addressed together here
   rather than as further one-off patches:

   1. Every prior #pf-account-scoped override above hardens only :hover
      and :focus-visible - never plain REST state. A statically screenshotted
      button (not actively hovered/focused) still falls through to
      whatever the theme (Astra) supplies at rest. This block hardens REST
      too, for every neutral/destructive account button.
   2. The prior fix assumed #pf-account .selector ancestor scoping is
      reliably enough specificity/leverage on its own. As a deliberate,
      narrow, ancestor-INDEPENDENT safety net (in case a native <dialog>
      is ever reparented by an unrelated script - e.g. a dialog polyfill -
      to somewhere no longer a descendant of #pf-account), the Delete
      confirmation dialog's own button classes are also self-doubled
      (.pf-delete-confirm-cancel.pf-delete-confirm-cancel) so the rule
      still wins purely on the button's own class, without depending on
      any ancestor relationship at all. #pf-account.pf-account (both the
      id and the class already on that one real container element - never
      a synthetic double-id hack) is used everywhere else for the same
      specificity margin.

   Every colour-bearing property a generic theme button reset is
   realistically able to set is covered explicitly and !important:
   background, background-color, background-image, border-color, color,
   box-shadow. :focus is hardened alongside :focus-visible specifically
   for the two destructive Delete buttons and their paired Cancel/neutral
   buttons, because the focus a dialog's Cancel/close handler restores via
   a script-driven .focus() call after a mouse-driven Cancel click is not
   guaranteed to satisfy :focus-visible heuristics in every browser - if it
   doesn't, only a plain :focus rule can still guarantee the required
   accessible, correctly-coloured focus state ("must still render
   destructive red... never silently fall back to neutral/Plum").

   This block is purely additive - every existing rule above is left in
   place - and is placed last so it also wins any same-specificity/
   !important source-order tie against everything before it.

   NEUTRAL:     .pf-my-shape-card-action, .pf-my-shape-card-rename-cancel,
                .pf-delete-confirm-cancel
   DESTRUCTIVE: .pf-my-shape-card-delete, .pf-delete-confirm-delete
   ========================================================================== */

/* NEUTRAL - rest */
#pf-account.pf-account .pf-my-shape-card-action,
#pf-account.pf-account .pf-my-shape-card-rename-cancel{
  background: var(--pf-color-background, #ffffff) !important;
  background-color: var(--pf-color-background, #ffffff) !important;
  background-image: none !important;
  border-color: var(--pf-color-primary-border, rgba(110,59,91,0.28)) !important;
  color: var(--pf-color-text-soft, rgba(17,17,17,0.72)) !important;
  box-shadow: none !important;
}
.pf-delete-confirm-cancel.pf-delete-confirm-cancel,
#pf-account.pf-account .pf-delete-confirm-cancel{
  background: var(--pf-color-background, #ffffff) !important;
  background-color: var(--pf-color-background, #ffffff) !important;
  background-image: none !important;
  border-color: var(--pf-color-border-strong, rgba(17,17,17,0.12)) !important;
  color: var(--pf-color-text, #111111) !important;
  box-shadow: none !important;
}

/* NEUTRAL - hover */
#pf-account.pf-account .pf-my-shape-card-action:hover,
#pf-account.pf-account .pf-my-shape-card-rename-cancel:hover,
.pf-delete-confirm-cancel.pf-delete-confirm-cancel:hover,
#pf-account.pf-account .pf-delete-confirm-cancel:hover{
  background: var(--pf-color-primary-soft-hover, rgba(110,59,91,.05)) !important;
  background-color: var(--pf-color-primary-soft-hover, rgba(110,59,91,.05)) !important;
  background-image: none !important;
  border-color: var(--pf-color-primary-border, rgba(110,59,91,0.28)) !important;
  color: var(--pf-color-primary, #6E3B5B) !important;
  box-shadow: none !important;
}

/* NEUTRAL - keyboard focus (:focus-visible) and script-restored focus
   (:focus) alike - see the header comment above for why both are needed. */
#pf-account.pf-account .pf-my-shape-card-action:focus-visible,
#pf-account.pf-account .pf-my-shape-card-action:focus,
#pf-account.pf-account .pf-my-shape-card-rename-cancel:focus-visible,
#pf-account.pf-account .pf-my-shape-card-rename-cancel:focus,
.pf-delete-confirm-cancel.pf-delete-confirm-cancel:focus-visible,
.pf-delete-confirm-cancel.pf-delete-confirm-cancel:focus,
#pf-account.pf-account .pf-delete-confirm-cancel:focus-visible,
#pf-account.pf-account .pf-delete-confirm-cancel:focus{
  background: var(--pf-color-primary-soft-hover, rgba(110,59,91,.05)) !important;
  background-color: var(--pf-color-primary-soft-hover, rgba(110,59,91,.05)) !important;
  background-image: none !important;
  border-color: var(--pf-color-primary-border, rgba(110,59,91,0.28)) !important;
  color: var(--pf-color-primary, #6E3B5B) !important;
  outline: 2px solid var(--pf-color-primary, #6E3B5B) !important;
  outline-offset: 2px;
  box-shadow: none !important;
}

/* DESTRUCTIVE - rest (card Delete stays an outlined/tertiary red hook;
   dialog Delete stays the filled/primary red CTA - same established
   visual language as before, only now hardened). */
#pf-account.pf-account .pf-my-shape-card-delete{
  background: var(--pf-color-background, #ffffff) !important;
  background-color: var(--pf-color-background, #ffffff) !important;
  background-image: none !important;
  border-color: var(--pf-color-error-border, rgba(170,17,17,0.35)) !important;
  color: var(--pf-color-error, #AA1111) !important;
  box-shadow: none !important;
}
.pf-delete-confirm-delete.pf-delete-confirm-delete,
#pf-account.pf-account .pf-delete-confirm-delete{
  background: var(--pf-color-error, #AA1111) !important;
  background-color: var(--pf-color-error, #AA1111) !important;
  background-image: none !important;
  border-color: var(--pf-color-error, #AA1111) !important;
  color: #fff !important;
  box-shadow: none !important;
}

/* DESTRUCTIVE - hover */
#pf-account.pf-account .pf-my-shape-card-delete:hover{
  background: var(--pf-color-error-soft, rgba(170,17,17,.06)) !important;
  background-color: var(--pf-color-error-soft, rgba(170,17,17,.06)) !important;
  background-image: none !important;
  border-color: var(--pf-color-error-border, rgba(170,17,17,0.35)) !important;
  color: var(--pf-color-error-hover, #8A0E0E) !important;
  box-shadow: none !important;
}
.pf-delete-confirm-delete.pf-delete-confirm-delete:hover,
#pf-account.pf-account .pf-delete-confirm-delete:hover{
  background: var(--pf-color-error-hover, #8A0E0E) !important;
  background-color: var(--pf-color-error-hover, #8A0E0E) !important;
  background-image: none !important;
  border-color: var(--pf-color-error-hover, #8A0E0E) !important;
  color: #fff !important;
  box-shadow: none !important;
}

/* DESTRUCTIVE - keyboard focus (:focus-visible) and script-restored focus
   (:focus) alike. This is the exact "card Delete -> dialog -> Cancel ->
   focus returns to card Delete" path from the staging report: it must
   stay destructive red here regardless of which focus pseudo-class the
   browser actually applies for a script-driven .focus() call. */
#pf-account.pf-account .pf-my-shape-card-delete:focus-visible,
#pf-account.pf-account .pf-my-shape-card-delete:focus{
  background: var(--pf-color-error-soft, rgba(170,17,17,.06)) !important;
  background-color: var(--pf-color-error-soft, rgba(170,17,17,.06)) !important;
  background-image: none !important;
  border-color: var(--pf-color-error-border, rgba(170,17,17,0.35)) !important;
  color: var(--pf-color-error-hover, #8A0E0E) !important;
  outline: 2px solid var(--pf-color-error, #AA1111) !important;
  outline-offset: 2px;
  box-shadow: none !important;
}
.pf-delete-confirm-delete.pf-delete-confirm-delete:focus-visible,
.pf-delete-confirm-delete.pf-delete-confirm-delete:focus,
#pf-account.pf-account .pf-delete-confirm-delete:focus-visible,
#pf-account.pf-account .pf-delete-confirm-delete:focus{
  background: var(--pf-color-error-hover, #8A0E0E) !important;
  background-color: var(--pf-color-error-hover, #8A0E0E) !important;
  background-image: none !important;
  border-color: var(--pf-color-error-hover, #8A0E0E) !important;
  color: #fff !important;
  outline: 2px solid var(--pf-color-error, #AA1111) !important;
  outline-offset: 2px;
  box-shadow: none !important;
}

/* =========================
   VentraConnect visual integration (UI-2B-final)
   Colour/typography overrides for the guest My PotterForm login surface.
   VentraConnect's own plugin source is never modified - these selectors
   and its --vcs-* variable API were provided directly from live staging
   outerHTML/CSS capture, not guessed.

   Architecture (branding bridge): three escalating pure-CSS attempts on
   the Magic Link entry button's background were each proven, on live
   staging, to still lose the runtime cascade - up to and including a
   selector matching every class/attribute VentraConnect's own markup
   carries. element.style.setProperty(prop, value, 'important') on the
   live element won immediately, proving this was a pure stylesheet-vs-
   stylesheet specificity problem, not a plugin/license lock. Rather than
   escalate CSS specificity indefinitely, Assets/sb-shape-account-branding.js
   (a small, guest-only, visual-only runtime module - see its own docblock;
   never touches OAuth/Magic Link/Google auth requests, tokens, or session
   state) now owns the Magic Link entry button's and the modal's Send Link
   button's background/colour/--vcs-* boundary directly, at runtime,
   reading PotterForm's own --pf-* tokens via getComputedStyle() rather
   than hardcoding colours. The CSS below therefore keeps only what still
   has a clear, non-conflicting role: layout (border-radius, border
   width/style), typography (font-weight), the Magic Link icon's fill
   (never proven contested the way the button background was),
   :focus-visible outlines, the modal input (never proven contested), and
   the modal's top-accent pseudo-element (gated behind the .pf-vcs-branded
   class the branding bridge adds once it has run, so these rules never
   fire before branding is actually in place). The modal card and close
   control were added to the JS boundary in the UI-2B FINAL Modal
   Branding Fix pass, after live staging showed both still carrying
   VentraConnect's own blue despite this file's earlier colour-only
   overrides for them - see Assets/sb-shape-account-branding.js's
   brandModalCard()/brandModalClose().

   The Magic Link modal (.vcsl-auth-modal) is NOT scoped under
   .pf-account-login below - VentraConnect may render it outside that
   wrapper in the DOM (e.g. appended elsewhere), so .vcsl-auth-modal
   itself (the modal's own plugin-specific root, not the generic
   .vcs-modal framework class) is the correct, sufficiently narrow scope
   on its own. No bare .vcs-btn, .button-primary, .vcs-modal, or input
   selector is ever written outside these scopes. No position/size/
   dimension/animation property is touched anywhere in this section.
   ========================= */

/* ---- Magic Link entry button (background/colour owned by the branding
   bridge JS - see Assets/sb-shape-account-branding.js) --------------- */

.pf-account-login .vcs-btn--magic-link[data-provider="magic_link"]{
  font-weight: 600;
  border-radius: 12px;
}

.pf-account-login .vcs-btn--magic-link[data-provider="magic_link"] .vcs-btn__label{
  color: #fff !important;
}

/* VentraConnect's supplied inline SVG uses fill="#000000" on its own
   <path> elements - never rewritten here, only recoloured via CSS, and
   only within this exact Magic Link selector, which requires both
   .vcs-btn--magic-link and [data-provider="magic_link"] - Google's own
   button (.vcs-btn[data-provider="google"] below) can never match either
   condition, so the icon-recolour and the "never touch Google's logo"
   requirement cannot conflict by construction. Never duplicated in the
   branding bridge JS either - see that file's own comment. */
.pf-account-login .vcs-btn--magic-link[data-provider="magic_link"] svg path{
  fill: #fff !important;
}

.pf-account-login .vcs-btn--magic-link[data-provider="magic_link"]:focus-visible{
  outline: 2px solid var(--pf-color-primary, #6E3B5B);
  outline-offset: 2px;
}

.pf-account-login .vcs-btn--magic-link[data-provider="magic_link"]:active{
  transform: translateY(1px);
}

/* ---- Google entry button - surrounding control only, logo untouched --- */

.pf-account-login .vcs-btn[data-provider="google"]{
  --vcs-bg: var(--pf-white, #FFFDFC);
  --vcs-bg-hover: var(--pf-color-primary-soft-hover, rgba(110,59,91,.05));
  --vcs-fg: var(--pf-ink, #2B2729);
  --vcs-border: var(--pf-color-primary-border, rgba(110,59,91,.28));
  --vcs-radius: 12px;
  background: var(--pf-white, #FFFDFC) !important;
  background-image: none !important;
  border-color: var(--pf-color-primary-border, rgba(110,59,91,0.28)) !important;
  color: var(--pf-ink, #2B2729) !important;
}

.pf-account-login .vcs-btn[data-provider="google"] .vcs-btn__label{
  color: var(--pf-ink, #2B2729) !important;
}

/* No svg/path rule here at all, anywhere in this file - Google's
   multicolour logo fills are never targeted, satisfying "DO NOT recolor
   Google's SVG paths/logo" by construction, not just by intent. */

.pf-account-login .vcs-btn[data-provider="google"]:hover{
  background: var(--pf-color-primary-soft-hover, rgba(110,59,91,.05)) !important;
  background-image: none !important;
  border-color: var(--pf-color-primary, #6E3B5B) !important;
}

.pf-account-login .vcs-btn[data-provider="google"]:focus-visible{
  outline: 2px solid var(--pf-color-primary, #6E3B5B);
  outline-offset: 2px;
}

/* ---- Magic Link modal (.vcsl-auth-modal) ------------------------------- */

/* Background/background-color/background-image/border-color are owned by
   the branding bridge JS (Assets/sb-shape-account-branding.js's
   brandModalCard()) - a direct-style-vs-runtime-cascade boundary was
   already proven necessary for Magic Link/Send Link, and live staging
   showed the same cool/bluish cast surviving this rule's own !important,
   so the card gets the same JS boundary now. Only border geometry
   (width/style) and radius stay here, so the border actually renders -
   JS supplies only its colour. */
.vcsl-auth-modal .vcs-modal__card{
  border-style: solid;
  border-width: 1px;
  border-radius: var(--pf-radius-panel, 20px);
}

/* The top-accent line is a decorative pseudo-element somewhere in the
   modal's own markup, and VentraConnect's CSS is not vendored in this
   repo, so its owner cannot be read from source. The branding bridge JS
   (see markAccentOwner() in sb-shape-account-branding.js) inspects the
   likely owners' actual computed ::before/::after at runtime and adds
   exactly one of these marker classes to whichever one is really
   rendering it - never a guessed selector. Gated behind .pf-vcs-branded
   (added by brandModal()) so neither rule can fire before branding has
   actually run. Colour/background only, no content/position/size/
   radius/transform - the detected pseudo-element's own geometry is never
   touched. */
.vcsl-auth-modal.pf-vcs-branded .pf-vcs-accent-before::before{
  background: var(--pf-color-primary, #6E3B5B) !important;
  background-image: none !important;
  border-color: var(--pf-color-primary, #6E3B5B) !important;
}

.vcsl-auth-modal.pf-vcs-branded .pf-vcs-accent-after::after{
  background: var(--pf-color-primary, #6E3B5B) !important;
  background-image: none !important;
  border-color: var(--pf-color-primary, #6E3B5B) !important;
}

/* Detection was broadened to also match border-image-based accents (see
   markAccentOwner() in sb-shape-account-branding.js) - neutralised here
   too, alongside background-image, so a detected border-image can never
   survive next to the solid Plum background/border-color above. */
.vcsl-auth-modal.pf-vcs-branded .pf-vcs-accent-before::before,
.vcsl-auth-modal.pf-vcs-branded .pf-vcs-accent-after::after{
  border-image-source: none !important;
}

/* "Link active for 09:58" countdown - the time itself was still rendering
   VentraConnect's own blue on live staging. Colour only: padding,
   dimensions, and the countdown's own JS timing are untouched. */
.vcsl-auth-modal .vcs-countdown{
  border-color: var(--pf-color-primary-border, rgba(110,59,91,.28)) !important;
  background: var(--pf-white, #FFFDFC) !important;
  background-color: var(--pf-white, #FFFDFC) !important;
}

.vcsl-auth-modal .vcs-countdown__time{
  color: var(--pf-color-primary, #6E3B5B) !important;
}

/* Background/background-color/background-image/border-color/color are
   owned by the branding bridge JS (brandModalClose()) - live staging
   showed the close control's background staying VentraConnect's own
   blue despite this file's earlier colour-only override, the same
   cascade problem already proven for Magic Link/Send Link/the card
   above. Only the focus-visible outline (never proven contested) stays
   CSS-owned. */
.vcsl-auth-modal .vcs-modal__close:focus-visible{
  outline: 2px solid var(--pf-color-primary, #6E3B5B);
  outline-offset: 2px;
}

/* "Send link" - background/colour/--vcs-* owned by the branding bridge JS
   (Assets/sb-shape-account-branding.js's brandModalSendLink(), applied
   once when the modal is detected), matching Magic Link's entry-button
   treatment - a submit button rendered by the same plugin, so assumed to
   need the same runtime boundary rather than waiting for a second proven-
   broken report. Narrowly scoped under both .vcsl-auth-modal and
   .vcs-form--magic, so this remaining CSS is never a bare .button-primary
   override (WordPress core's own generic button class) despite reusing
   that exact class name from the provided markup. */
.vcsl-auth-modal .vcs-form--magic .button-primary{
  font-weight: 600;
  border-radius: 12px;
}

.vcsl-auth-modal .vcs-form--magic .button-primary:focus-visible{
  outline: 2px solid var(--pf-color-primary, #6E3B5B);
  outline-offset: 2px;
}

.vcsl-auth-modal .vcs-form--magic .button-primary:active{
  transform: translateY(1px);
}

/* Email input - rest-state border deliberately left alone ("existing
   neutral border at rest" per spec); only focus-visible gets the shared
   PotterForm focus treatment. No form semantics touched. */
.vcsl-auth-modal .vcs-form--magic input:focus-visible{
  border-color: var(--pf-color-primary, #6E3B5B) !important;
  outline: 2px solid var(--pf-color-primary, #6E3B5B);
  outline-offset: 1px;
}

/* ---- Magic Link cross-tab completion banner (roadmap step 10b, Section
   9.10) ---------------------------------------------------------------
   A small, transient notice inserted at the top of #pf-account only when
   this authenticated pageview is a same-browser Magic Link callback that
   an actively-waiting original tab has already acknowledged (see
   Assets/sb-shape-account-auth-ux.js's showCompletionBanner()) - never
   rendered server-side, never a new template. Colour/surface only, using
   the same shared tokens the rest of this file already relies on - no
   blue, no position/animation. */
#pf-account .pf-auth-complete-banner{
  margin: 0 0 16px;
  padding: 10px 14px;
  background: var(--pf-white, #FFFDFC);
  border: 1px solid var(--pf-color-primary-border, rgba(110,59,91,0.28));
  border-left: 3px solid var(--pf-color-primary, #6E3B5B);
  border-radius: var(--pf-radius-small, 8px);
  color: var(--pf-ink, #2B2729);
  font-size: 14px;
  line-height: 1.5;
}