import * as React from 'react'; /** * One line of a line-numbered log: a gutter number and a monospaced message. * * Ported from Figma `.console-message` (22:11297), which is a 20px row of Twilio Sans Mono 16/20 with a * gutter beside a body. Its gutter is seventeen separate hand-drawn text layers, so the atom is a * specimen of a log rather than a component with a line-count prop. * * **Deliberately ONE LINE, and not a code viewer.** The atom supplies the type ramp (mono 16/20), the row * height and the two gaps, and says nothing about scrolling, wrapping, selection, a copy affordance or * how a long line behaves. Building a viewer from it would be inventing the nine tenths it does not show. * A caller stacks these; the container's scroll behaviour is the caller's, which is the same call * `ChatLog` makes about who owns the viewport. */ declare const consoleMessageStyles: (props?: import("class-variance-authority/types").ClassProp | undefined) => string; /** * The gutter number. * * **Figma's syntax colours are declined, and this is the atom that inherits the defect if they are not.** * It inks the gutter `colors/code/3` #7688c2 and the body `blue-200` #3acefa. Both map 1:1 onto Strix * tokens — `--color-code-3` and `--color-code-7`/`--color-highlight` — and all eight `--color-code-*` are * declared once in `@theme` and never re-declared per theme. So they are theme-invariant: all eight pass * 4.5:1 on a dark page and **all eight fail on a light one**, `code-3` at 3.46:1 and the body cyan at * **1.84:1**. A code viewer built from this atom verbatim would be unreadable in light mode rather than * merely low-contrast. * * That is open question 7 in `docs/DESIGN_DECISIONS_NEEDED.md`, and it stays open: authoring a light * syntax ramp by eye is how a palette stops being coherent. `--color-text-accent-strong` (6.98:1 light / * 12.12:1 dark) carries both roles until that question is settled, which is the same substitution * `ToolCall` made for the same token. */ declare const consoleMessageLineNumberStyles: (props?: import("class-variance-authority/types").ClassProp | undefined) => string; /** The message body. Same ink and the same reason as the gutter — see above. */ declare const consoleMessageTextStyles: (props?: import("class-variance-authority/types").ClassProp | undefined) => string; export { consoleMessageStyles, consoleMessageLineNumberStyles, consoleMessageTextStyles }; /** * Figma's `State` axis, and it is not a visual variant: `Active` and `Loading` bind identical fills, * inks and geometry in every layer, so whatever distinguishes Loading in the design is not expressed in * any bound value. It is expressed here as `aria-busy` rather than invented as a treatment. */ export declare const CONSOLE_MESSAGE_STATES: readonly ["active", "loading"]; export type ConsoleMessageState = (typeof CONSOLE_MESSAGE_STATES)[number]; export interface ConsoleMessageProps extends React.ComponentPropsWithoutRef<'div'> { /** The gutter number. `select-none`, so copying the row does not carry the numbers with it. */ lineNumber: number; /** * `loading` sets `aria-busy` and changes nothing visually. **Not because Figma draws nothing** — * this said Figma "draws it identically to `active`", and in fact its Loading member (22:11319) * carries `opacity-30` on the root. Every bound ink is the same, which is why the REST payload * showed no difference; node opacity is not in it. * * The dimming is deliberately not ported: at 30% the gutter composites to 1.53:1 and the line to * 1.95:1 against Figma's page, so a loading line would be illegible in either theme. `aria-busy` * carries the state instead. * @default 'active' */ state?: ConsoleMessageState; /** The line itself, rendered in a ``. */ children: React.ReactNode; } /** * @example GET /Lookup?phone=+1XXXXXXXXXX * @example POST /Verify */ export declare const ConsoleMessage: React.ForwardRefExoticComponent>; //# sourceMappingURL=console-message.d.ts.map