@huaweidevtools/aishell-dsh-brand 0.0.4 → 0.0.6

package/lib/types/client/SuggestionCards.d.ts

@@ -0,0 +1,94 @@
+/**
+ * Example-prompt cards for the New-Session hero.
+ *
+ * ## Where this renders, and why it takes a portal to get there
+ *
+ * The entry occupies `conversation.input.dock`, the band between the hero
+ * workspace row and the input card. That is where the strip is MOUNTED — but
+ * not where it is DRAWN: the product wants the cards directly under the hero
+ * headline, and the workspace row sits between the two.
+ *
+ * Measured on the live page (1280×900):
+ *
+ *     hero (headline)              y=288  h=74
+ *     hero workspace row           y=374  h=28
+ *     conversation.input.dock      y=411  h=80
+ *     the input card               y=491
+ *
+ * The row cannot be crossed with a margin — it would be covered — and its DOM
+ * is a sibling subtree, unreachable from the dock. So the strip renders
+ * through `createPortal` into the hero's own content div, the empty `_body`
+ * the official shell leaves for exactly this. See `hero-content.ts` for how
+ * that mount is found and why it fails closed.
+ *
+ * The dock entry is still what supplies the slot props (`useSession`,
+ * `inputActions`, `t`), so the registration is unchanged; the portal only
+ * relocates the output. What the dock band itself renders is nothing.
+ *
+ * ## When it renders
+ *
+ * The dock band renders in BOTH the hero and the docked composer (it only
+ * needs a live input zone), so the gate is `session.blank` — the same
+ * condition the account chip next door uses. `blank` is true from the moment a
+ * New Session opens until the first turn is accepted: exactly the window the
+ * cards exist for. Once the first message is sent the strip renders nothing
+ * and the composer takes over.
+ *
+ * ## Why it does not look like the input card
+ *
+ * The first version read as a second input box, and the reason was measurable
+ * rather than a matter of taste. Both surfaces were built from the same two
+ * ingredients the shell reserves for a composer:
+ *
+ *   - the same neutral one step apart — the card was `bg-module-platform`
+ *     (`#353638` in dark) and the composer `specific-input-major` (`#2c2c2e`),
+ *     both rungs of one ramp, so the two read as siblings;
+ *   - the same box-shadow token. `--dsw-elevation-soft` expands to
+ *     `var(--dsw-elevation-stroke), …`, and that stroke is a
+ *     `0 0 0 .5px` ring — so "no border" had not removed the outline at all,
+ *     it had only moved it into the shadow. Both surfaces carry a hairline.
+ *
+ * The fix is to use the shell's vocabulary for a CHOICE rather than for a
+ * FIELD. Every pickable surface in the product — the option list in the
+ * question card (`border-radius: var(--dsw-radius-md)`, `background: 0 0`),
+ * the command and trigger lists, the portalled menu — draws itself the same
+ * way: a transparent ground, a `radius-md` corner, and a fill that appears
+ * only on hover or selection. A field, by contrast, is an opaque well inset
+ * into the page.
+ *
+ * So a card here is:
+ *
+ *   - TRANSLUCENT, not opaque and not empty. The shell explains this exact
+ *     choice for `SegmentedControl`: a translucent fill "reads as a place
+ *     rather than a second button". Opaque is what made the card a well;
+ *     fully transparent is invisible on a white page, where the light theme
+ *     would leave nothing but floating text. The tint is the shell's own
+ *     interactive pair — `interactive-bg-hover` at rest, `interactive-bg-active`
+ *     on hover — so hovering reads as the same material intensifying;
+ *   - `radius-md` (12px), the choice radius, against the composer's 28px
+ *     `radius-panel`;
+ *   - no shadow at rest. The shell gives an elevated surface a shadow only
+ *     when it FLOATS over other content (a menu, a hovercard, a modal); a
+ *     card sitting inline in the page gets none, so neither does this.
+ *
+ * The icon tile keeps an accent tint — `Tag`'s info tone and the plan
+ * package's chip both paint `color-mix(… business-primary 10%, transparent)`
+ * — on a square with `radius-sm`, matching those chips' geometry.
+ *
+ * ## Auto-rotation
+ *
+ * The strip shows three of four cards, so the fourth would otherwise be
+ * invisible to anyone who does not touch the arrows. It advances one card
+ * every {@link AUTOPLAY_INTERVAL_MS}, pausing on hover, on keyboard focus, in
+ * a background tab, and under `prefers-reduced-motion`. The policy itself
+ * lives in `autoplay.ts`, kept pure so the list of reasons to stop is testable
+ * rather than buried in an effect.
+ *
+ * @module @huaweidevtools/aishell-dsh-brand/client/SuggestionCards
+ */
+import { type ReactNode } from 'react';
+import type { PropsRuntime, PropsLocale } from '@deepseek-ai/dsh-client-ui-slots';
+/** Full component props: the dock band's owner share + the session kit + `t`. */
+export type SuggestionCardsProps = PropsRuntime<'conversation.input.dock'> & PropsLocale<'aishell-brand'>;
+export declare function SuggestionCards(props: SuggestionCardsProps): ReactNode;
+//# sourceMappingURL=SuggestionCards.d.ts.map

package/lib/types/client/autoplay.d.ts

@@ -0,0 +1,67 @@
+/**
+ * Auto-rotation policy for the example-prompt strip.
+ *
+ * Kept apart from the component and free of DOM, for the same reason
+ * `carousel.ts` is: the DECISION is what needs pinning down, and a decision
+ * buried in an effect can only be checked by watching a browser.
+ *
+ * ## Why the strip advances on its own
+ *
+ * The strip shows three of four cards, so a card is always off screen and a
+ * reader who never touches the arrows never learns it exists. Rotation is what
+ * makes the set self-evident. The cost is that content moves without being
+ * asked to, which is why every reason to stop is collected here rather than
+ * decided piecemeal at the call site.
+ *
+ * ## Every reason to stop
+ *
+ *  - `engaged` — the pointer is over the strip or focus is inside it. Someone
+ *    reaching for a card must not have it slide out from under the cursor;
+ *    this is the pause the feature was asked for, and `focus` is the half of
+ *    it that covers a reader who never uses a pointer.
+ *  - `reducedMotion` — the reader asked the platform for less movement. An
+ *    element that moves by itself for more than five seconds is exactly what
+ *    `prefers-reduced-motion` exists to suppress, and a hover pause cannot help
+ *    the reader who cannot hover. Honouring it is what keeps the feature from
+ *    being motion no one consented to.
+ *  - `visible` — the tab is hidden. A background tab still fires timers, so
+ *    without this the strip would churn through slides nobody can see and land
+ *    somewhere arbitrary on return.
+ *  - `ready` — the ring has not been measured yet. Advancing before the step
+ *    is known would move the track by a wrong distance; see the measurement
+ *    note in `SuggestionCards.tsx`.
+ *  - `ring` — three cards or fewer all fit, so there is nowhere to advance to.
+ *    A strip with nothing to scroll must not appear to scroll.
+ *
+ * @module @huaweidevtools/aishell-dsh-brand/client/autoplay
+ */
+/**
+ * How long each card is shown before the strip advances.
+ *
+ * Fixed rather than configurable: this is a hint at what the product can do,
+ * not a reading surface, and a setting nobody asked for is a setting nobody
+ * finds.
+ */
+export declare const AUTOPLAY_INTERVAL_MS = 1500;
+/** Everything that can hold the strip still. */
+export interface AutoplayInputs {
+    /** More cards than fit, so there is somewhere to advance to. */
+    readonly ring: boolean;
+    /** The ring has been measured and the track can be moved a known distance. */
+    readonly ready: boolean;
+    /** The pointer is over the strip, or focus is inside it. */
+    readonly engaged: boolean;
+    /** The reader asked for reduced motion. */
+    readonly reducedMotion: boolean;
+    /** The tab is on screen. */
+    readonly visible: boolean;
+}
+/**
+ * Whether the strip should be advancing on its own right now.
+ *
+ * Expressed as one predicate rather than a chain of early returns inside the
+ * timer, so that adding a reason to stop is a change to this list and its
+ * test — not a change to the effect that schedules the ticks.
+ */
+export declare function autoplayActive(inputs: AutoplayInputs): boolean;
+//# sourceMappingURL=autoplay.d.ts.map

package/lib/types/client/carousel.d.ts

@@ -0,0 +1,96 @@
+/**
+ * Carousel position maths, kept pure so it can be tested without a DOM.
+ *
+ * The strip is a RING, not a scroll range: the cards form a circle, and an
+ * arrow steps one card around it forever. Clicking next from the last
+ * position lands on the first, and clicking prev from the first lands on the
+ * last — and crucially, every intermediate position exists. A four-card ring
+ * showing three at a time has FOUR positions, not two:
+ *
+ *      cards 1 2 3 4, three visible
+ *      pos 0 → [1 2 3]
+ *      pos 1 → [2 3 4]
+ *      pos 2 → [3 4 1]     ← the wrap is visible, not a jump back
+ *      pos 3 → [4 1 2]
+ *      pos 4 → [1 2 3]     same as pos 0
+ *
+ * A plain scroll container cannot express that: its range is only
+ * `content - viewport` (one step, for four cards), and positions 2 and 3 have
+ * no place to live. So the card list is rendered {@link COPIES} times over
+ * and the window travels through the middle copy, where both neighbours
+ * always have content.
+ *
+ * ## Why the copies, and how the seam stays invisible
+ *
+ * With the list rendered three times, a window at physical position `p` shows
+ * `cards[p .. p+VISIBLE-1]`, and position `2n` shows exactly what position `n`
+ * shows. That equivalence is the seam: once a slide settles at `2n`, the
+ * track can be placed at `n` in the same frame with transitions off, and
+ * nothing on screen changes. The same holds at the other end, where `n-1` and
+ * `2n-1` are the same window.
+ *
+ * The rewind happens only AFTER the slide finishes — never before. Jumping
+ * first would put the destination on screen instantly and then animate away
+ * from it, so a click at the seam would appear to skip a card. This is the
+ * one law in this module that a reader is likely to get backwards.
+ *
+ * @module @huaweidevtools/aishell-dsh-brand/client/carousel
+ */
+/**
+ * How many times the card list is rendered.
+ *
+ * Three is the minimum that works. The window lives in the middle copy, so it
+ * needs one full copy behind it (to show the cards before the start) and one
+ * ahead (to show the cards past the end while a slide is finishing at the
+ * seam, where the position may briefly reach `2n` and read up to
+ * `2n + VISIBLE - 1`).
+ */
+export declare const COPIES = 3;
+/** How many cards to render for a ring of `n`. */
+export declare function ringLength(n: number): number;
+/**
+ * The physical position the ring starts at — the first card of the middle
+ * copy. Starting here rather than at 0 is what makes the very first prev
+ * click land on a real card instead of an empty track.
+ */
+export declare function ringStart(n: number): number;
+/**
+ * Where a settled position should be silently rewound to, or `null` when it
+ * is already inside the working band.
+ *
+ * The band is `[n, 2n-1]`. A slide may finish one past either end — `2n`
+ * going forward, `n-1` going backward — and both have an exact twin inside
+ * the band. See the module note for why this runs after the slide, not
+ * before.
+ */
+export declare function rewindTo(pos: number, n: number): number | null;
+/** One arrow press, resolved into the physical positions involved. */
+export interface RingStep {
+    /**
+     * Where the track must be placed with transitions OFF before the slide.
+     * Equal to the incoming position when no rewind is due; when it differs,
+     * the jump is invisible (both positions show the same window).
+     */
+    readonly from: number;
+    /**
+     * Where the slide ends. May sit one past the band's end, in which case the
+     * next {@link rewindTo} brings it back.
+     */
+    readonly to: number;
+}
+/**
+ * Resolve one arrow press on a ring.
+ *
+ * Any rewind still owed from the previous press is settled first, so a person
+ * clicking faster than the slide animation cannot walk the window off the
+ * rendered copies — the band always absorbs one more step.
+ */
+export declare function ringStep(pos: number, delta: number, n: number): RingStep;
+/**
+ * One arrow press on a plain strip (fewer cards than fit): step by one and
+ * stay inside the scrollable range.
+ *
+ * @param maxPos - the last meaningful position, `0` when nothing scrolls.
+ */
+export declare function clampStep(pos: number, delta: number, maxPos: number): number;
+//# sourceMappingURL=carousel.d.ts.map

package/lib/types/client/hero-content.d.ts

@@ -0,0 +1,70 @@
+/**
+ * The mount point the suggestion strip renders into, inside the hero.
+ *
+ * ## Why a portal, and not CSS placement
+ *
+ * The strip is a `conversation.input.dock` entry, and that band renders BELOW
+ * the hero workspace row in the composer stack. Measured on the live page
+ * (1280×900, DSH 0.2.x):
+ *
+ *     hero (headline)              y=288  h=74
+ *     hero workspace row           y=374  h=28
+ *     conversation.input.dock      y=411  h=80
+ *     the input card               y=491
+ *
+ * The product wants the cards directly under the headline, and the workspace
+ * row sits between. A negative margin cannot cross it — the row would be
+ * covered — and the row's own subtree is not reachable from the dock, since
+ * the two are separate children of the composer stack.
+ *
+ * The hero, however, already renders an empty content div for exactly this
+ * purpose. Its stack is: headline → (the "Powered by" label) → `_body`, where
+ * `_body` is `flex-direction: column` and left empty by the official shell.
+ * That is the hero's content area, and putting the cards there is using the
+ * slot as intended rather than fighting the layout.
+ *
+ * ## How the mount is found
+ *
+ * By the hero's own class suffix, from the headline outward — `[class*="_body"]`
+ * alone is ambiguous (the conversation root has a `_body` too, and the live
+ * page has two). So the search starts at a `[class*="_headline"]`, steps to its
+ * parent (the hero stack), and takes that stack's own `_body` child. The
+ * headline is unique on the page and is what makes the walk unambiguous.
+ *
+ * Children are walked directly rather than with `:scope >`. The two are
+ * equivalent here, and the direct walk keeps these helpers working against the
+ * hand-rolled DOM stub the specs use (which has no selector engine) instead of
+ * leaving the module's real logic untested.
+ *
+ * The classes are CSS-module hashes (`pXSMma_body`), hence the suffix match.
+ * A base bump that renames them fails closed: {@link findHeroContent} returns
+ * null, the portal renders nothing, and the arrows and cards simply do not
+ * appear — the strip is never left in the wrong parent.
+ *
+ * @module @huaweidevtools/aishell-dsh-brand/client/hero-content
+ */
+/**
+ * The hero's content area, or `null` when the hero is not on screen.
+ *
+ * Returns null rather than throwing: a New Session that has not painted its
+ * hero yet is a normal state (and the strip retries on the next frame), not an
+ * error.
+ */
+export declare function findHeroContent(target: Document): HTMLElement | null;
+/**
+ * A container for the strip inside the hero content area.
+ *
+ * The hero body is `display: block` and zero-height, so the strip cannot rely
+ * on it for layout and must not inherit that block context. The wrapper is
+ * created here rather than rendered by React into the official div, because
+ * React does not own that node — it owns only what the portal puts inside.
+ */
+export declare function ensureHeroMount(content: HTMLElement): HTMLElement;
+/**
+ * Remove the mount this module created, if it is still there.
+ *
+ * Only the mount is removed — never the host div, which belongs to the shell
+ * and is reused on the next New Session.
+ */
+export declare function removeHeroMount(content: HTMLElement): void;
+//# sourceMappingURL=hero-content.d.ts.map

package/lib/types/client/index.d.ts

@@ -8,7 +8,7 @@
  * @module @huaweidevtools/aishell-dsh-brand/client
  */
 import type { Context as ClientContext } from '@deepseek-ai/cordis';
-/** Required service: the UI slot registry. */
+/** Required services: the UI slot registry and the locale registry. */
 export declare const inject: string[];
 export declare function apply(ctx: ClientContext): void;
 //# sourceMappingURL=index.d.ts.map

package/lib/types/client/locales.d.ts

@@ -0,0 +1,66 @@
+/**
+ * aishell brand locale dictionaries.
+ *
+ * The brand plugin owns its own namespace rather than reusing `aishell`
+ * (which `aishell-credentials` registers): a namespace's texts have exactly
+ * one owner, and a duplicate `(ns, locale)` registration throws.
+ *
+ * ## Why content lives in a dictionary
+ *
+ * The suggestion cards are the only strings in this plugin a person reads,
+ * and they are CONTENT rather than interface chrome — a card title, its
+ * one-line gloss, and the prompt a click inserts. They still belong here:
+ * a card that says「云资源查询」to an English reader is worse than no card,
+ * and the prompt it inserts would start an English conversation in Chinese.
+ *
+ * Chinese is the key-set source of truth; English is complete against it and
+ * is also the terminal fallback, so every locale other than `zh` reads
+ * English. That is the framework's own chain (`LOCALE_IDS = ["zh", "en"]`,
+ * with English carrying no fallback) — there is no third dictionary to write.
+ *
+ * @module @huaweidevtools/aishell-dsh-brand/client/locales
+ */
+/** Dictionary namespace owned by this plugin. */
+export declare const NS: "aishell-brand";
+/** Simplified Chinese dictionary (the key-set source of truth). */
+export declare const zh: {
+    readonly 'suggestion.previous': "上一个示例";
+    readonly 'suggestion.next': "下一个示例";
+    readonly 'suggestion.inventory.title': "云资源查询";
+    readonly 'suggestion.inventory.gloss': "列出当前账号下的云资源";
+    readonly 'suggestion.inventory.prompt': "请列出我的华为云资源清单，按服务分类（计算、存储、网络、数据库等），标出每类资源的数量和所在区域。";
+    readonly 'suggestion.deploy.title': "部署方案推荐";
+    readonly 'suggestion.deploy.gloss': "按访问量和预算给出可落地的部署路径";
+    readonly 'suggestion.deploy.prompt': "我要部署一个轻量级 Web 应用，请对比几种可行的部署方案，说明各自的适用规模、月度成本量级和运维复杂度，并给出你的推荐及理由。";
+    readonly 'suggestion.enterprise.title': "企业上云";
+    readonly 'suggestion.enterprise.gloss': "多账号、网络分区与权限边界的整体设计";
+    readonly 'suggestion.enterprise.prompt': "请为我规划一套云上 Landing Zone 架构，覆盖账号组织结构、网络分区、权限边界与审计要求，并说明各部分的设计取舍。";
+    readonly 'suggestion.billing.title': "账单分析";
+    readonly 'suggestion.billing.gloss': "分析上个月的云资源支出";
+    readonly 'suggestion.billing.prompt': "请分析我上个月的云资源支出构成，找出占比最高的几项服务，指出其中可以优化或降配的部分，并估算调整后能节省多少。";
+};
+/** English dictionary. Complete against {@link zh}; also the terminal fallback. */
+export declare const en: {
+    readonly 'suggestion.previous': "Previous example";
+    readonly 'suggestion.next': "Next example";
+    readonly 'suggestion.inventory.title': "Cloud inventory";
+    readonly 'suggestion.inventory.gloss': "List the resources in this account";
+    readonly 'suggestion.inventory.prompt': string;
+    readonly 'suggestion.deploy.title': "Deployment options";
+    readonly 'suggestion.deploy.gloss': "A workable path for your traffic and budget";
+    readonly 'suggestion.deploy.prompt': string;
+    readonly 'suggestion.enterprise.title': "Landing zone";
+    readonly 'suggestion.enterprise.gloss': "Multi-account structure, network and permission boundaries";
+    readonly 'suggestion.enterprise.prompt': string;
+    readonly 'suggestion.billing.title': "Billing analysis";
+    readonly 'suggestion.billing.gloss': "Break down last month's cloud spend";
+    readonly 'suggestion.billing.prompt': string;
+};
+/** Every key, derived from the zh dictionary (the source of truth). */
+export type AishellBrandLocaleKey = keyof typeof zh;
+declare module '@deepseek-ai/dsh-client-ui-slots' {
+    interface LocaleNamespaceMap {
+        'aishell-brand': AishellBrandLocaleKey;
+    }
+}
+//# sourceMappingURL=locales.d.ts.map

package/lib/types/client/suggestion-icons.d.ts

@@ -0,0 +1,45 @@
+/**
+ * Inline SVG artwork for the suggestion cards.
+ *
+ * Inline rather than an icon dependency: the strip draws four shapes, and a
+ * dependency would add a package, a version to track, and a bundle face to
+ * keep in step with the host.
+ *
+ * Every path is drawn on a 24×24 viewBox with `currentColor`, so a card
+ * decides the colour by setting `color` and nothing here hard-codes a theme
+ * value.
+ *
+ * ## Shape rules, learned by getting them wrong
+ *
+ * The first draft drew "deploy" as a box with an arrow leaving it — which
+ * reads as SHARE or export, the one meaning this card must not carry. A
+ * glyph in a row of four is read at a glance and out of context, so each one
+ * has to be recognisable on its own:
+ *
+ *   - nothing may resemble the share glyph (box + outward arrow) or the
+ *     external-link glyph (box + arrow through a corner);
+ *   - every shape is closed and filled-ish in silhouette, because outlines
+ *     at 20px in a row of four blur into each other;
+ *   - no glyph carries more than three strokes, so they stay distinguishable
+ *     at the size they are actually drawn.
+ *
+ * These rules are not machine-checked: rendering the glyphs needs
+ * `react-dom/server`, which this repo does not depend on, and vitest here
+ * collects only `.spec.ts` (not `.tsx`). The browser harness in
+ * `scripts/render-check/` is what actually puts them on screen.
+ *
+ * @module @huaweidevtools/aishell-dsh-brand/client/suggestion-icons
+ */
+import type { ReactNode } from 'react';
+import type { SuggestionIcon } from './suggestions.ts';
+/** Props shared by every glyph. */
+interface IconProps {
+    /** Rendered size in px; the cards use 20. */
+    readonly size?: number;
+}
+/** Resolve one icon key to its glyph. */
+export declare function SuggestionIconArt({ icon, size, }: IconProps & {
+    readonly icon: SuggestionIcon;
+}): ReactNode;
+export {};
+//# sourceMappingURL=suggestion-icons.d.ts.map

package/lib/types/client/suggestions.d.ts

@@ -0,0 +1,118 @@
+/**
+ * The New-Session example cards, and the shapes they need.
+ *
+ * One array drives the whole strip: add or reorder a card by editing
+ * `SUGGESTIONS` and adding its three keys to `locales.ts`, and nothing else.
+ * The row renders whatever it is given — three or fewer display side by side
+ * with no arrows, more than three become a carousel.
+ *
+ * ## This file holds no copy
+ *
+ * Every string a person reads — the card title, its one-line gloss, and the
+ * prompt a click inserts — lives in `locales.ts`, addressed by the keys here.
+ * A card whose text were inlined would be readable in exactly one language,
+ * and the prompt it inserted would start a conversation in that language no
+ * matter what the reader's locale was.
+ *
+ * The three keys per card are separate rather than one blob because the
+ * surfaces differ: the card shows `title` and `gloss` (both clamped — one
+ * line and two lines — so a long string ellipsizes instead of breaking the
+ * row), while `prompt` goes to the composer and is never displayed on the
+ * card. A prompt that only restates its title makes the click pointless;
+ * written as a pair, the prompt carries the context and the expected output
+ * that make the first message worth sending without editing.
+ *
+ * ## Sizing, when editing copy
+ *
+ * Three cards share one row, which at the default column leaves roughly 150px
+ * per title — about seven CJK glyphs, or noticeably more Latin ones. Measured
+ * against the shipped set: every title fits at 560px and above, and all four
+ * clip below ~460px. Keep them within a couple of characters of each other —
+ * the longest one is otherwise the only card that ever shows an ellipsis,
+ * which reads as a bug rather than as a long name.
+ *
+ * @module @huaweidevtools/aishell-dsh-brand/client/suggestions
+ */
+import type { AishellBrandLocaleKey } from './locales.ts';
+/** One example card: what it looks like, and what a click inserts. */
+export interface Suggestion {
+    /**
+     * Stable identity for React keys and for the carousel's position maths.
+     * Not shown to anyone — it names the dictionary key prefix, so renaming it
+     * means renaming three keys in `locales.ts`.
+     */
+    readonly id: string;
+    /** Icon key resolved by {@link SuggestionIconArt}. */
+    readonly icon: SuggestionIcon;
+    /** The tile colour, measured to work in both themes. See {@link SuggestionHue}. */
+    readonly hue: SuggestionHue;
+    /** Dictionary key for the card's one-line title. */
+    readonly titleKey: AishellBrandLocaleKey;
+    /** Dictionary key for the line under the title. */
+    readonly glossKey: AishellBrandLocaleKey;
+    /** Dictionary key for the text inserted into the composer. */
+    readonly promptKey: AishellBrandLocaleKey;
+}
+/** The icon set this strip can draw. Keys are local to this plugin. */
+export type SuggestionIcon = 'cloud' | 'deploy' | 'architecture' | 'cost';
+/**
+ * The tile colour for one card, as the shell's own token names.
+ *
+ * ## Why each card carries its own hue
+ *
+ * The first version drew every icon in one accent, on the reasoning that four
+ * hues beside the brand mark would read as noise. That was a guess, and the
+ * shell contradicts it: `FileTypeIcon` gives every item in a row its own hue
+ * (`code` blue, `excel` green, `folder` amber, `image` violet), which is the
+ * same situation — a row of small glyphs read at a glance — and it chooses
+ * per-item colour. Colour is what makes such a row scannable rather than a
+ * wall of identical tiles.
+ *
+ * ## These are STATIC tokens, not the semantic ones
+ *
+ * `--dsw-alias-state-success-primary` and friends mean "the operation
+ * succeeded" / "this needs attention". A card about cost is not a warning, so
+ * borrowing the warning colour would be a lie the palette tells. The `static`
+ * family is the one intended for decorative identity, which is exactly what a
+ * card's hue is — and `FileTypeIcon` reaches for the same family.
+ *
+ * ## The values were chosen by measurement, in both themes
+ *
+ * Violet is the exception: the design platform ships NO violet token, so
+ * `FileTypeIcon` defines one locally (`rgb(139, 118, 246)`) for its own
+ * artwork. The same value is reused here rather than inventing a second one,
+ * and it is the only literal colour in this plugin.
+ *
+ * The four were picked to clear three bars at once, in both themes:
+ *
+ *   - glyph on its tile >= 4.5 — measured 5.42 at worst (violet);
+ *   - tile against the card >= 1.6 — measured 2.05 at worst;
+ *   - worst pairwise colour distance >= 30 (CIE76 dE) — measured 38.7.
+ *
+ * The last bar is the one that matters for "four colours, not one blur": an
+ * obvious-looking pick like blue + violet measures only 17.5 apart, which is
+ * why this is measured rather than eyeballed.
+ */
+export interface SuggestionHue {
+    /**
+     * The tile fill. A SOLID hue, with the glyph in `--dsw-alias-label-primary-
+     * foreground` on top.
+     *
+     * A tint of the hue was the first attempt and it measured badly: a glyph
+     * drawn in a hue on top of a tint of that same hue has almost nothing to
+     * separate them, so the contrast was 1.8–2.8 — and RAISING the tint made it
+     * worse, since more of the hue behind the glyph means less difference from
+     * it. A solid tile puts the glyph on full-strength colour instead, which
+     * measured 5.4–9.9 for the same hues.
+     */
+    readonly tile: string;
+}
+/**
+ * The cards, in display order.
+ *
+ * Order matters only for the ring's starting window: the strip opens on the
+ * first {@link VISIBLE} cards, so the first entries are the ones a person
+ * sees without pressing an arrow.
+ */
+export declare const SUGGESTIONS: readonly Suggestion[];
+//# sourceMappingURL=suggestions.d.ts.map

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@huaweidevtools/aishell-dsh-brand",
   "description": "AI Shell brand reskin for DSH web — replaces sidebar and hero brand marks with AI Shell SVG",
-  "version": "0.0.4",
+  "version": "0.0.6",
   "publishConfig": {
     "access": "public"
   },
@@ -30,7 +30,8 @@
       "inject": [
         "@deepseek-ai/dsh-client-ui-renderer",
         "@deepseek-ai/dsh-client-ui-sidebar",
-        "@deepseek-ai/dsh-client-ui-conversation"
+        "@deepseek-ai/dsh-client-ui-conversation",
+        "@deepseek-ai/dsh-client-locale"
       ],
       "platform": "web"
     },
@@ -44,12 +45,15 @@
   },
   "devDependencies": {
     "@deepseek-ai/cordis": "^4.0.4",
-    "@deepseek-ai/dsh-client-ui-conversation": ">=0.2.0-0 <0.3.0-0",
-    "@deepseek-ai/dsh-client-ui-renderer": ">=0.2.0-0 <0.3.0-0",
-    "@deepseek-ai/dsh-client-ui-sidebar": ">=0.2.0-0 <0.3.0-0",
-    "@deepseek-ai/dsh-client-ui-slots": ">=0.2.0-0 <0.3.0-0",
+    "@deepseek-ai/dsh-client-locale": "0.2.0-rc.1 || 0.2.1-rc.1 || 0.2.1-rc.2 || 0.2.1",
+    "@deepseek-ai/dsh-client-ui-conversation": "0.2.0-rc.1 || 0.2.1-rc.1 || 0.2.1-rc.2 || 0.2.1",
+    "@deepseek-ai/dsh-client-ui-renderer": "0.2.0-rc.1 || 0.2.1-rc.1 || 0.2.1-rc.2 || 0.2.1",
+    "@deepseek-ai/dsh-client-ui-sidebar": "0.2.0-rc.1 || 0.2.1-rc.1 || 0.2.1-rc.2 || 0.2.1",
+    "@deepseek-ai/dsh-client-ui-slots": "0.2.0-rc.1 || 0.2.1-rc.1 || 0.2.1-rc.2 || 0.2.1",
     "@types/react": "~18.3.1",
+    "@types/react-dom": "~18.3.1",
     "react": "^18.2.0",
+    "react-dom": "^18.2.0",
     "tsdown": "^0.10.0",
     "typescript": "^5.7.0"
   },