Use component class APIs in AgentOS Fleet primitives

Context

The closed class-ownership refactor exposed a smaller, independently actionable application problem: six class-based Fleet primitives manually read the aggregate component cls array, transform it, and assign it back. That duplicates Neo.component.Base class-mutation behavior and couples application code to the current array representation.

The existing public component methods own this boundary: addCls(), removeCls(), and toggleCls().

Live latest-open sweep: checked the latest 20 open issues and the latest 30 A2A messages at 2026-07-15T19:12:56Z; no equivalent ticket or in-flight claim surfaced. Targeted issue, Discussion, Knowledge Base, Memory Core, and local-content sweeps also found no owner for this cleanup.

Agent OS structure-map gate: ran npm run --silent ai:structure-map -- --files --loc. No service under ai/ owns these mutations; the owning surface is the Body-side Fleet view folder under apps/agentos/view/fleet/. The sibling Dock Demo Viewport already demonstrates the correct addCls() idiom.

The Problem

These six Fleet components manually reproduce the component class API:

• apps/agentos/view/fleet/EventChip.mjs:59-65
• apps/agentos/view/fleet/FamilyRail.mjs:101-112
• apps/agentos/view/fleet/HealthBar.mjs:176-180
• apps/agentos/view/fleet/HealthSwatch.mjs:99-105
• apps/agentos/view/fleet/SourceHealthMarker.mjs:115-127
• apps/agentos/view/fleet/StateDot.mjs:100-119

Each site obtains this.cls or me.cls, mutates or filters that aggregate, then writes the whole value back. The code works against today's array shape instead of expressing its actual intent: add, remove, or toggle a known semantic class.

That is especially poor preparation for the object-shaped class-config direction being explored in D#15200. This ticket does not define that architecture; it makes the Fleet consumers indifferent to it by using the already-public mutation boundary.

The Architectural Reality

cls is currently a reactive component config, while Neo.component.Base owns its VDOM projection and update path. The getter returns a copy, so getter-mutate-reassign manually reimplements the abstraction.

StylingAndTheming.md draws the relevant boundary:

• component-root classes go through component configs and APIs;
• descendant raw-VDOM nodes continue to use direct node.cls arrays.

The six target sites are component-root mutations. Complete authored replacements in Accounts, FleetGrid, and AgentDetail are not aggregate transforms and remain outside this ticket. Dock Demo progress-pip writes target descendant VDOM nodes and are also excluded.

The Fix

Replace only the six aggregate read-transform-reassign sites with the existing component class methods:

• state, kind, and family transitions remove the prior known class and add the next known class;
• Boolean markers use enforced toggleCls(name, state) semantics;
• SourceHealthMarker mutates only its closed state/confidence vocabulary through the component API while preserving its text and ARIA updates;
• remove NeoArray imports that become unused.

Preserve the current logical update behavior. Because a remove-then-add sequence can enter the reactive setter more than once, focused evidence must prove that no observable intermediate class state, extra motion, or render regression is introduced. If the existing API cannot satisfy that, stop and route the missing atomic/batched primitive back to D#15200 rather than inventing an app-local abstraction.

Decision Record impact

None. This is an application-consumer cleanup against the existing public component API. It neither decides nor constrains the object-shaped cls / wrapperCls architecture.

Acceptance Criteria

• All six listed Fleet sites stop reading an aggregate component cls value for mutation and stop assigning the transformed value back.
• Each site uses only existing addCls(), removeCls(), and/or toggleCls() semantics; no new core class API is introduced.
• Event kind, family, health state, confidence, live, and animation markers remove their prior class and apply exactly their current class across repeated transitions.
• Base classes and unrelated caller-authored classes remain present after every transition.
• Repeating the same transition does not create duplicate classes.
• Focused evidence covers both transition directions for each touched class family.
• Render/update evidence proves no observable intermediate class state, extra motion, or update regression compared with the current single aggregate assignment.
• A scoped source check finds no component aggregate read-transform-reassign pattern in the six target files.
• The explicitly excluded descendant VDOM and complete-authored-replacement sites remain unchanged.

Out of Scope

• The cls / wrapperCls object-model Discussion or implementation.
• Any change to Neo.component.Base, VDOM class normalization, serialization, Neural Link, or layouts.
• Fixing the underlying class-reapplication defect tracked by #15197.
• Descendant VDOM class-array writes.
• Non-AgentOS applications, including Workstation.
• Fleet visual design, SCSS, tokens, or state vocabulary changes.

Avoided Traps

• No owner-keyed contribution map or private provenance layer.
• No spread/filter clone followed by whole-value reassignment.
• No direct edits to a component root's vdom.cls.
• No broad search-and-replace across static configs or descendant VDOM.
• No conversion of complete authored replacements that do not read the aggregate.
• No opportunistic public API expansion to optimize batching.

Related

• D#15200
• #15197
• #15199
• #14745

Origin Session ID: e0413ff9-4738-42b2-9f76-c50690e9edea

Retrieval Hint: "AgentOS Fleet component cls getter transform reassign addCls removeCls toggleCls six primitives"