/**
 * Plan editor styling.
 *
 * MDXEditor's structural CSS is imported by the app; this retheme layer maps it
 * onto Ace's tokens so the editor reads as part of the product rather than as a
 * third-party widget.
 */

.plan {
	--plan-gutter: 2rem;
	container-type: inline-size;
	/*
	 * A comfortable measure. The panel is resizable and a plan is read far more
	 * often than it is written, so the text stops widening well before the pane
	 * does. At the body size below this is roughly 85 characters a line, near
	 * the top of the range a reader can track back from without losing the row.
	 */
	--plan-measure: 40rem;
}

/* Decisions pane -------------------------------------------------------- */

.plan-workspace {
	position: relative;
	display: flex;
	flex: 1;
	min-height: 0;
	overflow: hidden;
}

.plan-document {
	position: relative;
	flex: 1;
	min-width: 0;
	min-height: 0;
}

.plan-decisions {
	display: flex;
	height: 100%;
	min-width: 0;
	min-height: 0;
	flex-direction: column;
	overflow: hidden;
	background: var(--color-background);
}

/* The node stays in the plan for exports and agent reads; its form is in the
   decisions pane, so inline it renders as nothing. */
.plan .plan-content [data-plan-questionnaire],
.plan .plan-content [data-plan-decision] {
	display: none;
}

/*
 * The prose a sidecar card refers to, while somebody is pointing at that card.
 *
 * Registered in `CSS.highlights`, so it paints over the text without putting
 * anything in the document. One mark for both halves of the sidecar: questions
 * used to outline a block while comments washed a range, so the same fact —
 * this is the prose that card refers to — read as two different things
 * depending on which card it came from. `::highlight()` cannot draw an outline,
 * so the wash is what they can both be.
 *
 * Nothing is painted at rest. Standing marks for live comments and for decided
 * prose were tried and taken out: a plan accumulates decisions, so anything
 * permanent ends up covering most of the document, and a page that is mostly
 * highlighted has told you nothing.
 *
 * `background-color`, not `background`: only a handful of longhands are
 * permitted here, and the shorthand works today solely because browsers expand
 * it before filtering. Not worth depending on.
 *
 * The colour it composites to over the page is recorded because a percentage
 * of an already-pale token says nothing about whether anyone will see it —
 * `accent` is `oklch(0.85 0.09 250)`, so 14% of it renders `#f9fbff`, which is
 * white. `ring` is dark enough that a wash of it reads, at about the weight of
 * the browser's own text selection.
 */
::highlight(plan-related) {
	/* #b7cff2 */
	background-color: color-mix(in oklch, var(--color-ring) 40%, transparent);
}

/*
 * The same pointer, for a browser with no Highlight API.
 *
 * A block outline rather than a wash, because without the API there is no way
 * to mark part of one — less precise, and honest about it. Standing marks are
 * dropped entirely on this path: outlining every decided passage would box up
 * half the plan.
 */
.plan .plan-content [data-plan-related] {
	border-radius: var(--radius-sm);
	outline: 1px solid color-mix(in oklch, var(--color-ring) 60%, transparent);
	outline-offset: 3px;
	background: color-mix(in oklch, var(--color-accent) 20%, transparent);
}

@container (max-width: 46rem) {
	.plan-workspace.is-sidecar-open {
		grid-template-columns: minmax(0, 1fr);
		grid-template-rows: minmax(0, 1fr) minmax(12rem, 40vh);
	}

	.plan-workspace.is-sidecar-open .plan-document {
		grid-column: 1;
		grid-row: 1;
	}

	.plan-sidecar {
		grid-column: 1;
		grid-row: 2;
		border-block-start: 1px solid var(--color-border);
		border-inline-start: 0;
	}

	.plan-sidecar-grip {
		display: none;
	}
}

/*
 * Retheme MDXEditor onto Ace's tokens.
 *
 * MDXEditor ships a light Radix palette on its own root and only switches off
 * it for a `.dark-theme` class it expects the host to add. Ace has its own
 * theme, so rather than opt into a second one we point its variables at ours —
 * the editor then follows Ace into light or dark with nothing to keep in sync.
 *
 * These have to land on the same element MDXEditor sets them on; an ancestor
 * would lose to its own declaration.
 */
.plan .mdxeditor {
	background: transparent;
	font-family: InterVariable, system-ui, sans-serif;

	--basePageBg: transparent;
	--baseBase: var(--color-background);
	--baseBgSubtle: var(--color-muted);
	--baseBg: var(--color-muted);
	--baseBgHover: var(--color-accent);
	--baseBgActive: var(--color-accent);
	--baseLine: var(--color-border);
	--baseBorder: var(--color-border);
	--baseBorderHover: var(--color-ring);
	--baseSolid: var(--color-muted-foreground);
	--baseSolidHover: var(--color-foreground);
	--baseText: var(--color-foreground);
	--baseTextContrast: var(--color-foreground);

	--accentBase: var(--color-background);
	--accentBgSubtle: var(--color-muted);
	--accentBg: var(--color-muted);
	--accentBgHover: var(--color-accent);
	--accentBgActive: var(--color-accent);
	--accentLine: var(--color-border);
	--accentBorder: var(--color-border);
	--accentBorderHover: var(--color-ring);
	--accentSolid: var(--color-primary);
	--accentSolidHover: var(--color-primary-hover);
	--accentText: var(--color-primary);
	--accentTextContrast: var(--color-foreground);

	--admonitionTipBg: var(--color-muted);
	--admonitionTipBorder: var(--color-success);
	--admonitionInfoBg: var(--color-muted);
	--admonitionInfoBorder: var(--color-primary);
	--admonitionCautionBg: var(--color-muted);
	--admonitionCautionBorder: var(--color-warning);
	--admonitionDangerBg: var(--color-muted);
	--admonitionDangerBorder: var(--color-destructive);
	--admonitionNoteBg: var(--color-muted);
	--admonitionNoteBorder: var(--color-border);

	--error-color: var(--color-destructive);
	--font-body: InterVariable, system-ui, sans-serif;
	--font-mono: ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, monospace;
}

/*
 * Scoped to `.plan` on purpose. MDXEditor sets padding and colour directly
 * on its own content class, which is exactly as specific as ours, so a bare
 * `.plan-content` wins only by landing later in the bundle. That is a
 * property of how the CSS happens to be chunked, not of anything we control.
 */
.plan .plan-content {
	/*
	 * The trailing space is deliberate and large: the caret should never sit
	 * against the bottom of the pane, and a plan is usually appended to.
	 */
	padding: 1.5rem var(--plan-gutter) 60vh;
	margin-inline: auto;
	max-width: calc(var(--plan-measure) + var(--plan-gutter) * 2);
	font-size: 0.9375rem;
	line-height: 1.6;
	color: var(--color-foreground);
}

.plan .plan-content:focus {
	outline: none;
}

/*
 * Document typography.
 *
 * Tailwind's preflight resets headings to inherit their size and weight and
 * strips list markers, which is right for an app chrome and wrong for prose.
 * A plan is prose, so the document elements are given their meaning back here.
 */
.plan-content :is(h1, h2, h3, h4, h5, h6) {
	font-weight: 600;
	line-height: 1.3;
	margin-block: 1.5em 0.5em;
	color: var(--color-foreground);
}

.plan-content :is(h1, h2, h3, h4, h5, h6):first-child {
	margin-block-start: 0;
}

.plan-content h1 {
	font-size: 1.5rem;
}
.plan-content h2 {
	font-size: 1.25rem;
}
.plan-content h3 {
	font-size: 1.0625rem;
}
.plan-content :is(h4, h5, h6) {
	font-size: 1rem;
}

.plan-content p {
	margin-block: 0.75em;
}

.plan-content :is(ul, ol) {
	margin-block: 0.75em;
	padding-inline-start: 1.5em;
}

.plan-content ul {
	list-style: disc;
}
.plan-content ol {
	list-style: decimal;
}

.plan-content li {
	margin-block: 0.25em;
}

/* Nested lists sit tighter than the block they interrupt. */
.plan-content li > :is(ul, ol) {
	margin-block: 0.25em;
}

.plan-content blockquote {
	margin-block: 1em;
	padding-inline-start: 1em;
	border-inline-start: 3px solid var(--color-border);
	color: var(--color-muted-foreground);
}

.plan-content a {
	color: var(--color-primary);
	text-decoration: underline;
	text-underline-offset: 2px;
}

.plan-content hr {
	margin-block: 1.5em;
	border: 0;
	border-block-start: 1px solid var(--color-border);
}

.plan-content :is(strong, b) {
	font-weight: 600;
	color: var(--color-foreground);
}

/* Structural components ------------------------------------------------- */

.plan-content [data-plan-type] {
	border-inline-start: 3px solid var(--color-border);
	padding: 0.75rem 1rem;
	margin-block: 1rem;
	border-radius: var(--radius-md);
	background: var(--color-muted);
}

.plan-content [data-plan-type="warning"] {
	border-color: var(--color-chart-4);
}
.plan-content [data-plan-type="danger"] {
	border-color: var(--color-destructive);
}
.plan-content [data-plan-type="tip"] {
	border-color: var(--color-chart-2);
}
.plan-content [data-plan-type="important"] {
	border-color: var(--color-chart-5);
}

.plan-content pre {
	background: var(--color-code);
	border-radius: var(--radius-md);
	padding: 0.75rem 1rem;
	overflow-x: auto;
	font-family: ui-monospace, SFMono-Regular, monospace;
	font-size: 0.8125rem;
}

/*
 * Inline code. Sized in `em` so it tracks whatever it sits in — a heading's
 * code should not shrink to body size — and left to `pre` when it is a block.
 */
.plan-content :not(pre) > code {
	background: var(--color-code);
	color: var(--color-foreground);
	border-radius: var(--radius-sm);
	padding: 0.125em 0.3em;
	font-family: ui-monospace, SFMono-Regular, monospace;
	font-size: 0.875em;
}

/* Tables scroll independently so a wide one never widens the document. */
/*
 * Tables scroll independently so a wide one never widens the document.
 *
 * `display: block` is what allows that, but it also stops the table sizing
 * itself from its contents — columns get squeezed until neighbouring values
 * touch and read as one word. `width: max-content` gives that back, and the
 * `max-width` keeps a narrow table from stretching to fill the measure.
 */
.plan-content table {
	display: block;
	width: max-content;
	max-width: 100%;
	overflow-x: auto;
	border-collapse: collapse;
	margin-block: 1em;
}

.plan-content th,
.plan-content td {
	border: 1px solid var(--color-border);
	padding: 0.375rem 0.625rem;
	text-align: start;
	/* Without this a cell collapses onto its neighbour when a column is
	   narrow, and two values read as one word. */
	vertical-align: top;
	min-width: 4rem;
}

.plan-content th {
	font-weight: 600;
	background: var(--color-muted);
	color: var(--color-foreground);
}

/* A cell's paragraph is the cell; it should not add document spacing. */
.plan-content :is(th, td) > p {
	margin-block: 0;
}

/* Remote cursors --------------------------------------------------------- */

/*
 * The frame remote cursors are measured against. It wraps the prose and grows
 * with it, so carets scroll with the text they belong to.
 */
.plan .plan-frame {
	position: relative;
}

/*
 * Lexical owns the caret's geometry — position, height and offsets are written
 * inline on every paint — and hands us the peer's colour as a custom property.
 * Only appearance belongs here. The shadow widens a 1px caret that would
 * otherwise be easy to miss, without fighting the inline width.
 */
.plan .plan-cursor {
	background-color: var(--lexical-cursor-color, currentColor);
	box-shadow: 0 0 0 0.5px var(--lexical-cursor-color, currentColor);
	border-radius: 1px;
}

.plan .plan-cursor-name {
	position: absolute;
	inset-block-end: 100%;
	inset-inline-start: -1px;
	margin-block-end: 2px;
	padding: 0 0.25rem;
	border-radius: 0.25rem;
	background: var(--lexical-cursor-color, currentColor);
	color: white;
	font-size: 0.625rem;
	line-height: 1rem;
	font-weight: 500;
	white-space: nowrap;
	pointer-events: none;
	opacity: 0;
	transition: opacity 200ms ease;
}

/* Raised while its peer is moving, then left to fade. */
.plan .plan-cursor[data-plan-active] .plan-cursor-name {
	opacity: 1;
}

/*
 * Where selections fall back to rect overlays, because the browser has no
 * Highlight API. The supported path is styled by Lexical from the same colour.
 */
.plan .plan-cursor-selection-bg {
	background-color: color-mix(in srgb, var(--lexical-cursor-color, currentColor) 30%, transparent);
}

@media (prefers-reduced-motion: reduce) {
	.plan * {
		transition: none !important;
		animation: none !important;
	}

	/*
	 * Without the fade, a label would blink in and out on every keystroke a
	 * peer makes. Leaving it up is the quieter of the two.
	 */
	.plan .plan-cursor-name {
		opacity: 1;
	}
}

/* Rendered previews ------------------------------------------------------ */

.plan-content [data-plan-preview]:empty {
	display: none;
}

.plan-content [data-plan-preview][data-plan-error] {
	color: var(--color-destructive);
	font-size: 0.75rem;
	padding: 0.5rem 0;
}

/* Source stays visible and editable beneath its preview. */
.plan-content [data-plan-source] {
	white-space: pre-wrap;
	font-family: ui-monospace, SFMono-Regular, monospace;
	font-size: 0.8125rem;
}

/*
 * A general sibling, not an adjacent one: the block's chrome sits between the
 * preview and the source, and a block has exactly one source anyway.
 */
.plan-content [data-plan-preview]:not(:empty) ~ [data-plan-source] {
	opacity: 0.6;
	font-size: 0.75rem;
}

/*
 * A block formula is an editable region exactly like a code block, and has to
 * read as one: the rendered result on the page, its source in a box below.
 *
 * A code block gets that box from the generic `pre` rule, and a formula renders
 * the same structure into plain `div`s — so without this it is a bare line of
 * monospace with no background, no padding and nothing in it, and inserting one
 * looks like the command did nothing at all. The box belongs to the source
 * alone; wrapping the preview too would put the rendered formula in a grey
 * well, which is not what a diagram does.
 */
.plan-content .planMath[data-plan-inline="false"] [data-plan-source] {
	--ace-formula-inset-block: 0.75rem;
	--ace-formula-inset-inline: 1rem;

	/*
	 * No `display` here. A `div` is already block, so declaring it again buys
	 * nothing — and this selector outranks the rule that hides the source when
	 * the block is collapsed, which would keep a formula on screen forever.
	 */
	position: relative;
	background: var(--color-code);
	border-radius: var(--radius-md);
	padding: var(--ace-formula-inset-block) var(--ace-formula-inset-inline);
	overflow-x: auto;
}

/*
 * Say what belongs in an empty one. Lexical fills an empty block with a managed
 * line break, so `:empty` never matches and the placeholder keys off that
 * instead. It sits out of flow so it cannot displace the caret in front of it,
 * which means it has to repeat the padding the caret is already inside.
 */
.plan-content
	.planMath[data-plan-inline="false"]
	[data-plan-source]:has(> br[data-lexical-managed-linebreak]:only-child)::before {
	content: "LaTeX, e.g. E = mc^2";
	position: absolute;
	inset-block-start: var(--ace-formula-inset-block);
	inset-inline-start: var(--ace-formula-inset-inline);
	color: var(--color-muted-foreground);
	pointer-events: none;
}

/*
 * Showing a result without its source.
 *
 * Not the `hidden` attribute: a formula's source sets `display: block`, which
 * outranks the user agent's rule for `hidden` and would leave it on screen.
 */
.plan-content [data-plan-collapsed] [data-plan-source] {
	display: none;
}

.plan-content [data-plan-preview] svg {
	max-width: 100%;
	height: auto;
}

/* Tabs ------------------------------------------------------------------- */

.plan-content [data-plan-chrome="tabs"] {
	margin-block-end: 0.5rem;
}

.plan-content [data-plan-panels] > [hidden] {
	display: none;
}

/* Presence --------------------------------------------------------------- */

/*
 * Opposite the status chip, and above the prose rather than in it. Pointer
 * events stay on: the faces carry a tooltip naming who is here.
 */
.plan-presence {
	position: absolute;
	z-index: 2;
	inset-block-start: 0.75rem;
	inset-inline-start: 0.75rem;
	display: flex;
	align-items: center;
}

/* Status ----------------------------------------------------------------- */

/*
 * Floats over the end of the prose rather than taking a row from it. Never
 * interactive, so it stays out of the way of selecting the text underneath.
 */
.plan-status {
	position: absolute;
	z-index: 2;
	inset-block-end: 0.75rem;
	inset-inline-end: 0.75rem;
	display: flex;
	align-items: center;
	gap: 0.375rem;
	max-width: min(22rem, 60%);
	pointer-events: none;
	font-size: 0.6875rem;
	line-height: 1rem;
}

/*
 * A hidden state is not `display: none`: the label stays in the accessibility
 * tree so the live region keeps reporting durability. With every child
 * screen-reader-only the box collapses to nothing on screen.
 */
.plan-status[data-level="notice"] {
	padding: 0.25rem 0.625rem;
	border: 1px solid var(--color-border);
	border-radius: 9999px;
	background: var(--color-background);
	box-shadow: 0 1px 2px color-mix(in oklch, var(--color-foreground) 8%, transparent);
}

.plan-status-dot {
	flex: none;
	width: 0.375rem;
	height: 0.375rem;
	border-radius: 9999px;
	background: currentColor;
}

/* What the agent changed ------------------------------------------------- */

/*
 * Marks drawn entirely in `box-shadow`, which is what keeps them free of the
 * layout.
 *
 * An agent editing below the fold must not shift the sentence somebody is in
 * the middle of typing, and a mark that expires ten seconds later must not
 * shift it back — so nothing here may take space, and nothing here may add an
 * element. A `::before` bar was the obvious way to draw the gutter and is the
 * wrong one: it needs the block to become a containing block, which re-anchors
 * any absolutely positioned widget chrome inside it for as long as the mark is
 * up.
 *
 * An outset shadow offset into the gutter with a negative spread leaves a
 * sliver beside the block, outside it, costing no space and no stacking.
 */
.plan .plan-content [data-plan-change] {
	transition: box-shadow 600ms ease-out, background 600ms ease-out;
}

/* Written just now: a solid rule beside it, and a wash over it. */
.plan .plan-content [data-plan-change="added"] {
	box-shadow: -0.5rem 0 0 -0.375rem var(--color-ring);
	background: color-mix(in oklch, var(--color-ring) 10%, transparent);
}

/*
 * Moved, not written. Deliberately quieter than the wash above: the words are
 * ones the reader may already have read, and marking them as loudly as new
 * prose would say something untrue about them.
 */
.plan .plan-content [data-plan-change="moved"] {
	box-shadow: -0.5rem 0 0 -0.4375rem color-mix(in oklch, var(--color-ring) 70%, transparent);
}

/*
 * A hole where something was.
 *
 * Drawn on the edge of the block still beside it, because what went has no
 * element to carry a mark. The two sides are separate properties so one block
 * can hold a removal above it and a vacancy below it at once.
 */
.plan .plan-content [data-plan-gap-before],
.plan .plan-content [data-plan-gap-after] {
	transition: box-shadow 600ms ease-out;
}

.plan .plan-content [data-plan-gap-before="removed"] {
	box-shadow: 0 -0.375rem 0 -0.3125rem var(--color-muted-foreground);
}

.plan .plan-content [data-plan-gap-after="removed"] {
	box-shadow: 0 0.375rem 0 -0.3125rem var(--color-muted-foreground);
}

/*
 * Where a block left from, as opposed to where one was deleted. Fainter, since
 * nothing was lost — the content is still in the plan, further up or down.
 */
.plan .plan-content [data-plan-gap-before="vacated"] {
	box-shadow: 0 -0.375rem 0 -0.34375rem
		color-mix(in oklch, var(--color-muted-foreground) 55%, transparent);
}

.plan .plan-content [data-plan-gap-after="vacated"] {
	box-shadow: 0 0.375rem 0 -0.34375rem
		color-mix(in oklch, var(--color-muted-foreground) 55%, transparent);
}

/*
 * A block can be both: written where something else was taken out. The
 * shadows compose in one property, so the combinations have to be spelled out
 * rather than left to the cascade, which would keep only the last.
 */
.plan .plan-content [data-plan-change="added"][data-plan-gap-before="removed"] {
	box-shadow:
		-0.5rem 0 0 -0.375rem var(--color-ring),
		0 -0.375rem 0 -0.3125rem var(--color-muted-foreground);
}

.plan .plan-content [data-plan-change="added"][data-plan-gap-after="removed"] {
	box-shadow:
		-0.5rem 0 0 -0.375rem var(--color-ring),
		0 0.375rem 0 -0.3125rem var(--color-muted-foreground);
}

/*
 * The agent wrote this block and the reader is pointing at a card that refers
 * to it.
 *
 * Only reachable where there is no Highlight API, since that is the only path
 * on which a sidecar mark touches the element's own background. The two rules
 * have equal specificity, so without saying so the later one — this file's —
 * would simply replace the earlier and the pointer would lose its wash.
 * Pointing is something the reader just did and the agent's mark is ambient,
 * so the pointer wins; the gutter bar is in `box-shadow` and survives either
 * way.
 */
.plan .plan-content [data-plan-related][data-plan-change] {
	background: color-mix(in oklch, var(--color-accent) 20%, transparent);
}

/* Reaching the ones off screen ------------------------------------------- */

/*
 * One chip per edge, over the prose rather than in it, and only while
 * something in that direction is still unread. Opposite the status chip at the
 * bottom, which is why the lower one sits inline-start of it.
 */
.plan-changes {
	position: absolute;
	z-index: 3;
	inset-inline-start: 50%;
	translate: -50% 0;
	display: flex;
	flex-direction: column;
	gap: 0.375rem;
	max-width: min(24rem, 80%);
}

.plan-changes[data-side="above"] {
	inset-block-start: 0.75rem;
}

.plan-changes[data-side="below"] {
	inset-block-end: 0.75rem;
	flex-direction: column-reverse;
}

.plan-changes-bar {
	display: flex;
	align-self: center;
	align-items: stretch;
	border: 1px solid var(--color-border);
	border-radius: 9999px;
	background: var(--color-background);
	box-shadow: 0 1px 3px color-mix(in oklch, var(--color-foreground) 12%, transparent);
	font-size: 0.6875rem;
	line-height: 1rem;
	overflow: hidden;
}

.plan-changes-go,
.plan-changes-more {
	display: flex;
	align-items: center;
	gap: 0.375rem;
	padding: 0.25rem 0.625rem;
	color: var(--color-foreground);
	cursor: pointer;
}

.plan-changes-more {
	padding-inline: 0.375rem;
	border-inline-start: 1px solid var(--color-border);
}

.plan-changes-go:hover,
.plan-changes-more:hover {
	background: var(--color-accent);
}

.plan-changes-list,
.plan-changes-empty {
	margin: 0;
	padding: 0.375rem;
	max-height: 12rem;
	overflow-y: auto;
	list-style: none;
	border: 1px solid var(--color-border);
	border-radius: var(--radius-md);
	background: var(--color-background);
	box-shadow: 0 2px 8px color-mix(in oklch, var(--color-foreground) 12%, transparent);
	font-size: 0.6875rem;
	line-height: 1rem;
}

.plan-changes-empty {
	padding: 0.5rem 0.625rem;
	color: var(--color-muted-foreground);
}

.plan-changes-item {
	display: flex;
	gap: 0.5rem;
	padding: 0.25rem 0.5rem;
	border-radius: var(--radius-sm);
}

.plan-changes-kind {
	flex: none;
	font-weight: 600;
	color: var(--color-muted-foreground);
}

/* Still waiting to be reached, as opposed to already shown and counted down. */
.plan-changes-item[data-unread] {
	background: color-mix(in oklch, var(--color-ring) 8%, transparent);
}

.plan-changes-item[data-unread] .plan-changes-kind {
	color: var(--color-foreground);
}

.plan-changes-item[data-kind="removed"] .plan-changes-text {
	color: var(--color-muted-foreground);
	text-decoration: line-through;
}

/* One line each: this is an index, not a diff. */
.plan-changes-text {
	overflow: hidden;
	white-space: nowrap;
	text-overflow: ellipsis;
}