@gaia-ai/addon-gaia-ui 0.13.1 → 0.14.0

package/dist/src/Component/footer-actions/index.js

@@ -99,11 +99,13 @@ export const parseFooterLadder = (ladder, idPrefix = 'footer-action') => {
         .map((s) => s.trim())
         .filter((s) => s !== '');
     const items = [];
-    for (let i = 0; i < segments.length; i += 1) {
-        const m = /^(\S+)(?:\s+(.+))?$/.exec(segments[i]);
+    for (const [i, seg] of segments.entries()) {
+        const m = /^(\S+)(?:\s+(.+))?$/.exec(seg);
         if (m === null)
             continue;
         const key = m[1];
+        if (key === undefined)
+            continue;
         const label = m[2];
         items.push(actionItem(`${idPrefix}-${i}`, key, label));
     }

package/dist/src/Component/list-chrome/index.js

@@ -9,7 +9,7 @@ import { BACKGROUND_ACTIVE, BORDER, DEFAULT_BACKGROUND, FOREGROUND, FOREGROUND_A
  */
 export const filterBadgeStrip = (id, badges) => {
     const nodes = [];
-    for (let index = 0; index < badges.length; index += 1) {
+    for (const [index, badge] of badges.entries()) {
         if (index > 0) {
             nodes.push(textNode({
                 id: `${id}-gap-${index}`,
@@ -18,7 +18,6 @@ export const filterBadgeStrip = (id, badges) => {
                 fg: BORDER,
             }));
         }
-        const badge = badges[index];
         const value = badge.value;
         const active = value !== undefined && value !== '';
         const label = active ? value : badge.label;

package/dist/src/Component/markdown/index.d.ts

@@ -24,6 +24,11 @@ export declare const styledRunOf: (span: MarkdownSpan) => StyledRun;
  * reads a span's flags.
  */
 export declare const styledLineOf: (line: MarkdownLine) => StyledLine;
+/**
+ * The inverse of {@link styledLineOf}: already-painted runs as parser lines,
+ * so a React painter can consume production rows without a source round trip.
+ */
+export declare const markdownLineFromStyled: (line: StyledLine) => MarkdownLine;
 /** A `gaia_rich` body as the physical rows a surface draws or prints — D1. */
 export declare function markdownLines(body: string): StyledLine[];
 /** A line NOTHING parses — one unstyled run (D3's plain path, as a value). */

package/dist/src/Component/markdown/index.js

@@ -74,6 +74,21 @@ export const styledLineOf = (line) => ({
     runs: line.spans.map(styledRunOf),
     heading: line.heading,
 });
+/**
+ * The inverse of {@link styledLineOf}: already-painted runs as parser lines,
+ * so a React painter can consume production rows without a source round trip.
+ */
+export const markdownLineFromStyled = (line) => ({
+    text: line.text,
+    heading: line.heading,
+    spans: line.runs.map((run) => ({
+        text: run.text,
+        ...((run.attributes & BOLD) !== 0 ? { bold: true } : {}),
+        ...((run.attributes & ITALIC) !== 0 ? { italic: true } : {}),
+        ...((run.attributes & DIM) !== 0 ? { dim: true } : {}),
+        ...(run.fg !== undefined ? { code: true } : {}),
+    })),
+});
 /** A `gaia_rich` body as the physical rows a surface draws or prints — D1. */
 export function markdownLines(body) {
     return parseMarkdown(body).map(styledLineOf);

package/dist/src/Component/section-list/index.d.ts

@@ -173,7 +173,7 @@ export declare const panelSectionKey: (heading: string) => string;
  * The one description of what a section renders as. {@link flattenSections}
  * derives the row surface from it and a converted screen derives its nodes from
  * it, so the two cannot answer differently for the same document — which is the
- * property that lets the Dashboard hand over renderables while its pipe keeps
+ * property that lets Stats hand over renderables while its pipe keeps
  * emitting the bytes it always did (spec F5).
  */
 export declare function sectionRows(sections: Section[], keyOf?: (heading: string) => string): SectionRow[];

package/dist/src/Component/section-list/index.js

@@ -131,7 +131,7 @@ export const panelSectionKey = (heading) => Array.from(new TextEncoder().encode(
  * The one description of what a section renders as. {@link flattenSections}
  * derives the row surface from it and a converted screen derives its nodes from
  * it, so the two cannot answer differently for the same document — which is the
- * property that lets the Dashboard hand over renderables while its pipe keeps
+ * property that lets Stats hand over renderables while its pipe keeps
  * emitting the bytes it always did (spec F5).
  */
 export function sectionRows(sections, 

package/dist/src/Component/stats-panel/index.js

@@ -1,9 +1,9 @@
-// GAIA-256 spec D11 — the Dashboard's `/usage`-style bar rows.
+// GAIA-256 spec D11 — Stats' `/usage`-style bar rows.
 //
 // A SHARED component (the third in `src/Component/`), and it earns that place by
 // carrying no entity vocabulary at all: it takes `{ label, numbers }` and draws
 // bars. Nothing here knows a ticket from a run from a project — which is exactly
-// what G4 asserts, and why the Dashboard can render four different blocks from
+// what G4 asserts, and why Stats can render four different blocks from
 // one function.
 //
 // It produces the ROWS OF ONE BLOCK. Stacking blocks under bold headings is

package/dist/src/Component/team-member-workload-list/index.d.ts

@@ -0,0 +1,9 @@
+import type { SectionLine } from '../section-list/index.js';
+export interface TeamMemberWorkloadListItem {
+    userId: string;
+    label: string;
+    open: number;
+    running: number;
+    waiting: number;
+}
+export declare function teamMemberWorkloadRows(members: readonly TeamMemberWorkloadListItem[]): SectionLine[];

package/dist/src/Component/team-member-workload-list/index.js

@@ -0,0 +1,31 @@
+const countCell = (text) => ({
+    text,
+    width: 9,
+    right: true,
+});
+export function teamMemberWorkloadRows(members) {
+    const memberCell = (text) => ({
+        text,
+        width: 24,
+        min: 12,
+        grow: 1,
+    });
+    return [
+        {
+            cells: [
+                memberCell('Member'),
+                countCell('Open'),
+                countCell('Running'),
+                countCell('Waiting'),
+            ],
+        },
+        ...members.map((member) => ({
+            cells: [
+                memberCell(member.label),
+                countCell(String(member.open)),
+                countCell(String(member.running)),
+                countCell(String(member.waiting)),
+            ],
+        })),
+    ];
+}

package/dist/src/Component/top-tabs/index.d.ts

@@ -1,315 +1,17 @@
-/** One top-level TUI tab: its id and label. */
+/** Tab rendering is independent of registration and routing. */
 export interface TopTab {
     id: string;
     label: string;
 }
-/** The root level: what there is before a project is chosen. */
-export declare const ROOT_TABS: readonly [{
-    readonly id: "dashboard";
-    readonly label: "Dashboard";
-}, {
-    readonly id: "projects";
-    readonly label: "Projects";
-}, {
-    readonly id: "conductors";
-    readonly label: "Conductors";
-}, {
-    readonly id: "teams";
-    readonly label: "Teams";
-}];
-/**
- * The project level: the tabs of an opened project.
- *
- * GAIA-450 added `conductors` (`ProjectConductorsScreen`, `project.conductors`,
- * order 50) — LAST, by the same "which project it serves is a COLUMN of that
- * screen" argument GAIA-232 made for the root level, applied the other way:
- * once a project IS chosen, seeing who serves it is a natural final stop
- * beside Tickets, Ticket-Agents and Runs. Missing here — as it was for one
- * `coding` pass, review B11 — makes the screen and its route entirely
- * unreachable by Tab or click: `tabsOfLocation` reads this list, not the
- * route registry's `tab` metadata, for what a level cycles through.
- */
-export declare const PROJECT_TABS: readonly [{
-    readonly id: "dashboard";
-    readonly label: "Dashboard";
-}, {
-    readonly id: "tickets";
-    readonly label: "Tickets";
-}, {
-    readonly id: "ticket-agents";
-    readonly label: "Ticket-Agents";
-}, {
-    readonly id: "runs";
-    readonly label: "Runs";
-}, {
-    readonly id: "conductors";
-    readonly label: "Conductors";
-}];
-/**
- * The ticket level: the sections of ONE OPEN TICKET — GAIA-346.
- *
- * The third level this file's GAIA-239 comment has described since it was
- * written, arriving with the change that needed it. What is new is not the level
- * but where it is DRAWN: that comment reserved it for "the header box's meta row,
- * so no top-level bar at all", and the operator's ruling is the opposite — the
- * sections belong in the bar every other level uses, and the ticket detail keeps
- * no tab row of its own.
- *
- * These entries are NOT destinations. A section is a mode of the one ticket
- * route: switching one runs no `Router.navigate`, so the screen instance, its
- * document and its per-section state are untouched (spec D1/F3). The kernel
- * learns that from the screen, through `Screen.selectTopTab`, and not from a
- * level name — nothing in this file distinguishes a mode from a destination, and
- * nothing should.
- *
- * `runs` is declared here AND on the project level, which GAIA-256 D2 already
- * made legal: ids are not globally unique, every function is level-parameterised,
- * and one bar is on screen at a time.
- */
-export declare const TICKET_TABS: readonly [{
-    readonly id: "overview";
-    readonly label: "Overview";
-}, {
-    readonly id: "comments";
-    readonly label: "Comments";
-}, {
-    readonly id: "related";
-    readonly label: "Related";
-}, {
-    readonly id: "runs";
-    readonly label: "Runs";
-}];
-/**
- * The team level: Overview · Users for one crew — GAIA-391 AC4, by operator
- * ruling.
- *
- * The level the `users` root tab BECAME. It sits between root and user, so the
- * navigation reads root → team → user: which crews are there, who is in this
- * one, what has that person done. Destinations, not modes — each tab is its own
- * screen, so Tab runs a real `Router.navigate` and `teamId` is preserved
- * (`Routing/registry.ts` keeps the params for this scope for the same reason it
- * keeps them for `project` and `user`).
- *
- * `overview` is also declared on the user level, which GAIA-256 D2 already made
- * legal: ids are not globally unique, every function here is level-parameterised,
- * and one bar is on screen at a time.
- */
-export declare const TEAM_TABS: readonly [{
-    readonly id: "overview";
-    readonly label: "Overview";
-}, {
-    readonly id: "users";
-    readonly label: "Users";
-}];
-/**
- * The user level: Overview · Tickets · Runs for one person (GAIA-377 D1).
- *
- * Destinations, not modes — each tab is its own screen in the slice that owns
- * its query (D2), so Tab runs a real `Router.navigate` and preserves `userId`.
- *
- * UNCHANGED by GAIA-391: the ruling moved this level's PARENT (it hangs off
- * {@link TEAM_TABS} now instead of off a root `users` tab), not its contents.
- */
-export declare const USER_TABS: readonly [{
-    readonly id: "overview";
-    readonly label: "Overview";
-}, {
-    readonly id: "tickets";
-    readonly label: "Tickets";
-}, {
-    readonly id: "runs";
-    readonly label: "Runs";
-}];
-/**
- * The tab bars, keyed by level — the one place a level is named.
- *
- * Declared in DEPTH order (root → project → ticket, then team → user), which is
- * documentation rather than mechanism: nothing reads this object in key order
- * since GAIA-256 D2 deleted `locateTab`, the one function that did.
- */
-export declare const TAB_LEVELS: {
-    readonly root: readonly [{
-        readonly id: "dashboard";
-        readonly label: "Dashboard";
-    }, {
-        readonly id: "projects";
-        readonly label: "Projects";
-    }, {
-        readonly id: "conductors";
-        readonly label: "Conductors";
-    }, {
-        readonly id: "teams";
-        readonly label: "Teams";
-    }];
-    readonly project: readonly [{
-        readonly id: "dashboard";
-        readonly label: "Dashboard";
-    }, {
-        readonly id: "tickets";
-        readonly label: "Tickets";
-    }, {
-        readonly id: "ticket-agents";
-        readonly label: "Ticket-Agents";
-    }, {
-        readonly id: "runs";
-        readonly label: "Runs";
-    }, {
-        readonly id: "conductors";
-        readonly label: "Conductors";
-    }];
-    readonly ticket: readonly [{
-        readonly id: "overview";
-        readonly label: "Overview";
-    }, {
-        readonly id: "comments";
-        readonly label: "Comments";
-    }, {
-        readonly id: "related";
-        readonly label: "Related";
-    }, {
-        readonly id: "runs";
-        readonly label: "Runs";
-    }];
-    readonly team: readonly [{
-        readonly id: "overview";
-        readonly label: "Overview";
-    }, {
-        readonly id: "users";
-        readonly label: "Users";
-    }];
-    readonly user: readonly [{
-        readonly id: "overview";
-        readonly label: "Overview";
-    }, {
-        readonly id: "tickets";
-        readonly label: "Tickets";
-    }, {
-        readonly id: "runs";
-        readonly label: "Runs";
-    }];
-};
-/** The name of a level that carries a top-level tab bar. */
-export type TabLevel = keyof typeof TAB_LEVELS;
-/** The ids of one level's tabs, derived from {@link TAB_LEVELS}. */
-export type TabIdOf<L extends TabLevel> = (typeof TAB_LEVELS)[L][number]['id'];
-/**
- * The id of any top-level tab, derived — never re-listed. Before GAIA-239 this
- * union was hand-written in `tui-kernel.ts` alongside a third hardcoded copy of
- * the same ids for the Tab cycle order; the three could drift silently.
- */
-export type TopTabId = {
-    [L in TabLevel]: TabIdOf<L>;
-}[TabLevel];
-/**
- * Where a screen sits in the navigation: which bar it draws, and which tab of
- * that bar is its own. A discriminated union over the levels, so a location can
- * never pair one level's name with another level's tab id.
- *
- * GAIA-373 D5/D6 — the `ticket` arm is the one that is NOT a literal union, and
- * it is also the one that carries an optional bar of its own. Both halves have
- * the same cause: the ticket level is not a DESTINATION level.
- * `router.navigateTab` is never reached for it, because `selectTopTab` claims
- * every ticket tab (GAIA-346 D4), so the literal union that protects root/project
- * NAVIGATION has no target here — while a contributed section mode
- * (`gaia/artifacts`) is data from the contribution store and cannot be a literal
- * in this file at all. Root and project keep theirs intact, so
- * `topTabBar('root', 'runs')` is still a TS2345.
- *
- * `tabs` is read by BOTH bar builders below and by the kernel's Tab cycle, so
- * the bar drawn, the bar clicked and the bar cycled are three readings of one
- * field rather than three answers.
- */
-export type TabLocation = {
-    level: 'root';
-    tab: TabIdOf<'root'>;
-} | {
-    level: 'project';
-    tab: TabIdOf<'project'>;
-} | {
-    level: 'ticket';
+export interface TabLocation {
+    level: string;
     tab: string;
-    tabs?: readonly TopTab[];
-} | {
-    level: 'team';
-    tab: TabIdOf<'team'>;
-} | {
-    level: 'user';
-    tab: TabIdOf<'user'>;
-};
-/** The entries a location draws: its own, else its level's registry. */
-export declare const tabsOfLocation: (location: TabLocation) => readonly TopTab[];
-/**
- * The bar as the PIECES it is drawn from: one part per tab, carrying that tab's
- * id, with the joins between them carrying none.
- *
- * GAIA-340 Task 11 (spec D6) — this replaces `topTabSpans`, which published the
- * same layout as `[start, end)` COLUMN ranges for the kernel to resolve a click
- * against. The bar is a row of renderables now (`Kernel/chrome.ts`), so "which
- * tab is under the pointer" is answered by the renderer's own hit test — the
- * part the pointer landed on IS a node, and its id names its tab. A column map
- * beside that would be a second answer to a question the renderer already
- * answers, and it needed `displayWidth` to build, which is exactly the string
- * measurement this ticket exists to delete (R5/D8).
- *
- * The argument the spans made survives unchanged, and is why the parts are here
- * rather than in the chrome: {@link topTabBar} is these parts JOINED, so the
- * rendered bar and the clickable pieces are two readings of one expression and
- * cannot drift apart.
- */
-export interface TabBarPart<Id extends string = TopTabId> {
-    /** The tab this piece is, or absent for the join between two tabs. */
+    tabs: readonly TopTab[];
+}
+export interface TabBarPart<Id extends string = string> {
     readonly tab?: Id;
     readonly text: string;
 }
-/**
- * One level's tab bar as a single row; the active tab is bracketed.
- *
- * The level is part of the signature on purpose: it is what keeps the id checked
- * at compile time now that there is more than one bar. `topTabBar('root', 'runs')`
- * is a TS2345 naming the root level's valid ids — not a bar that silently
- * brackets nothing.
- *
- * NO PRODUCT CALLER SINCE GAIA-340 Task 11, and KEPT — the decision, so it is not
- * re-litigated. The chrome draws the bar as one node per tab (`tabPartsFor`), so
- * the only readers of this and of {@link tabBarFor} are four suites that pin the
- * bar's picture. They are what those pins compare the RENDERED row against, and
- * the alternative is transcribing the bar into each of them as a literal — a
- * hand-copied reference cannot notice a label change, where this one is
- * `renderParts(…).join('')`, i.e. the same expression the chrome's nodes come
- * from. Two readings of one source cannot drift into two answers; a literal and a
- * source can. That is the same argument spec D6 makes for moving an independent
- * reference rather than dropping it, and it costs ten lines and no measurement.
- */
-export declare function topTabBar<L extends TabLevel>(level: L, activeId: TabIdOf<L>): string;
-/**
- * The same bar, for a caller holding a whole {@link TabLocation} rather than a
- * literal level. The pairing was already checked when the location was built, so
- * this needs no second check — and unlike `topTabBar(loc.level, loc.tab)` it does
- * not ask the compiler to correlate two independently narrowed properties.
- */
+export declare const tabsOfLocation: (location: TabLocation) => readonly TopTab[];
+export declare function tabPartsFor(location: TabLocation): TabBarPart[];
 export declare function tabBarFor(location: TabLocation): string;
-/**
- * One level's own bar as its clickable pieces — see {@link TabBarPart}.
- *
- * GAIA-239: the LEVEL is part of the signature, exactly as it is for
- * {@link topTabBar}, and for the same reason twice over. GAIA-241 shipped one
- * `topTabSpans(activeId)` over the single flat bar; read level-blind it would
- * publish the project bar's pieces on the root screen too, so a click where
- * `Ticket-Agents` sits on the other level would open a tab that screen does not
- * draw — the very defect GAIA-239 removed, arriving through the mouse. Pieces
- * and bar of two different levels is a TS2345, not a silent mis-click.
- */
-export declare function topTabParts<L extends TabLevel>(level: L, activeId: TabIdOf<L>): TabBarPart<TabIdOf<L>>[];
-/**
- * The same pieces, for a caller holding a whole {@link TabLocation} — the
- * companion of {@link tabBarFor}, and the pairing it needs was already checked
- * when the location was built. Keeping the two in step is what makes "the bar you
- * see is the bar you click" true by construction: both read `location`.
- *
- * GAIA-373 — `TabBarPart<string>` rather than the `TopTabId` default, and that
- * is an honest widening rather than a lost check: a location may carry a bar of
- * its own now, whose entries are CONTRIBUTED (`gaia/artifacts`) and by
- * construction outside every union derived from `TAB_LEVELS`. The level-typed
- * {@link topTabParts} keeps the narrow ids for callers that name a level.
- */
-export declare function tabPartsFor(location: TabLocation): TabBarPart<string>[];