Discover Repeat collections and compatible Components in both hosts

docs/binding-discovery.md

@@ -12,7 +12,7 @@ For Person the browser exposes `name`, `rank`, `home`, `home.street`, and `visit
 
 ## Metadata boundary
 
-The fresh target worker loads classes without initialization and inspects signatures. It never constructs Models, Controllers, providers, controls or Converters, never invokes getters/property accessors, and never starts JavaFX. Application types stay outside both hosts. The independently negotiated `bindings-v3` capability adds the BINDINGS operation; it uses bounded UTF-8 metadata, build/context identity and document revisions, with zero image dimensions. Existing wire operation ordinals remain unchanged.
+The fresh target worker loads classes without initialization and inspects signatures. It never constructs Models, Controllers, providers, controls or Converters, never invokes getters/property accessors, and never starts JavaFX. Application types stay outside both hosts. The independently negotiated `bindings-v4` capability adds the BINDINGS operation; it uses bounded UTF-8 metadata, build/context identity and document revisions, with zero image dimensions. Existing wire operation ordinals remain unchanged.
 
 Model fallback follows NeitzelLib's public read/write JavaBean Attribute rules and simple/complex/collection classification. Nested paths expand to depth four with cycle diagnostics; collection paths expose declared element types without pretending a collection is a single nested Model. Explicit custom BeanInfo is not executed: types requiring it report a generated-metadata diagnostic. Custom/replacement ViewModels, built-in message properties and Computed methods now follow the [signature-based selection rules](viewmodel-computed-validation.md). Generated metadata and arbitrary dynamic property APIs remain unresolved.
 

docs/converter-validation.md

@@ -27,7 +27,7 @@ The chooser distinguishes compatible, incompatible, unverified and invalid candi
 
 The worker indexes class headers in captured classpath/module-path directories and JARs, respecting multi-release JAR selection, then loads Converter descendants without initialization. It reads annotations and method signatures without constructing Converters or invoking application methods. The index is bounded to 100,000 classes and 256 candidates; the normal worker deadline and cancellation apply. Application classes never enter a host.
 
-The subsequent [ViewModel/Computed slice](viewmodel-computed-validation.md) now uses `bindings-v3` and metadata format 3, adding candidate and document-problem records to the existing BINDINGS operation without changing its wire ordinal. Older binding capabilities are not silently interpreted as this format. The UTF-8 payload, metadata counts, request identity, build identity and document-revision checks remain bounded.
+The subsequent [ViewModel/Computed slice](viewmodel-computed-validation.md) now uses `bindings-v4` and metadata format 4, adding candidate and document-problem records to the existing BINDINGS operation without changing its wire ordinal. Older binding capabilities are not silently interpreted as this format. The UTF-8 payload, metadata counts, request identity, build identity and document-revision checks remain bounded.
 
 The validator covers attribute-form DirectBindings in root BindingLists: discoverable Model paths, control IDs, JavaFX property existence/writability, plain type compatibility, explicit Converter availability/capabilities and duplicate Direct/Computed targets. Known violations are errors. Unresolved types, incomplete/custom Model metadata, missing Model declarations and nested binding syntax produce warnings. Custom/replacement ViewModel signatures and Computed methods are now checked by the [next slice](viewmodel-computed-validation.md). Generated metadata, collection semantics, nested Component draft metadata, dependency injection availability and runtime method behavior remain incomplete. A warning does not certify that preview will succeed. Complete Problems-view integration and broader binding authoring remain later work.
 

docs/repeat-binding-inspector.md

@@ -14,9 +14,9 @@ A second Repeat targeting the same pane requires **Replace conflicting bindings*
 
 ## Validation boundary
 
-Structural diagnostics cover missing/ambiguous pane identifiers, duplicate Repeat panes, and missing/malformed Component class or collection names. Known structural errors block new previews; invalid drafts remain saveable and undoable. **Validate Repeat bindings** reports these checks and existing target-side binding diagnostics for the current source. Validation does not apply pending form values.
+Structural diagnostics cover missing/ambiguous pane identifiers, duplicate Repeat panes, and missing/malformed Component class or collection names. Known structural errors block new previews; invalid drafts remain saveable and undoable. **Discover / Validate Repeat** reports structural and [target-side compatibility checks](repeat-compatibility.md) for the current source. Validation does not apply pending form values.
 
-This slice accepts typed field values. A collection/Component chooser and complete preflight compatibility discovery are later work. The pane's actual Java type, collection existence and ObservableList value, element/Component Model compatibility, Component loading and injection still require target-runtime loading. The inspector explicitly distinguishes structural validation from those remaining runtime checks. Generated metadata, Table/Column authoring, structural reference refactoring and complete IDE Problems integration also remain open.
+The [collection/Component discovery slice](repeat-compatibility.md) now adds choices and declared-type validation in both hosts. Unknown metadata remains a warning; actual values, Component construction and injection remain runtime checks. Generated metadata, Table/Column authoring, structural reference refactoring and complete IDE Problems integration remain open.
 
 ## Automated qualification
 

docs/repeat-compatibility.md

@@ -0,0 +1,37 @@
+# Repeat collection and Component discovery
+
+In **Bindings → Repeat bindings**, use **Discover / Validate Repeat** after Build and Refresh. The shared inspector lists collections with their element types, pane targets, and Component candidates with compatibility explanations. Choosing a collection refreshes the Component comparisons. Choosing a pane or Component only fills the form; **Apply Repeat binding** remains the source-changing action. Discovery preserves explicitly entered Component names and never silently selects a unique candidate.
+
+The same worker-side checks validate saved or unsaved Repeat declarations before new previews. Known errors block preview while Save and ordinary host Undo/Redo remain available. Unknown types produce warnings and allow preview. Form suggestions are checked against the requested collection; document diagnostics describe the existing source, not unapplied field changes. Source/build invalidation clears Repeat choices, and stale responses cannot populate a changed form or document.
+
+## Runtime-aligned metadata
+
+Generic ViewModel Model collections retain the existing nested Attribute paths and generic element metadata. NeitzelLib wraps Model collections as observable lists. Custom and replacement ViewModels use their public JavaFX Property accessor signatures; `ListProperty<T>` and `Property<ObservableList<T>>` provide element information without invoking accessors. A plain `Property<List<T>>` cannot prove its value is observable and remains unverified. Raw collections, unresolved type variables, dynamic property resolvers, missing Model context and absent Component Model constraints are also unverified. Known non-collection properties are rejected.
+
+Component discovery scans conventional FXML resource names on the target classpath/module path, then loads associated classes **without initialization**. It checks public concrete JavaFX Parent classes, writable accessible `modelProperty`, available `ClassName.fxml`, `fx:root`, its base type and the absence of a conflicting Controller. Collection element types are compared with both the Component's `neitzel-model` declaration and its typed Model property. Missing resources/classes, wrong pane types, non-collection paths and known Model mismatches are errors. Pane choices include incompatible controls with explanations rather than hiding why they cannot be used.
+
+The scan uses the target resource loader, including captured draft overlays for existing Component resources. It is bounded to 4,096 scanned FXML entries and 256 candidates. Component FXML parsing is secure and size-limited. No application constructor, getter, accessor, Controller method, provider or static initializer is executed by discovery. Application types never enter the host UI.
+
+## Boundaries
+
+Compatibility means declared type compatibility, not guaranteed runtime success. Injection configuration, constructor/accessor bodies, null collection values, null elements, dynamic list contents and Component binding behavior remain runtime checks. This slice does not alter NeitzelLib's collection-change semantics. Generated metadata, arbitrary generic substitution across a selected ViewModel's inheritance, BeanInfo execution and cross-View incidental ViewModel selection remain outside the signature fallback.
+
+Named modules must expose Component resources to the discovery worker and reflective Model access to NeitzelLib; unavailable metadata is reported rather than assumed compatible.
+
+Candidate enumeration follows conventional `package/ClassName.fxml` resource names; unusual/nested class naming may require typing the class explicitly and validating the declaration. Newly created classes still require Build and Refresh. Table/Column authoring, structural reference refactoring and complete IDE Problems integration remain later work.
+
+## Protocol and automation
+
+Binding metadata format 4 and the negotiated `bindings-v4` capability add bounded collection, Component and pane options. Old metadata capabilities are rejected. Existing build, draft and worker identity checks remain in effect; no host-specific application reflection was added.
+
+Unit tests cover matching and mismatching types, wrong pane targets, missing/non-collection paths, raw element types, writable Model access, replacement ViewModel collections, uncertain plain-List backing, non-initialization and metadata round trips. Real classpath and module-path fixtures qualify Component resource discovery and mismatch diagnostics. The shared live host scenario chooses a collection, checks compatible/incompatible options, preserves explicit choices and source until Apply, saves a mismatched Component, verifies preview blocking and exact Undo/Redo, then renders the corrected draft. Existing inspector and lifecycle scenarios remain enabled. No manual testing is required; previously skipped checks remain skipped.
+
+Run the bootstrap and registered IntelliJ checks documented in the [README](../README.md).
+
+## Qualification — 2026-11-13
+
+The full bootstrap gate passed: 103 unit/adapter tests, 36 target processes with 498 assertions, both native standalone modes, 48 worker lifecycle cycles, connected host checks and plugin packaging. Registered IntelliJ classpath and module-path runs also passed the shared inspector scenarios, exclusive JavaFX 26 native-library checks and worker shutdown.
+
+Earlier registered IntelliJ attempts encountered one initial-render timeout and two immediate saved-file assertions (one Repeat and one pre-existing DirectBinding scenario). The files inspected after failure contained the requested invalid drafts. Waiting for the shared Source view before the Repeat saves did not explain the DirectBinding failure. A subsequent complete registered run passed with unchanged production code and unchanged file-content assertions; temporary diagnostics were removed. The intermittent render/save failures are **not claimed fixed** and remain automation-reliability follow-ups. No speculative save or rendering change was included.
+
+Local run evidence: `/tmp/repeat-compatibility-bootstrap-final.log`, `/tmp/repeat-save-diagnostic.log`, and `target/ide-workflow/{classpath,modulepath}.json`. These generated artifacts are not repository inputs. Previously skipped human checks remain skipped.

docs/repository-bootstrap-plan.md

@@ -120,4 +120,8 @@ The [Computed authoring slice](computed-binding-inspector.md) adds create/change
 
 ## Shared Repeat-binding inspector
 
-The [Repeat authoring slice](repeat-binding-inspector.md) adds create/change/remove, explicit duplicate-pane replacement, structural diagnostics and normal host Undo/Redo in both hosts. Collection/Component compatibility discovery and Table/Column authoring remain subsequent work, alongside generated metadata, reference refactoring and Problems integration.
+The [Repeat authoring slice](repeat-binding-inspector.md) adds create/change/remove, explicit duplicate-pane replacement, structural diagnostics and normal host Undo/Redo in both hosts. Collection/Component compatibility discovery is covered by the next completed slice below. Table/Column authoring, generated metadata, reference refactoring and Problems integration remain subsequent work.
+
+## Repeat collection and Component compatibility
+
+The [shared Repeat discovery slice](repeat-compatibility.md) adds collection, pane and Component choices, non-initializing target-side type comparisons, source-preserving explicit selections and document diagnostics with preview gating. Runtime construction and values remain preview checks. Table/Column authoring, generated metadata, reference refactoring and Problems integration remain open.

docs/viewmodel-computed-validation.md

@@ -20,7 +20,7 @@ Computed validation still runs when a Model declaration is missing: that limits
 
 ## Boundaries
 
-Application classes stay in the target worker and are loaded without initialization. The `bindings-v3` capability and metadata format 3 add Controller/ViewModel identity and Computed signatures, plus the captured resource on requests. Old metadata capabilities are rejected rather than silently decoded. Existing protocol identities, payload limits, path/target limits and worker cancellation apply; the method inventory is bounded to 256 entries.
+Application classes stay in the target worker and are loaded without initialization. The current `bindings-v4` capability and metadata format 4 retain Controller/ViewModel identity and Computed signatures, plus the captured resource on requests, and add [Repeat options](repeat-compatibility.md). Old metadata capabilities are rejected rather than silently decoded. Existing protocol identities, payload limits, path/target limits and worker cancellation apply; the method inventory is bounded to 256 entries.
 
 Generated metadata, custom BeanInfo execution, arbitrary dynamic property resolvers, full generic inference, cross-View first-use conflicts, nested ViewModel selection caused by other Views/Components, collection authoring and dependency-injection viability remain outside this slice. Method bodies, null results, constructor side effects and Computed refresh behavior are runtime concerns; compatible signatures do not prove that application code will succeed. In particular, discovery does not change which additional properties NeitzelLib observes for Computed refresh. Complete IDE Problems integration remains later work.