@nadicodeai/design-system 12.1.66 → 12.1.67

package/DESIGN.md

@@ -392,11 +392,11 @@ A product page is one of five compositions, each answering one question first:
 | Collection | Which object? | The page header (its title with the page's actions on the title's row, and nothing under it), then one toolbar (filters, search, sort), one line per record with its identity and a few comparable facts, and the row's menu. One row is one hover and one open target. |
 | Object | What is this, where does it belong, what can I do? | The parent in the breadcrumb and its sections (tabs, or the sidebar for an object worked inside); then the object's header on the page ground, never in a card: its picture, its name at `{typography.heading-md}`, one line saying what it is, a row of key facts as label and value, and at the trailing edge the page's one primary action and the three dots; then grouped facts and settings sections as the cards below. An Agent is the exception: her first section, Profile, opens with her card, the same in every product (`AgentProfileCard`): on the left her orb at 64 px, her name with a ghost pencil that turns her name, description and, where the product holds it, her look into fields in place, saved by the card's own Save, with no drawer or overlay, her description and her facts (status, last activity, the template she was made from); on the right her model, drawn with its maker's mark, her reasoning and, where the product holds them, her permissions, saved from the card's footer; her instructions follow as the next card. The page's commands sit in the window's three dots where the product has one, and otherwise at the end of her name's row. |
 | Configuration | What can I change? | A centred reading column of titled sections, help beside each field, a local save and recovery. |
-| Library | What reusable thing can I use? | Kind, text identity, description, source and revision; detail shows content and requirements. |
+| Library | What reusable thing can I use? | The shelf's title with its one definition line, the search, then the entries as two-column rows: each its kind's tile, its name, one line of description and its add control; detail shows content, requirements, source and revision. |
 
 Every setting is that Configuration composition, whether it belongs to the person, to the platform or to one record's Settings tab, so the column keeps its width and its field layout from one entry of a settings menu to the next, and each section saves its own fields from its own footer ("Cards and sections"). A table that reaches a reading column keeps the identity and the action beside it and lets its remaining columns fall to the row's supporting detail, rather than widening the page or scrolling sideways.
 
-Every page in every product opens with the same header (`PageHeader`). The top bar holds only the path to the page: its sidebar group or its parents, ending at the destination or the object, such as "Business › Agents" or "Beta Studio › Beta Desk", and never the page's own title. The content then starts with the title at `{typography.heading-md}`, on the left, and on the same row at the trailing edge the page's actions: the page's three dots when it has two further commands or more, then at most one `outline` button, then the one `default` primary, rightmost. `PageActions` is their only owner: it takes a `primary`, a `secondary` and a `menu` of two commands or more, and draws the order and the variants, so a page never passes buttons of its own. Nothing sits under the title: no line introduces, explains or counts the page, and the toolbar, the list or the page follows the title row directly. Inside an object worked from a section sidebar, the title is the section's name ("Apps"); a page that opens with the object's own header or card, such as an Agent's Profile (`AgentProfileCard`), has it as its title and no title row above it.
+Every page in every product opens with the same header (`PageHeader`). The top bar holds only the path to the page: its sidebar group or its parents, ending at the destination or the object, such as "Business › Agents" or "Beta Studio › Beta Desk", and never the page's own title. The content then starts with the title at `{typography.heading-md}`, on the left, and on the same row at the trailing edge the page's actions: the page's three dots when it has two further commands or more, then at most one `outline` button, then the one `default` primary, rightmost. `PageActions` is their only owner: it takes a `primary`, a `secondary` and a `menu` of two commands or more, and draws the order and the variants, so a page never passes buttons of its own. Nothing sits under the title: no line introduces, explains or counts the page, and the toolbar, the list or the page follows the title row directly. The one exception is a catalog shelf of the Library (Skills, Plugins): one line under its title says what kind of thing the shelf holds, because a skill and a plugin are drawn alike and that line is what tells the two shelves apart; it never counts or introduces anything else. Inside an object worked from a section sidebar, the title is the section's name ("Apps"); a page that opens with the object's own header or card, such as an Agent's Profile (`AgentProfileCard`), has it as its title and no title row above it.
 
 A collection is named once, by the page's title, and the collection's card never adds a header that only describes it. A populated collection carries no picture; a picture belongs only to a collection's first use ("Elevation & Depth"). The table's footer holds only a count or the paging, never a help sentence: guidance a step needs lives in that step.
 
@@ -557,7 +557,7 @@ The sign-up page draws the account being made as the company's card: one object
 
 ### Identity marks
 
-A recognised app, platform or model maker is drawn with its genuine mark beside its readable name, in a tile that owns the box; an unknown one keeps its name and a text monogram, never a guessed logo. The tile is 24 px, the size a 40 px table row holds, wherever a mark names a row; a mark grows only where it stands for the object itself, as on its card or at the head of its page, and there every surface of that object draws it at one size. A mark identifies and never replaces the label, and its colour identifies the maker, never a connection's health. Marks are used nominatively, to name a platform, an integration or a provider, never next to wording that implies endorsement. A brand mark never stands in for a UI icon, and a UI icon never stands in for a brand. Skills are text, without icons. In a chart, a model is named by its label, and marks stay out of legends.
+A recognised app, platform or model maker is drawn with its genuine mark beside its readable name, in a tile that owns the box; an unknown one keeps its name and a text monogram, never a guessed logo. The tile is 24 px, the size a 40 px table row holds, wherever a mark names a row; a mark grows only where it stands for the object itself, as on its card or at the head of its page, and there every surface of that object draws it at one size. A mark identifies and never replaces the label, and its colour identifies the maker, never a connection's health. Marks are used nominatively, to name a platform, an integration or a provider, never next to wording that implies endorsement. A brand mark never stands in for a UI icon, and a UI icon never stands in for a brand. A Library skill is drawn with its line icon on a `card` tile with a hairline `border`, the tile an app mark sits in, and a plugin with its line icon on the `info-soft` tile (`CatalogTile`), at 40 px in a row and 64 px at the head of its page, so the tile's ground says which kind it is; the icon is one of the catalog's fixed set, never a brand mark, and an app keeps its brand mark. In a chart, a model is named by its label, and marks stay out of legends.
 
 ### Product views
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nadicodeai/design-system",
-  "version": "12.1.66",
+  "version": "12.1.67",
   "type": "module",
   "publishConfig": {
     "access": "public"