component-engineer

name	component-engineer
description	Chords UI component implementation policy. Use for the class-based component model, application shell, input components, layouts, message forms, validation display, dropdown/table/entity components, and server-connected components across the core, proto, and client modules.

Component Engineering

When to Use

Use this skill for UI component and component-infrastructure work:

• The Component/InputComponent class hierarchy, component lifecycle, and Props-style configuration in core.
• The application shell (appshell), views, and navigation support in core.
• Basic components: dropdowns, selectors, layouts, dialogs, tables, and wizards in core.
• Protobuf-aware components in proto: MessageForm, field editors, oneof support, and validation message display.
• Server-connected components in client: command posting, entity subscriptions, and entity-backed components such as EntityChooser.

For generated MessageField/MessageOneof/MessageDef contracts or Protobuf declarations, prefer .agents/skills/codegen-engineer/SKILL.md. For Gradle build logic, use .agents/skills/build-engineer/SKILL.md.

Policy

• Follow the class-based component pattern: rendering in content(), pre-composition state updates in beforeComposeContent(), configuration via companion-object invoke operators with Props-style lambdas.
• Name composable functions and composable-emitting methods in PascalCase.
• Hold state that must trigger recomposition in mutableStateOf-backed properties (by mutableStateOf(...) with getValue/setValue imports).
• Respect module layering: core must not depend on proto or client; proto must not depend on client. Put behavior in the lowest module that owns it.
• All libraries use Kotlin explicit API mode: public declarations need explicit public modifiers and public API needs KDoc.
• Avoid breaking public API: signatures, property names, and visibility of published declarations are contracts for external consumers. Prefer additive changes; when a member is protected, it is part of the API for component subclasses.
• Target the pinned toolchain: Kotlin 1.8.20 and Compose Multiplatform 1.5.12. Do not use newer language features or Compose APIs. Some Compose APIs in use are experimental (@OptIn(ExperimentalComposeUiApi::class)); keep such opt-ins localized and documented.
• Match existing KDoc style: @param tags for type parameters and constructor-like parameters, backticked identifiers, and wrapped lines within 100 characters.
• When changing a public component, check the KDoc examples of the changed class and its neighbors: examples are not compiled or covered by tests and go stale silently.
• Keep the copyright header year current in modified files.

Hotspots

• Component lifecycle: trace Component, InputComponent, and the concrete component's beforeComposeContent/content overrides together when changing state or recomposition behavior.
• Message forms: trace MessageForm, field/oneof registration, validation state, and the codegen runtime metadata (MessageField, MessageOneof) together.
• Entity components: trace app.client read/observe calls, entity-to-ID mapping, and selection state together (e.g., EntityChooser, DropdownSelector).

Verification

Run the narrowest relevant command first (repository root, JDK 11):

./gradlew :<module>:test
./gradlew :<module>:check
./gradlew clean build

UI rendering and interaction cannot be covered by automated tests here. For visual or interactive changes, verify compilation and existing tests, then state clearly in the final response what manual verification remains.