City-Lifeline-Cockpit/dynamic-component-service-master/openspec/changes/add-eztree-public-methods-and-config-sync/specs/eztree-runtime-config/spec.md

ADDED Requirements

Requirement: ezTreeCom MUST expose additive runtime config methods

The ezTreeCom component MUST expose additive public instance methods that allow callers to read the latest config snapshot, apply a new config snapshot, and request a randomized tree configuration after the component has mounted.

Scenario: Read the latest config from a component ref

• WHEN a consumer obtains the ezTreeCom instance through a Vue ref in preview or federated usage
• THEN the consumer MUST be able to retrieve the latest applied tree configuration from that component instance

Scenario: Apply config through a public method

• WHEN a consumer applies a new config object or accepted text payload through the component's public API
• THEN the component MUST update its runtime tree options and MUST regenerate the tree from that configuration

Scenario: Randomize through a public method

• WHEN a consumer triggers the component's public randomization method
• THEN the component MUST produce a new tree configuration, regenerate the tree, and make the new snapshot available for immediate readback

Requirement: Keep config text, runtime options, and generated tree state synchronized

The component MUST keep jsonText, runtime tree options, and generated geometry aligned across manual text apply, preview action-button calls, and public method calls.

Scenario: Apply text that passed editor validation

• WHEN the preview editor accepts a tree config text payload
• THEN ezTreeCom MUST accept the same syntax on apply and MUST regenerate the tree from that payload instead of failing later in the component

Scenario: Randomization updates the latest text snapshot

• WHEN preview or external code changes the tree through randomization or a public apply method
• THEN the component's latest config text snapshot and any preview-bound jsonText state MUST update to the same applied configuration

Scenario: Preserve upstream TreeOptions behavior across repeated updates

• WHEN ezTreeCom applies new configuration data repeatedly over time
• THEN it MUST keep the upstream TreeOptions-based flow intact rather than replacing the options container with an incompatible plain object

Requirement: Preserve existing prop-based compatibility for published consumers

The existing prop-driven usage of isUpdate, jsonText, and jsonTextChangeNumber MUST continue to work after public methods are added.

Scenario: Legacy consumer only uses props

• WHEN a consumer continues driving ezTreeCom only through props without calling any new public methods
• THEN the component MUST still load, update, and animate as it did before this change