/*
  Base token foundation, per DESIGN.md's YAML frontmatter (colors,
  typography, rounded, spacing). Established here in Story 1.1 since this
  is the first editor screen built (AC6). Editor-side styling stays
  deliberately plain per DESIGN.md's "Editor components" section — no
  gradient, no accent flourish beyond the lavender focus ring (not needed
  yet on this single-field form).

  Only the tokens this story's UI actually uses are defined here; later
  stories add more as they need them (this is CSS, not a database table —
  Story 1.1 Dev Notes' "create only what's needed" principle still
  applies in spirit, but a shared :root token block is cheap to keep
  complete for colors that are certain to recur).
*/

:root {
  /* colors */
  --surface-canvas: #FBF5EF;
  --surface-card: #FFFFFF;
  --text-primary: #4A4038;
  --text-secondary: #6E645A;
  --text-inverse: #FFFFFF;
  --border-card: #F3DFE0;
  --radio-idle-border: #E3D6CE;
  --radio-idle-fill: #FFFFFF;
  --radio-checked-fill: #C9B8E8;
  --radio-checked-border: #B39DDB;
  --tag-bg: #FDE9D7;
  --tag-text-warm: #8F6035;
  /* DESIGN.md accent-primary — the one permitted focus-ring use, reused
     four times across this file; a named property instead of a fourth
     (or fifth) hardcoded #C9B8E8 literal (caught by code review). */
  --accent-primary: #C9B8E8;

  /*
    Story 2.2: Quick-Modus answer form + result state. Straight from
    DESIGN.md's frontmatter color block. --action-gradient-start/-end/
    -text retokenize .btn-primary's previously-hardcoded gradient
    literal (#F6C9A0/#F3B98A/#5A4632) below, per this file's own
    established promote-repeated-literals pattern (see the
    --accent-primary comment above) -- this story is the first to add a
    second consumer (the answer form's submit button already reuses
    .btn-primary, so no visual change, just a named source of truth).
  */
  --surface-card-subtle: #FFFDFB;
  --accent-wash: #F4EFFB;
  --action-gradient-start: #F6C9A0;
  --action-gradient-end: #F3B98A;
  --action-text: #5A4632;
  --state-correct: #A8D5BA;
  --state-correct-wash: #EAF5EE;
  --state-incorrect: #F3B8B0;
  --state-incorrect-wash: #FBEEEC;
  --tag-text-success: #2E5B3F;
  --tag-text-danger: #7A342C;
  --progress-track: #F1E4DA;

  /* rounded scale */
  --rounded-sm: 7px;
  --rounded-md: 14px;
  --rounded-lg: 18px;
  --rounded-xl: 22px;
  --rounded-2xl: 24px;
  --rounded-full: 9999px;

  /* spacing scale */
  --space-1: 4px;
  --space-2: 8px;
  --space-3: 12px;
  --space-4: 16px;
  --space-5: 20px;
  --space-6: 24px;
  --space-7: 32px;
  --space-8: 40px;
}

* {
  box-sizing: border-box;
}

body {
  margin: 0;
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif;
  background: var(--surface-canvas);
  color: var(--text-primary);
  line-height: 1.5;
}

.editor-nav {
  padding: var(--space-4) var(--space-6);
  border-bottom: 1px solid var(--border-card);
  min-height: var(--space-8);
}

main {
  max-width: 420px;
  margin: var(--space-8) auto;
  padding: var(--space-6);
  background: var(--surface-card);
  border: 1px solid var(--border-card);
  border-radius: var(--rounded-xl);
}

h1 {
  font-size: 17px;
  font-weight: 600;
  margin: 0 0 var(--space-6);
}

label {
  display: block;
  font-weight: 600;
  margin-bottom: var(--space-2);
}

/* editor-form-field: plain bordered field, no gradient, rounded.sm */
input[type="password"] {
  width: 100%;
  padding: var(--space-3);
  margin-bottom: var(--space-4);
  border: 1px solid var(--radio-idle-border);
  border-radius: var(--rounded-sm);
  background: var(--surface-card);
  color: var(--text-primary);
  font-family: inherit;
  font-size: 1rem;
}

input[type="password"]:focus {
  outline: 2px solid var(--accent-primary);
  outline-offset: 1px;
}

/*
  Login submit button: resolved design ambiguity (see Story 1.1 Dev
  Notes) — button-secondary (solid, non-gradient), not button-primary
  (peach gradient), to satisfy the editor area's stated "no gradient"
  rule despite DESIGN.md's own Editor form field entry contradicting
  itself on this point.
*/
/*
  .btn-secondary is shared by the editor login form's <button> (its
  original Story 1.1 use) and, from Story 2.2 on, the "Nächste Frage"
  <a> link (DESIGN.md's button-secondary, "replaces the primary button
  post-submit"). display/text-align/text-decoration are no-ops for the
  <button> case (already block-ish via width:100% and centered by
  default) and the properties an <a> needs to render identically.
*/
.btn-secondary {
  display: block;
  width: 100%;
  padding: var(--space-4);
  border: none;
  border-radius: var(--rounded-xl);
  background: var(--text-primary);
  color: var(--text-inverse);
  font-weight: 600;
  font-size: 15px;
  text-align: center;
  text-decoration: none;
  cursor: pointer;
}

.btn-secondary:hover {
  opacity: 0.92;
}

.error {
  margin: var(--space-4) 0 0;
  color: var(--text-primary);
  font-size: 12.5px;
}

/*
  Story 3.1: KI-Generierung's post-redirect success confirmation. Neither
  .empty-state (a neutral/secondary-color label for "nothing here," not a
  confirmation) nor .error fits, so this is a new class -- plain text
  using the same --tag-text-success color already established for the
  editor's mint/success tag pairing, no pastel background wash (DESIGN.md
  forbids result washes outside the Learner side).
*/
.form-success {
  margin: var(--space-4) 0 0;
  color: var(--tag-text-success);
  font-size: 12.5px;
  font-weight: 600;
}

/*
  Story 1.2: the question create/edit form. Wider container variant since
  the base `main` (420px) is sized for the single-field login card, not a
  question text + topic + 6 option rows form.
*/
.question-form-card {
  max-width: 640px;
}

.prompt-page {
  max-width: 800px;
}

.prompt-template {
  white-space: pre-wrap;
  word-break: break-word;
  padding: var(--space-3);
  border: 1px solid var(--radio-idle-border);
  border-radius: var(--rounded-sm);
  background: var(--surface-card);
  font-family: inherit;
  font-size: 0.9rem;
  line-height: 1.45;
}

/* editor-form-field: plain bordered field, shared by text/textarea inputs */
input[type="text"],
textarea {
  width: 100%;
  padding: var(--space-3);
  border: 1px solid var(--radio-idle-border);
  border-radius: var(--rounded-sm);
  background: var(--surface-card);
  color: var(--text-primary);
  font-family: inherit;
  font-size: 1rem;
  line-height: 1.45;
}

textarea {
  resize: vertical;
}

input[type="text"]:focus,
textarea:focus {
  outline: 2px solid var(--accent-primary);
  outline-offset: 1px;
}

.form-field {
  margin-bottom: var(--space-5);
}

.options-fieldset {
  margin: 0 0 var(--space-5);
  padding: var(--space-4);
  border: 1px solid var(--border-card);
  border-radius: var(--rounded-md);
}

.options-fieldset legend {
  padding: 0 var(--space-2);
  font-weight: 600;
  font-size: 12.5px;
  color: var(--text-secondary);
}

.option-row {
  display: flex;
  align-items: center;
  gap: var(--space-3);
  padding: var(--space-2) 0;
}

.option-row .option-text-label {
  flex: 0 0 auto;
  margin: 0;
  font-weight: 400;
  color: var(--text-secondary);
  font-size: 12.5px;
}

.option-row .option-text {
  flex: 1 1 auto;
  margin: 0;
}

/*
  radio-control: circular (rounded.full), per DESIGN.md's "circular, never
  square" rule distinguishing Einfachauswahl from a multi-select checkbox
  — reused here for "which option is correct," the same semantics.
*/
.option-row .option-correct-label {
  flex: 0 0 auto;
  display: flex;
  align-items: center;
  gap: var(--space-2);
  margin: 0;
  min-height: 44px;
  font-weight: 400;
  font-size: 12.5px;
  color: var(--text-secondary);
  cursor: pointer;
}

.radio-control {
  appearance: none;
  width: 20px;
  height: 20px;
  margin: 0;
  border-radius: var(--rounded-full);
  border: 2px solid var(--radio-idle-border);
  background: var(--radio-idle-fill);
  cursor: pointer;
}

.radio-control:checked {
  border-color: var(--radio-checked-border);
  background: var(--radio-checked-fill);
}

.radio-control:focus-visible {
  outline: 2px solid var(--accent-primary);
  outline-offset: 2px;
}

.field-error {
  margin: var(--space-2) 0 0;
  color: var(--text-primary);
  font-size: 12.5px;
  font-weight: 600;
}

.btn-primary {
  width: 100%;
  padding: var(--space-4);
  border: none;
  border-radius: var(--rounded-xl);
  background: linear-gradient(180deg, var(--action-gradient-start), var(--action-gradient-end));
  color: var(--action-text);
  font-weight: 600;
  font-size: 15px;
  cursor: pointer;
}

.btn-primary:hover {
  opacity: 0.92;
}

/*
  Story 1.3: Fragenübersicht — the grouped question listing. Wider
  container variant, same pattern as .question-form-card above.
*/
.question-list-card {
  max-width: 640px;
}

.topic-group {
  margin-top: var(--space-6);
}

.topic-group:first-of-type {
  margin-top: var(--space-5);
}

/*
  topic-heading: DESIGN.md defines editor-row/topic-chip but no dedicated
  per-topic section-header component (a real gap, flagged rather than
  silently papered over — see the spec's Design Notes). Resolved here as
  plain text on the existing --text-secondary token, no new component
  invented.
*/
.topic-heading {
  margin: 0 0 var(--space-3);
  font-size: 12.5px;
  font-weight: 600;
  color: var(--text-secondary);
  text-transform: uppercase;
  letter-spacing: 0.03em;
}

.editor-row-list {
  list-style: none;
  margin: 0 0 var(--space-4);
  padding: 0;
  display: flex;
  flex-direction: column;
  gap: var(--space-3);
}

/*
  editor-row (DESIGN.md components.editor-row): flat card, no elevation
  beyond a soft shadow-free border, click/tap anywhere opens the detail
  surface — an anchor, not a div+JS handler (AD-8/AD-10's stdlib-only
  bias). min-height 44px meets the accessibility floor's tap-target size.
*/
.editor-row {
  display: flex;
  align-items: center;
  gap: var(--space-3);
  min-height: 44px;
  padding: var(--space-3) var(--space-4);
  background: var(--surface-card);
  border: 1px solid var(--border-card);
  border-radius: var(--rounded-md);
  color: var(--text-primary);
  text-decoration: none;
}

.editor-row:hover {
  opacity: 0.92;
}

.editor-row:focus-visible {
  outline: 2px solid var(--accent-primary);
  outline-offset: 2px;
}

/*
  topic-chip (DESIGN.md components.topic-chip): pill badge. max-width +
  ellipsis: topic can be up to 100 chars (Story 1.2's domain.Validate
  cap) — without a cap here, a long topic can't shrink or wrap (caught
  by code review) and overflows the row.
*/
.topic-chip {
  flex: 0 0 auto;
  max-width: 10rem;
  overflow: hidden;
  text-overflow: ellipsis;
  padding: var(--space-1) var(--space-3);
  border-radius: var(--rounded-full);
  background: var(--tag-bg);
  color: var(--tag-text-warm);
  font-size: 12.5px;
  font-weight: 600;
  white-space: nowrap;
}

.editor-row-text {
  flex: 1 1 auto;
  min-width: 0;
  overflow-wrap: break-word;
  font-size: 14px;
}

.empty-state {
  color: var(--text-secondary);
  font-size: 14px;
}

/*
  Story 1.4: the delete confirmation page. Deliberately reuses the same
  plain `main` card and `.btn-secondary` (no gradient, no new red/alarm
  color — DESIGN.md forbids pure/alarm red anywhere in the system, and the
  editor area stays in its established plain visual register). The
  "this is serious" signal comes from the copy/structure (naming exactly
  what's being deleted, an explicit confirm step), not from color.
*/
.question-delete-confirm-card {
  max-width: 420px;
}

.delete-confirm-text {
  margin: 0 0 var(--space-4);
  font-weight: 600;
}

.delete-confirm-warning {
  margin: 0 0 var(--space-6);
  color: var(--text-secondary);
  font-size: 12.5px;
}

.delete-confirm-cancel {
  margin: var(--space-4) 0 0;
  text-align: center;
  font-size: 14px;
}

.delete-confirm-cancel a {
  color: var(--text-primary);
}

.delete-confirm-cancel a:focus-visible {
  outline: 2px solid var(--accent-primary);
  outline-offset: 2px;
}

/*
  question-delete-link: the "Frage löschen" link on the edit form,
  structurally separate from the save <form> (a sibling <p>, not inside
  it) so it can never accidentally submit alongside the save action.
*/
.question-delete-link {
  margin: var(--space-5) 0 0;
  text-align: center;
  font-size: 13px;
}

.question-delete-link a {
  color: var(--text-secondary);
}

.question-delete-link a:focus-visible {
  outline: 2px solid var(--accent-primary);
  outline-offset: 2px;
}

/*
  Story 2.1: learner-side card container (Start, Themenauswahl, question
  view). Same surface-card/border-card/rounded.xl/spacing.6 combination
  the base `main` selector already provides -- the question-drawing view
  reuses that combination as-is, per the spec's Boundaries & Constraints,
  rather than a separate "question-card" class. Extended (not forked) with
  a >=600px breakpoint per EXPERIENCE.md's responsive rule ("single-column
  mobile; wider card + larger heading desktop") -- additive only, via this
  new class rather than a change to the shared `main` selector, so no
  existing editor page (each already overriding `main`'s 420px cap with
  its own dedicated class) is affected.
*/
.learner-card {
  max-width: 420px;
}

@media (min-width: 600px) {
  .learner-card {
    max-width: 600px;
  }

  .learner-card h1 {
    font-size: 22px;
  }
}

/*
  Themenauswahl's topic list. Per the spec's Design Notes, these rows are
  NOT `editor-row` (DESIGN.md restricts that plain/flat treatment to the
  editor area) -- they reuse the same surface-card/border-card/rounded.xl
  token combination as their own plain link-wrapped card.
*/
.learner-topic-list {
  list-style: none;
  margin: var(--space-5) 0 0;
  padding: 0;
  display: flex;
  flex-direction: column;
  gap: var(--space-3);
}

.learner-topic-card {
  display: flex;
  align-items: center;
  min-height: 44px;
  padding: var(--space-3) var(--space-4);
  background: var(--surface-card);
  border: 1px solid var(--border-card);
  border-radius: var(--rounded-xl);
  color: var(--text-primary);
  text-decoration: none;
}

.learner-topic-card:hover {
  opacity: 0.92;
}

.learner-topic-card:focus-visible {
  outline: 2px solid var(--accent-primary);
  outline-offset: 2px;
}

.learner-question-text {
  margin: var(--space-4) 0 0;
  font-size: 1rem;
}

/*
  Story 2.2: the answer form + post-submit result state. Quick-Modus's
  progress indicator is counter text only (no fill percentage) -- see the
  spec's Design Notes: there's no total to compute a fill fraction
  against yet (Prüfungsmodus, a later story, has one).
*/
.progress-indicator {
  margin: var(--space-3) 0 0;
  font-size: 11px;
  font-weight: 600;
  color: var(--text-secondary);
}

.einfachauswahl-hint {
  margin: var(--space-2) 0 0;
  font-size: 12.5px;
  color: var(--text-secondary);
}

.answer-option-list {
  margin: var(--space-5) 0 0;
  display: flex;
  flex-direction: column;
  gap: var(--space-3);
}

/*
  answer-option (DESIGN.md components.option-row / option-row-checked),
  deliberately named apart from the editor's .option-row/.radio-control
  (a different concept -- the create/edit form's correct-answer
  fieldset), per the spec's Boundaries & Constraints.
*/
.answer-option {
  display: flex;
  align-items: flex-start;
  gap: var(--space-3);
  min-height: 44px;
  padding: var(--space-3) var(--space-4);
  background: var(--surface-card-subtle);
  border: 1px solid var(--radio-idle-border);
  border-radius: var(--rounded-md);
}

label.answer-option {
  cursor: pointer;
}

label.answer-option:hover {
  opacity: 0.95;
}

/*
  Live pre-submit highlight while composing an answer -- DESIGN.md's
  option-row-checked, achieved with :has() (zero JS) rather than a
  server-rendered class, since which radio is checked is browser-local
  state the server never sees until submit. Scoped to .answer-form (the
  unanswered branch's own wrapper, never present post-submit) so this
  can never collide with the post-submit rose/mint state rules below,
  which reuse the same "checked" radio state for a different meaning.
*/
.answer-form .answer-option:has(> .answer-radio:checked) {
  background: var(--accent-wash);
  border-color: var(--radio-checked-border);
}

/*
  Post-submit only: the Learner's own wrong pick (rose) vs. the
  actually-correct option (mint) -- DESIGN.md: "the option the Learner
  selected uses rose," "the actually-correct option is revealed with
  mint." When the pick WAS correct, only answer-option-correct applies
  (never both), so no rose/mint conflict is possible.
*/
.answer-option-selected {
  background: var(--state-incorrect-wash);
  border-color: var(--state-incorrect);
}

/*
  The wrong pick's own radio dot still matches the generic
  .answer-radio:checked rule (lavender, "currently composing an answer")
  without this override -- caught by code review: the row background
  goes rose but the dot inside it didn't, contradicting DESIGN.md's "the
  option the Learner selected uses rose."
*/
.answer-option-selected .answer-radio:checked {
  border-color: var(--state-incorrect);
  background: var(--state-incorrect);
}

.answer-option-correct {
  background: var(--state-correct-wash);
  border-color: var(--state-correct);
}

.answer-radio {
  appearance: none;
  flex: 0 0 auto;
  width: 20px;
  height: 20px;
  margin-top: 2px;
  border-radius: var(--rounded-full);
  border: 2px solid var(--radio-idle-border);
  background: var(--radio-idle-fill);
  cursor: pointer;
}

.answer-radio:checked {
  border-color: var(--radio-checked-border);
  background: var(--radio-checked-fill);
}

.answer-radio:focus-visible {
  outline: 2px solid var(--accent-primary);
  outline-offset: 2px;
}

.answer-radio:disabled {
  cursor: default;
}

/*
  answer-option-radio-label: wraps the post-submit (disabled) radio in a
  real <label>, matching the pre-submit form's own label wrapper --
  caught by code review: a bare, unwrapped <input> next to (not
  associated with) its option text is a real gap even when disabled,
  since browsers/AT don't uniformly guarantee a disabled control is
  excluded from the accessibility tree. The label text itself is
  redundant with .answer-option-text right next to it, so it's visually
  hidden rather than shown twice.
*/
.answer-option-radio-label {
  display: contents;
}

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

/*
  The revealed-correct option's radio, when the Learner picked wrong,
  gets a dashed outline -- "never a red X," DESIGN.md's own phrase for
  how the correct answer is called out without an alarm-style icon.
*/
.answer-option-correct .answer-radio {
  border-style: dashed;
  border-color: var(--state-correct);
}

/*
  ...but only when it's pointing out an answer the Learner DIDN'T pick.
  When the Learner's own selection was the correct one, dashed ("here's
  what you missed") reads wrong for "you got this right" -- caught by
  code review. Higher specificity than the rule above, so it wins
  regardless of source order.
*/
.answer-option-correct.answer-option-selected .answer-radio {
  border-style: solid;
}

.answer-option-body {
  flex: 1 1 auto;
  min-width: 0;
}

.answer-option-text {
  display: block;
  font-size: 14px;
  overflow-wrap: break-word;
}

/*
  answer-tag (DESIGN.md components.tag-missed / tag-wrong): on its own
  indented line below the option text, never inline (a previously-caught
  regression risk per the epic context). Counter-intuitive naming, per
  the spec's Design Notes: tag-missed (mint/success) pairs with
  "Richtige Antwort," tag-wrong (rose/danger) pairs with "Deine
  Antwort" -- .answer-tag-correct/-wrong below are named for the LABEL
  they carry, not DESIGN.md's own token names, to avoid that exact
  mix-up in this file.
*/
.answer-tag {
  display: block;
  width: fit-content;
  margin-top: var(--space-2);
  padding: var(--space-1) var(--space-3);
  border-radius: var(--rounded-full);
  font-size: 10px;
  font-weight: 700;
  letter-spacing: 0.03em;
  text-transform: uppercase;
}

.answer-tag-wrong {
  background: var(--state-incorrect);
  color: var(--tag-text-danger);
}

.answer-tag-correct {
  background: var(--state-correct);
  color: var(--tag-text-success);
}

/*
  result-banner (DESIGN.md components.result-banner). No icon on the
  correct variant -- DESIGN.md bans icon-only (✓/✗) signaling and gives
  no correct-variant glyph to use, so the headline text alone carries
  the meaning there (see the spec's Design Notes). The incorrect
  variant's "!" is decorative only, never the sole signal.
*/
.result-banner {
  display: flex;
  align-items: flex-start;
  gap: var(--space-3);
  margin: var(--space-4) 0 0;
  padding: var(--space-4);
  border-radius: var(--rounded-lg);
}

.result-banner-correct {
  background: var(--state-correct-wash);
}

.result-banner-incorrect {
  background: var(--state-incorrect-wash);
}

.result-banner-icon {
  flex: 0 0 auto;
  display: flex;
  align-items: center;
  justify-content: center;
  width: 22px;
  height: 22px;
  border-radius: var(--rounded-full);
  background: var(--state-incorrect);
  color: var(--tag-text-danger);
  font-size: 13px;
  font-weight: 700;
}

.result-banner-headline {
  margin: 0;
  font-weight: 600;
  font-size: 15px;
}

.result-banner-copy {
  margin: var(--space-1) 0 0;
  font-size: 12.5px;
  color: var(--text-secondary);
}

.answer-form .btn-primary {
  margin-top: var(--space-5);
}

.next-question-link {
  margin-top: var(--space-5);
}

/*
  Story 2.3: a de-emphasized plain-text exit/secondary link -- generically
  named (not "fertig-link", despite that being its first use) since it's
  reused verbatim for three separate links: "Fertig" in both branches of
  frage.html, and "Zurück zum Start" on ergebnis.html (renamed from an
  earlier feature-specific name during code review, which found a
  Fertig-specific class being used as a general-purpose utility --
  confusing, and an accidental-breakage risk if "Fertig" is ever
  refactored in isolation). Deliberately not `.btn-secondary` (that's
  "Nächste Frage"/"Nochmal", a *continue* action; these are exit actions
  that must not visually compete with it). No DESIGN.md component covers
  this, so it follows the existing plain-text-link register already
  established for exactly this kind of secondary/exit action elsewhere in
  this codebase -- `.question-delete-link`/`.delete-confirm-cancel` (small,
  --text-secondary, no button chrome).
*/
.learner-secondary-link {
  margin: var(--space-4) 0 0;
  text-align: center;
  font-size: 13px;
}

.learner-secondary-link a {
  color: var(--text-secondary);
}

.learner-secondary-link a:focus-visible {
  outline: 2px solid var(--accent-primary);
  outline-offset: 2px;
}

/*
  Story 2.3: Quick-Ergebnis. Reuses `.learner-card`/existing typography --
  no new component beyond the score line and the Nochmal button's own
  top margin (mirrors `.next-question-link` above; `.btn-secondary` alone
  has no spacing from a preceding paragraph).
*/
.quick-ergebnis-score {
  margin: var(--space-5) 0 0;
  font-size: 1.1rem;
  font-weight: 600;
}

/*
  Story 2.4: enabled Prüfungsmodus entry on Start -- a <form>/<button>
  (POST, not a plain link, since starting an attempt creates real session
  state) styled with the existing .btn-secondary, just needing its own
  top spacing since it follows the Quick-Modus paragraph link rather than
  another .btn-secondary-using element.
*/
.pruefung-start-form {
  margin-top: var(--space-4);
}

/*
  Story 2.4: disabled-Prüfungsmodus state on Start. No existing pattern to
  reuse (confirmed by investigation, see the spec's Design Notes) -- a
  plain non-interactive block, not a `disabled` <button> (native
  disabled-button styling varies awkwardly across browsers and can't
  carry explanatory copy beneath it). Dashed border + muted surface/text
  visually reads as "not a live tap target," distinct from every enabled
  link/button on this page.
*/
.pruefung-disabled {
  margin-top: var(--space-4);
  padding: var(--space-3) var(--space-4);
  background: var(--surface-card-subtle);
  border: 1px dashed var(--radio-idle-border);
  border-radius: var(--rounded-xl);
}

.pruefung-disabled-label {
  margin: 0;
  font-weight: 600;
  color: var(--text-secondary);
}

.pruefung-disabled-copy {
  margin: var(--space-2) 0 0;
  font-size: 13px;
  color: var(--text-secondary);
}

.quick-ergebnis-nochmal {
  margin-top: var(--space-5);
}

/*
  Story 2.5: Prüfungs-Ergebnis's six-tier grade + per-topic breakdown.
  Reuses `.learner-card`; the tier label and score line follow
  `.quick-ergebnis-score`'s own typography scale/spacing rhythm (tier
  slightly larger/bolder as the headline number, score as its
  supporting line). The per-topic list is a new pattern (no existing
  per-topic list/table markup elsewhere in the codebase to reuse): plain
  rows, not `.learner-topic-card`'s tappable-link card treatment, since
  these rows are inert data, not navigation.
*/
.pruefung-ergebnis-tier {
  margin: var(--space-5) 0 0;
  font-size: 1.4rem;
  font-weight: 700;
}

.pruefung-ergebnis-score {
  margin: var(--space-1) 0 0;
  font-size: 1rem;
  color: var(--text-secondary);
}

.pruefung-ergebnis-topics-heading {
  margin: var(--space-6) 0 0;
  font-size: 14px;
  font-weight: 600;
}

.pruefung-ergebnis-topics {
  list-style: none;
  margin: var(--space-3) 0 0;
  padding: 0;
  display: flex;
  flex-direction: column;
  gap: var(--space-2);
}

.pruefung-ergebnis-topic-row {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: var(--space-3);
  padding: var(--space-3) var(--space-4);
  background: var(--surface-card-subtle);
  border: 1px solid var(--border-card);
  border-radius: var(--rounded-md);
}

.pruefung-ergebnis-topic-name {
  font-size: 14px;
  overflow-wrap: break-word;
}

.pruefung-ergebnis-topic-score {
  flex: 0 0 auto;
  font-size: 13px;
  font-weight: 600;
  color: var(--text-secondary);
}

/*
  Story 2.5: "Antworten durchsehen" link on Prüfungs-Ergebnis, between the
  topic breakdown and "Zurück zum Start" -- reuses .btn-secondary as-is
  (matching ergebnis.html's .quick-ergebnis-nochmal precedent); only the
  top spacing pulling it away from the preceding topic list is new.
*/
.pruefung-ergebnis-antwortdurchsicht {
  margin-top: var(--space-5);
}

/*
  Story 2.6: Prüfungs-Antwortdurchsicht stacks every attempt question's
  full frage.html answered-state markup (topic-chip, progress-indicator,
  result-banner, answer-option-list) one after another on a single page.
  Every class inside each block is already styled above and reused as-is
  -- this is only the new outer stacking wrapper, giving each question a
  divider and breathing room from the one before it (the existing
  .learner-card/typography rules were never written for a repeated list
  of stacked questions, only a single one).
*/
.antwortdurchsicht-question {
  margin-top: var(--space-6);
  padding-top: var(--space-6);
  border-top: 1px solid var(--border-card);
}

.antwortdurchsicht-question:first-of-type {
  margin-top: var(--space-5);
  padding-top: 0;
  border-top: none;
}

/*
  Story 3.3: Prüfungswarteschlange's origin tag ("Claude"/"importiert").
  Reuses topic-chip's pill shape (rounded.full, small pill, same padding/
  font scale) -- the reusable base the spec pointed at -- but deliberately
  NOT topic-chip's own --tag-bg/--tag-text-warm color pairing, so an
  origin tag sitting right next to a topic-chip on the same
  Warteschlange row never reads as a second topic. Plain neutral
  border+secondary-text treatment instead, matching the editor area's
  established "no accent flourish" register.
*/
.source-tag {
  flex: 0 0 auto;
  padding: var(--space-1) var(--space-3);
  border: 1px solid var(--border-card);
  border-radius: var(--rounded-full);
  background: var(--surface-card-subtle);
  color: var(--text-secondary);
  font-size: 12.5px;
  font-weight: 600;
  white-space: nowrap;
}