Components v0.9.1

[cairocoder01]

• Consistent Add Item UI for multi-text (add moved to top right)
• Proper reset of loading, saved, error indicators

[github-actions]

Code Review

This PR bumps @disciple.tools/web-components from ^0.8.12 to ^0.9.1 and ships the compiled build artifacts. Two behavioral changes are visible in the compiled output.

---

High

dt-multi-text Add button ignores disabled state
dt-assets/build/components/index.js (both component hunks)

The old add button (removed) had:
```js
class="input-addon btn-add" @click=${this._addItem} ?disabled=${this.disabled}
```

The new button in the overridden labelTemplate() has:
```js
@click="${this._addItem}" class="btn-add" tabindex="1"
```

There is no ?disabled=${this.disabled} binding on the new button, and _addItem() has no internal disabled guard (_addItem(){const e={verified:\!1,value:"",tempKey:Date.now().toString()};this.value=[...this.value,e]}). This means a user can click the Add button and append new items to a field that is rendered as disabled. Both component variants (dt-multi-text and the groups variant) are affected.

---

Medium

tabindex="1" is a keyboard-navigation anti-pattern
dt-assets/build/components/index.js (lines with tabindex="1" additions)

Positive tabindex values pull elements to the front of the global tab sequence across the entire page — before all natural-flow focusable elements. For a web component used inside a WordPress admin page with many other interactive elements, this will disrupt keyboard users who tab through the form. The attribute should be tabindex="0" (insert at natural position) or omitted entirely (buttons and inputs are already natively focusable).

Disabled visual state removed from .btn-add CSS
dt-assets/build/components/index.js (CSS hunk ~3097)

The old .input-addon.btn-add block included:
```css
&:disabled { color: var(--dt-multi-text-disabled-color, ...); }
&:hover:not([disabled]) { background-color: ...; color: ...; }
```

The replacement .btn-add block has no :disabled or [disabled] states. Combined with the missing ?disabled binding above, even if the binding were restored there would be no visual feedback that the button is inactive when the field is disabled.

---

Summary

The reset() fix (clearing loading/saved/error attributes) and the Add-button relocation to the label row are reasonable improvements, but the PR ships a functional regression: disabled multi-text fields accept new items via the Add button. Not ready to merge until ?disabled=${this.disabled} (or equivalent) is restored on the new button and the tabindex values are corrected.

[github-actions]

Code Review

I reviewed the PR diff, existing comments, and traced the compiled artifact changes across all three bundle formats (index.js, index.umd.cjs, index.es.js).

The issues raised in the existing review are confirmed and accurate — I have no new findings to add. The high-severity regression (Add button accepts input on disabled fields) and the two medium issues (tabindex, missing disabled CSS) are present in both index.js and index.umd.cjs identically.

Not ready to merge until the ?disabled binding is restored on the new btn-add button in the upstream @disciple.tools/web-components source and a rebuilt artifact is shipped.

[cairocoder01]

Claude is wrong - the disabled state is now fixed. Tested locally.