@fusion.dev/helix-core 0.0.0-dev → 0.0.3

package/dist/mixins/mixin-controller-value/mixin-controller-value.d.ts

@@ -17,9 +17,9 @@ export declare class MixinControllerValueInterface {
     /**
      * What the control holds now, and what its form submits.
      *
-     * Reading gives the real value, in either mode. Writing hands ownership to
-     * the consumer: from then on the control announces changes and applies none
-     * of them, and waits to be told.
+     * Reading gives the real value. Writing always applies, and is a seed and a
+     * correction rather than a claim of ownership: a consumer who wants the
+     * decision refuses the `helix-before-change`.
      */
     value: string;
     /**
@@ -32,8 +32,7 @@ export declare class MixinControllerValueInterface {
      *
      * It selects the event rather than the timing. `requestValue` is called
      * whenever the value moves either way; this decides whether the control sends
-     * `input` alone or `input` and `change` together, so a consumer can read the
-     * name and know how often to expect it.
+     * `input` alone or `input` and `change` together.
      */
     protected readonly announcesInput: boolean;
     /** Requests a new value, and reports whether the request stood. */
@@ -46,23 +45,16 @@ export declare class MixinControllerValueInterface {
 /**
  * Grafts `value`, `defaultValue`, and the two callbacks that answer a form.
  *
- * Every control with a value had written this, and by the third it was three
- * copies of the same four members and the same seeding rule: `Input`, then
- * `Toggle.Group`, then `Radio.Group`. The copies had not diverged, which is the
- * argument for the mixin rather than against it, because the next one would
- * have.
- *
- * **Seeded in `willUpdate`, not `connectedCallback`.** SSR never calls the
- * latter, so a control with a `default-value` would serve empty and fill itself
- * at hydration, which is a flash for a reader and a mismatch for React. Seeding
- * once, before the first render, is what makes the server and the client agree.
+ * **Derived on read, never seeded in a lifecycle hook.** `value` falls back to
+ * `defaultValue`, so the server and the client agree without either running a
+ * hook. Seeding in `connectedCallback` is the trap: SSR never calls it, so a
+ * control with a `default-value` would serve empty and fill itself at
+ * hydration, a flash for a reader and a mismatch for React.
  *
  * **What it does not own is reporting.** `setFormValue` stays with the
  * component, because what an empty value means is the component's business: a
  * text field submits its emptiness, since `""` is an answer and the field was
- * on the form, while a group with nothing chosen submits nothing at all. One
- * mixin cannot hold both without a flag, and a flag would be this rule written
- * down twice.
+ * on the form, while a group with nothing chosen submits nothing at all.
  *
  * `Checkbox` deliberately does not take this. Its `value` is what it submits
  * *when it is on* rather than what it holds, so it is configuration rather than

package/dist/mixins/mixin-controller-value/mixin-controller-value.js

@@ -10,23 +10,16 @@ import { requestChange } from '../../utils/request-change/request-change.js';
 /**
  * Grafts `value`, `defaultValue`, and the two callbacks that answer a form.
  *
- * Every control with a value had written this, and by the third it was three
- * copies of the same four members and the same seeding rule: `Input`, then
- * `Toggle.Group`, then `Radio.Group`. The copies had not diverged, which is the
- * argument for the mixin rather than against it, because the next one would
- * have.
- *
- * **Seeded in `willUpdate`, not `connectedCallback`.** SSR never calls the
- * latter, so a control with a `default-value` would serve empty and fill itself
- * at hydration, which is a flash for a reader and a mismatch for React. Seeding
- * once, before the first render, is what makes the server and the client agree.
+ * **Derived on read, never seeded in a lifecycle hook.** `value` falls back to
+ * `defaultValue`, so the server and the client agree without either running a
+ * hook. Seeding in `connectedCallback` is the trap: SSR never calls it, so a
+ * control with a `default-value` would serve empty and fill itself at
+ * hydration, a flash for a reader and a mismatch for React.
  *
  * **What it does not own is reporting.** `setFormValue` stays with the
  * component, because what an empty value means is the component's business: a
  * text field submits its emptiness, since `""` is an answer and the field was
- * on the form, while a group with nothing chosen submits nothing at all. One
- * mixin cannot hold both without a flag, and a flag would be this rule written
- * down twice.
+ * on the form, while a group with nothing chosen submits nothing at all.
  *
  * `Checkbox` deliberately does not take this. Its `value` is what it submits
  * *when it is on* rather than what it holds, so it is configuration rather than
@@ -54,12 +47,10 @@ export const MixinControllerValue = (Base) => {
             /**
              * Whether a reader edits this continuously, which decides the native name.
              *
-             * **It used to pick between `helix-input` and `helix-change`**, which was
-             * one mechanism under two names and said *phase* where it meant
-             * *granularity*. The request event is `helix-before-change` whatever the
-             * answer; this decides which native event announces the result, `input`
-             * while a reader is editing against `change` when they are done, which is
-             * the distinction the platform already draws. See 294.
+             * The request event is `helix-before-change` whatever the answer; this
+             * decides which native event announces the result, `input` while a reader
+             * is editing against `change` when they are done, which is the distinction
+             * the platform already draws.
              *
              * Discrete by default: only a control the reader edits continuously says
              * otherwise.
@@ -69,17 +60,10 @@ export const MixinControllerValue = (Base) => {
         /**
          * What the control holds now, and what its form submits.
          *
-         * One property, not two. Reading gives the real value whichever mode the
-         * control is in, so `input.value` answers the question anyone asking it
-         * meant. Writing hands ownership to the consumer, which is what
-         * `<helix-input value="x">` says too, and matches what a controlled input
-         * means in React: the value is theirs and the control waits to be told.
-         * `default-value` is how markup seeds one it does not want to own.
-         *
-         * The same shape as the other three mixins, which is the point of them
-         * being four of a kind rather than four of three kinds.
-         *
-         * helix-input
+         * One property, not two, so `input.value` answers the question anyone
+         * asking it meant. Writing always applies; `<helix-input value="x">` is the
+         * same statement in markup, and `default-value` is how markup seeds a value
+         * a reset should return to.
          */
         get value() {
             return this.valueState ?? this.defaultValue;
@@ -117,7 +101,6 @@ export const MixinControllerValue = (Base) => {
          * itself, whether or not a consumer declared `value`: a declared property
          * is a seed and a correction, the way `<input value>` is, and a consumer
          * who wants the change for themselves refuses it and assigns their own.
-         * See 294.
          */
         requestValue(next) {
             if (this.value === next) {

package/dist/mixins/mixin-dismissible/mixin-dismissible.d.ts

@@ -17,25 +17,20 @@ export declare class DismissibleElement {
 /**
  * Grafts `dismissible`, its label, and the event that says so.
  *
- * Three surfaces had written this: `Announcement`, `Tag` and `Toast.Item`, each
- * with the same two properties, the same event, and the same expression for the
- * label. They had not diverged, which is the argument for extracting rather than
- * against it, because the fourth would have.
- *
- * **The label reads the default slot, not the whole element**, and that is a bug
- * fix rather than a move. Every copy said `this.textContent`, which is every
- * light-DOM descendant including the ones assigned elsewhere. On `Announcement`
- * and `Tag` that is the same thing, because they have one slot. On `Toast.Item`
- * it swept in the actions: a message reading "Could not reach the server" with a
- * `Retry` button announced itself as "Could not reach the server Retry", and the
- * consumer removing it from their list got that string to match on.
+ * **The label reads the default slot, never `this.textContent`**, which is
+ * every light-DOM descendant including the ones assigned elsewhere. On
+ * `Announcement` and `Tag` the two are the same thing, because they have one
+ * slot. On `Toast.Item` the second sweeps in the actions: a message reading
+ * "Could not reach the server" with a `Retry` button announces itself as "Could
+ * not reach the server Retry", and the consumer removing it from their list
+ * gets that string to match on.
  *
  * **`dismissEvent()` is separate from `dismiss()` for the one that needs it.**
  * `Announcement` and `Tag` dispatch and are done: they own no state, so a
  * refusal is the whole of the consumer's answer. `Toast.Item` holds an `open`
- * it may or may not own, so its event has to go through the controlled-change
- * path with an `apply` beside it. Giving it the event rather than the method
- * lets it keep the contract and skip the default.
+ * and applies the change itself, so its event goes through `requestChange` with
+ * an `apply` beside it. Giving it the event rather than the method lets it keep
+ * the contract and skip the default.
  */
 export declare const MixinDismissible: <T extends Constructor<LitElement>>(Base: T) => Constructor<DismissibleElement> & T;
 export {};

package/dist/mixins/mixin-dismissible/mixin-dismissible.js

@@ -9,25 +9,20 @@ import { HelixDismissEvent } from '../../events/events.js';
 /**
  * Grafts `dismissible`, its label, and the event that says so.
  *
- * Three surfaces had written this: `Announcement`, `Tag` and `Toast.Item`, each
- * with the same two properties, the same event, and the same expression for the
- * label. They had not diverged, which is the argument for extracting rather than
- * against it, because the fourth would have.
- *
- * **The label reads the default slot, not the whole element**, and that is a bug
- * fix rather than a move. Every copy said `this.textContent`, which is every
- * light-DOM descendant including the ones assigned elsewhere. On `Announcement`
- * and `Tag` that is the same thing, because they have one slot. On `Toast.Item`
- * it swept in the actions: a message reading "Could not reach the server" with a
- * `Retry` button announced itself as "Could not reach the server Retry", and the
- * consumer removing it from their list got that string to match on.
+ * **The label reads the default slot, never `this.textContent`**, which is
+ * every light-DOM descendant including the ones assigned elsewhere. On
+ * `Announcement` and `Tag` the two are the same thing, because they have one
+ * slot. On `Toast.Item` the second sweeps in the actions: a message reading
+ * "Could not reach the server" with a `Retry` button announces itself as "Could
+ * not reach the server Retry", and the consumer removing it from their list
+ * gets that string to match on.
  *
  * **`dismissEvent()` is separate from `dismiss()` for the one that needs it.**
  * `Announcement` and `Tag` dispatch and are done: they own no state, so a
  * refusal is the whole of the consumer's answer. `Toast.Item` holds an `open`
- * it may or may not own, so its event has to go through the controlled-change
- * path with an `apply` beside it. Giving it the event rather than the method
- * lets it keep the contract and skip the default.
+ * and applies the change itself, so its event goes through `requestChange` with
+ * an `apply` beside it. Giving it the event rather than the method lets it keep
+ * the contract and skip the default.
  */
 export const MixinDismissible = (Base) => {
     class Dismissible extends Base {

package/dist/mixins/mixin-field/mixin-field.d.ts

@@ -16,7 +16,7 @@ export declare class MixinFieldInterface {
      */
     hint: string;
     /**
-     * Ids of the description nodes, for `aria-describedby` on the control.
+     * Id of the description node, for `aria-describedby` on the control.
      *
      * `undefined` when there is nothing to point at, so the attribute is absent
      * rather than pointing at an id that renders nothing.
@@ -68,7 +68,7 @@ export declare class MixinFieldInterface {
      *
      * `empty` is the control's own answer to whether it holds nothing, `message`
      * is what to say about it, and `anchor` names the part the browser should
-     * point its bubble at. Seven families wrote this out by hand.
+     * point its bubble at.
      */
     protected reportRequired(empty: boolean, message: string, anchor: string): void;
     /** The message actually shown: the consumer's, or the platform's, or none. */
@@ -129,17 +129,15 @@ export declare class MixinFieldInterface {
  * uses. Measured the same way, and the failure is silent either way: the
  * description simply never reaches the accessibility tree.
  *
- *
  * **The label, the hint and the feedback are documented on each component that
- * applies this, rather than here.** Eight of the eighteen did and ten did not,
- * which is what `check:parts` now refuses in both directions. Declaring them
- * once on this mixin is the obvious fix and does not work: the analyzer reads
- * `@csspart` off a custom element class, so a class-level tag here reaches the
- * manifest as nothing at all, on this JSDoc and on the inner class alike.
- * Measured both ways, and the inner-class version is the dangerous one, since
- * it satisfies `check:parts` while every API page stays exactly as wrong as
- * before. Members are different and do inherit, which is what the note about
- * the inner class in the area rules is about.
+ * applies this, rather than here.** Declaring them once on this mixin is the
+ * obvious fix and does not work: the analyzer reads `@csspart` off a custom
+ * element class, so a class-level tag here reaches the manifest as nothing at
+ * all, on this JSDoc and on the inner class alike. Measured both ways, and the
+ * inner-class version is the dangerous one, since it satisfies the rule while
+ * every API page stays exactly as wrong as before. Members are different and
+ * do inherit, which is what the note about the inner class in the area rules
+ * is about.
  */
 export declare const MixinField: <T extends Constructor<HelixElement>>(Base: T) => Constructor<MixinFieldInterface> & T;
 export {};

package/dist/mixins/mixin-field/mixin-field.js

@@ -65,17 +65,15 @@ const FEEDBACK_ID = 'helix-feedback';
  * uses. Measured the same way, and the failure is silent either way: the
  * description simply never reaches the accessibility tree.
  *
- *
  * **The label, the hint and the feedback are documented on each component that
- * applies this, rather than here.** Eight of the eighteen did and ten did not,
- * which is what `check:parts` now refuses in both directions. Declaring them
- * once on this mixin is the obvious fix and does not work: the analyzer reads
- * `@csspart` off a custom element class, so a class-level tag here reaches the
- * manifest as nothing at all, on this JSDoc and on the inner class alike.
- * Measured both ways, and the inner-class version is the dangerous one, since
- * it satisfies `check:parts` while every API page stays exactly as wrong as
- * before. Members are different and do inherit, which is what the note about
- * the inner class in the area rules is about.
+ * applies this, rather than here.** Declaring them once on this mixin is the
+ * obvious fix and does not work: the analyzer reads `@csspart` off a custom
+ * element class, so a class-level tag here reaches the manifest as nothing at
+ * all, on this JSDoc and on the inner class alike. Measured both ways, and the
+ * inner-class version is the dangerous one, since it satisfies the rule while
+ * every API page stays exactly as wrong as before. Members are different and
+ * do inherit, which is what the note about the inner class in the area rules
+ * is about.
  */
 export const MixinField = (Base) => {
     // JSDoc is duplicated from MixinFieldInterface deliberately. The interface is
@@ -84,14 +82,14 @@ export const MixinField = (Base) => {
     class FieldElement extends Base {
         constructor() {
             super(...arguments);
-            /**
-             * Help under the control, shown while there is nothing wrong.
-             */
-            this.hint = '';
             /**
              * What is wrong, in the reader's words rather than the browser's.
              */
             this.feedback = '';
+            /**
+             * Help under the control, shown while there is nothing wrong.
+             */
+            this.hint = '';
             /**
              * The accessible name, and the fallback for the `label` slot.
              */
@@ -103,15 +101,14 @@ export const MixinField = (Base) => {
             /**
              * Whether the reader has had a go at the field yet.
              *
-             * This was `:user-invalid`, which is the platform's own answer to "is this
-             * field wrong *yet*" and is the right idea. It does not work here, and the
-             * reason is structural rather than a browser bug: `:user-invalid` tracks
-             * interaction with the element it is on, and nobody interacts with this
-             * element. The reader types into an `<input>` inside its shadow root, so
-             * the host's interaction flag is never set and the selector never matches.
-             * Measured after submitting an invalid required field and again after
-             * editing one and leaving it: false both times, while `:invalid` matched
-             * both times.
+             * **Not `:user-invalid`**, which is the platform's own answer to "is this
+             * field wrong *yet*" and cannot work here, for a structural reason rather
+             * than a browser bug: it tracks interaction with the element it is on, and
+             * nobody interacts with this element. The reader types into an `<input>`
+             * inside its shadow root, so the host's interaction flag is never set and
+             * the selector never matches. Measured after submitting an invalid required
+             * field and again after editing one and leaving it: false both times, while
+             * `:invalid` matched both times.
              *
              * So the moments are listened for instead, and both of them demonstrably
              * reach the host: `invalid` when a form is submitted with this control
@@ -122,10 +119,10 @@ export const MixinField = (Base) => {
              * **A composite control has to construct its own `change`, and this mixin
              * deliberately does not do it for them.** A native `change` is
              * `composed: false`, so a control built from several inner inputs never
-             * relays one to its host: `Input` gets this free from its one control, and
-             * `PinInput` had four boxes, none of whose `change` means the code is
-             * entered, so a half-entered code was never `touched` and could never say
-             * what was wrong with it. See 311.
+             * relays one to its host: `Input` gets this free from its one control,
+             * while a `PinInput` of four boxes has no inner `change` that means the
+             * code is entered, so a half-entered code is never `touched` and can never
+             * say what is wrong with it.
              *
              * **The obvious shared fix is for `touched` to take a `focusout`, and it is
              * the wrong one**, because it is the paragraph above undone: a `focusout`
@@ -134,15 +131,15 @@ export const MixinField = (Base) => {
              * focus moment, it is the native meaning of `change`, "edited, then left",
              * and the editing half is the part a mixin up here cannot see.
              *
-             * **Nor is there one shape to extract yet.** The two composites in the
-             * library solve it differently and both are right: `PinInput` is
-             * focus-driven, taking a baseline when focus arrives from outside the row
-             * and announcing on the way out if it moved, and `DateInput` is
-             * value-driven, stopping its inner `change` and announcing once the date
-             * itself moves. Generalizing from those two would be generalizing from one,
-             * since only one of them has a leaving moment at all. The trigger for
-             * lifting it is a third control that needs the focus-driven shape, at which
-             * point what moves up is the baseline-and-commit pair rather than `touched`.
+             * **Nor is there one shape to extract yet.** The two composites solve it
+             * differently and both are right: `PinInput` is focus-driven, taking a
+             * baseline when focus arrives from outside the row and announcing on the
+             * way out if it moved, and `DateInput` is value-driven, stopping its inner
+             * `change` and announcing once the date itself moves. Only one of them has
+             * a leaving moment at all, so generalizing from the pair is generalizing
+             * from one. The trigger for lifting it is a third control that needs the
+             * focus-driven shape, at which point what moves up is the
+             * baseline-and-commit pair rather than `touched`.
              */
             this.touched = false;
             /** What the last render put on screen, so a change can be noticed. */
@@ -230,10 +227,8 @@ export const MixinField = (Base) => {
          * that the label is rendered and clipped, so the name arrives through the
          * same `<label for>` a visible one does.
          *
-         * This replaced `hide-label`, which was a second attribute to say what the
-         * absence of the first should have said. The rule is now `label` means a
-         * label, `aria-label` means a name, and neither means an unnamed field a
-         * screen reader announces as "edit text"
+         * The rule is that `label` means a label, `aria-label` means a name, and
+         * neither means an unnamed field a screen reader announces as "edit text".
          */
         renderLabel() {
             const hidden = this.label === '' ? this.getAttribute('aria-label') : null;
@@ -323,17 +318,10 @@ export const MixinField = (Base) => {
         /**
          * Reports "required and empty" and refreshes the message, or clears both.
          *
-         * Seven families had this written out: the same `valueMissing`, the same
-         * anchor lookup, the same `refreshFeedback` under the same comment about
-         * validity moving without a property moving. Seven copies of a five-line
-         * shape is the threshold at which this mixin itself was extracted, and two
-         * of them had already drifted, `checkbox-group` having no validity at all
-         * until yesterday.
-         *
-         * What differs between them is exactly two things, so those are the
+         * Two things differ between the controls that call this, so those are the
          * arguments: whether the control is empty, which only it can say, and the
          * sentence to say about it, which is different for a box, a switch and a
-         * set. The anchor is looked up here because every one of them anchored on a
+         * set. The anchor is looked up here because every one of them anchors on a
          * rendered part and the browser needs somewhere to point the bubble.
          *
          * The message is not derived from the control's kind, deliberately. "Tick
@@ -354,13 +342,12 @@ export const MixinField = (Base) => {
          * Records "wrong, and the reader knows it" as the custom state `invalid`.
          *
          * The styled tier selects on this rather than on `:host(:user-invalid)`,
-         * which cannot match for the reason above, so the invalid border never
-         * arrived either. One state, and the message and the border agree by
-         * construction.
+         * which cannot match for the reason above. One state, and the message and
+         * the border agree by construction.
          *
-         * **A state and not `data-invalid`, since 27 Aug 2026.** A field served
-         * with a `feedback` message already failing was written invalid on its
-         * first update, which is an attribute the consumer's server never sent.
+         * **A state and not `data-invalid`.** A field served with a `feedback`
+         * message already failing is written invalid on its first update, which
+         * would be an attribute the consumer's server never sent.
          * `HelixElement.toggleState` carries the argument.
          *
          * In `willUpdate`, which is where the resolved message is first known.
@@ -369,11 +356,9 @@ export const MixinField = (Base) => {
             super.willUpdate(changed);
             this.shownFeedback = this.resolvedFeedback;
             this.toggleState('invalid', this.shownFeedback !== '');
-            /* And say it to the accessibility tree, which nothing did.
-             *
-             * A field carrying a `feedback` message painted red, and was described by
-             * that message through `aria-describedby`, and was never announced as
-             * being *wrong*: a reader heard the message as though it were help text.
+            /* And say it to the accessibility tree. Describing a field with its
+             * `feedback` message through `aria-describedby` never announces it as
+             * being *wrong*: a reader hears the message as though it were help text.
              * `aria-invalid` is the one word for it, and this is the one place that
              * knows, so every field in the library gets it from here. */
             this.internals.ariaInvalid = this.shownFeedback === '' ? null : 'true';
@@ -395,10 +380,10 @@ export const MixinField = (Base) => {
     }
     __decorate([
         property()
-    ], FieldElement.prototype, "hint", void 0);
+    ], FieldElement.prototype, "feedback", void 0);
     __decorate([
         property()
-    ], FieldElement.prototype, "feedback", void 0);
+    ], FieldElement.prototype, "hint", void 0);
     __decorate([
         property()
     ], FieldElement.prototype, "label", void 0);
@@ -417,7 +402,6 @@ export const MixinField = (Base) => {
   
        The contract is enforced by use rather than by the cast. Every helper is
        called from `Input` or `Checkbox`, so an interface that drifts from the
-       class fails their builds, which is exactly how the missing declarations
-       were found. */
+       class fails their builds. */
     return FieldElement;
 };

package/dist/utils/capture-pointer/capture-pointer.d.ts

@@ -11,10 +11,7 @@
  *
  * That is reachable outside a test: a pointer released between the event being
  * queued and the handler running is gone by the time this is called, and a
- * synthetic `pointerdown` has no active pointer at all. The browser spec run
- * reported four of those as uncaught page errors, and three splitter specs had
- * each stubbed the method to get past it, which is the shape of a workaround
- * that has been in place long enough to read as setup.
+ * synthetic `pointerdown` has no active pointer at all.
  *
  * Returns whether it took, for the callers that then ask `hasPointerCapture`
  * before believing a move belongs to them.

package/dist/utils/capture-pointer/capture-pointer.js

@@ -11,10 +11,7 @@
  *
  * That is reachable outside a test: a pointer released between the event being
  * queued and the handler running is gone by the time this is called, and a
- * synthetic `pointerdown` has no active pointer at all. The browser spec run
- * reported four of those as uncaught page errors, and three splitter specs had
- * each stubbed the method to get past it, which is the shape of a workaround
- * that has been in place long enough to read as setup.
+ * synthetic `pointerdown` has no active pointer at all.
  *
  * Returns whether it took, for the callers that then ask `hasPointerCapture`
  * before believing a move belongs to them.

package/dist/utils/closest-instance/closest-instance.d.ts

@@ -1,19 +1,15 @@
 /**
  * The nearest ancestor that is an instance of a class, crossing shadow roots.
  *
- * **Identity rather than tag name, and the rule already existed.** `Accordion`'s
- * root states it two files from a violation of it: "Items are matched with
- * `instanceof`, never by tag name. Matching `helix-accordion-item` would tie
- * this tier to the styled one." Nine headless families resolve their
- * relationships that way; two did it by tag, and both named `helix-*` tags that
- * only `@fusion.dev/helix` registers, which is a headless package depending on a
- * styled one by string.
+ * **Identity rather than tag name.** Matching `helix-accordion-item` ties the
+ * headless tier to the styled one by string, and only `@fusion.dev/helix`
+ * registers a `helix-*` tag.
  *
  * The consequence is silent rather than loud. Subclassing a headless element under
  * a different tag is exactly what the headless tier exists to allow, and it is
- * what `helix/styled` itself does. Under a third tag the lookup returned `null`,
- * so an accordion's `mode` was ignored and every section behaved as `multiple`
- * with no error anywhere.
+ * what `helix/styled` itself does. Under a third tag a lookup by tag returns
+ * `null`, so an accordion's `mode` is ignored and every section behaves as
+ * `multiple` with no error anywhere.
  *
  * **`closest()` alone is not enough**, which is why this walks rather than
  * delegating. `closest()` stops at a shadow boundary: a component slotted into

package/dist/utils/closest-instance/closest-instance.js

@@ -1,19 +1,15 @@
 /**
  * The nearest ancestor that is an instance of a class, crossing shadow roots.
  *
- * **Identity rather than tag name, and the rule already existed.** `Accordion`'s
- * root states it two files from a violation of it: "Items are matched with
- * `instanceof`, never by tag name. Matching `helix-accordion-item` would tie
- * this tier to the styled one." Nine headless families resolve their
- * relationships that way; two did it by tag, and both named `helix-*` tags that
- * only `@fusion.dev/helix` registers, which is a headless package depending on a
- * styled one by string.
+ * **Identity rather than tag name.** Matching `helix-accordion-item` ties the
+ * headless tier to the styled one by string, and only `@fusion.dev/helix`
+ * registers a `helix-*` tag.
  *
  * The consequence is silent rather than loud. Subclassing a headless element under
  * a different tag is exactly what the headless tier exists to allow, and it is
- * what `helix/styled` itself does. Under a third tag the lookup returned `null`,
- * so an accordion's `mode` was ignored and every section behaved as `multiple`
- * with no error anywhere.
+ * what `helix/styled` itself does. Under a third tag a lookup by tag returns
+ * `null`, so an accordion's `mode` is ignored and every section behaves as
+ * `multiple` with no error anywhere.
  *
  * **`closest()` alone is not enough**, which is why this walks rather than
  * delegating. `closest()` stops at a shadow boundary: a component slotted into

package/dist/utils/create-sheet/create-sheet.d.ts

@@ -4,7 +4,7 @@ import { type CSSResult } from 'lit';
  *
  * Component styles live in real `.css` files rather than `css` tagged
  * templates, so they get CSS tooling: syntax highlighting, formatters, the
- * token linter, and a diff that reads as CSS. `bun run styles` compiles each
+ * token linter, and a diff that reads as CSS. `turbo run styles` compiles each
  * one into a sibling `.css.ts` that calls this.
  *
  * The `unsafe` in `unsafeCSS` warns about interpolating untrusted input into a

package/dist/utils/create-sheet/create-sheet.js

@@ -4,7 +4,7 @@ import { unsafeCSS } from 'lit';
  *
  * Component styles live in real `.css` files rather than `css` tagged
  * templates, so they get CSS tooling: syntax highlighting, formatters, the
- * token linter, and a diff that reads as CSS. `bun run styles` compiles each
+ * token linter, and a diff that reads as CSS. `turbo run styles` compiles each
  * one into a sibling `.css.ts` that calls this.
  *
  * The `unsafe` in `unsafeCSS` warns about interpolating untrusted input into a

package/dist/utils/custom-element/custom-element.d.ts

@@ -1,24 +1,3 @@
-/**
- * Registers a custom element, once.
- *
- * A drop-in replacement for Lit's `@customElement` that does not throw when the
- * tag is already registered.
- *
- * The duplicate is not hypothetical. Next.js evaluates a module in both the
- * server and client graphs, so a component imported by a server component and a
- * client component runs its registration twice against one registry, and
- * `customElements.define` throws:
- *
- * > Failed to execute 'define': the name "helix-card" has already been used
- *
- * That failure takes down the whole prerender, and it appears only once an app
- * mixes server and client usage of the same component, which is exactly what a
- * real app does.
- *
- * The analyzer detects `@customElement` **by decorator name**, not by where it
- * is imported from, so the manifest still records `tagName` and nothing
- * downstream changes.
- */
 /** Every tag registered twice by different classes, in registration order. */
 export declare const duplicateRegistrations: () => string[];
 /** Every tag registered through `customElement`, whoever imported it first. */

package/dist/utils/custom-element/custom-element.js

@@ -1,4 +1,4 @@
-/**
+/*
  * Registers a custom element, once.
  *
  * A drop-in replacement for Lit's `@customElement` that does not throw when the

package/dist/utils/draw-icon/draw-icon.d.ts

@@ -15,15 +15,15 @@ export interface DrawIconOptions {
  * every consumer of any component that renders one ships all of the generated
  * path data: measured at 50,814 bytes raw and 15,010 gzipped for 102 icons, and
  * growing about 147 gzipped bytes per icon added. A named import ships one path
- * and is checked when the package compiles rather than when `check:icons` runs.
+ * and is checked when the package compiles rather than by a name lookup later.
  *
  * That element still earns its place as *public* API, where a consumer writes a
  * name in markup and a lookup is the only thing that can work. What it should
  * not be is how this library draws its own marks.
  *
  * **There is no `part` option, and there cannot be.** A part name behind an
- * interpolation is a part the manifest cannot see, so `check:selectors` reports
- * the component's own stylesheet as matching nothing and the part stops being
+ * interpolation is a part the manifest cannot see, so the component's own
+ * stylesheet matches nothing and the part stops being
  * API. `Trend` needs one and therefore writes its `<svg>` out with a literal
  * `part="icon"`, which is the honest cost: a helper can carry everything except
  * the thing static analysis has to read.