Discover Table compatibility and declared Row alignment

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-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.
+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-v5` 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-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 subsequent [ViewModel/Computed slice](viewmodel-computed-validation.md) now uses `bindings-v5` and metadata format 5, 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-compatibility.md

@@ -18,11 +18,11 @@ Compatibility means declared type compatibility, not guaranteed runtime success.
 
 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.
+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](table-column-inspector.md) and [Table-specific discovery](table-compatibility.md) are now implemented. 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.
+The current metadata format 5 and negotiated `bindings-v5` capability retain bounded collection, Component and pane options and add [Table-specific options](table-compatibility.md). 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.
 

docs/repository-bootstrap-plan.md

@@ -129,3 +129,7 @@ The [shared Repeat discovery slice](repeat-compatibility.md) adds collection, pa
 ## Shared Table / Column inspector
 
 The [Table/Column authoring slice](table-column-inspector.md) adds Table and ordered Column CRUD, explicit reordering, optional widths and Row navigation in both hosts. Lexical edits and normal host Undo/Redo preserve the authoritative document. Structural errors block preview while drafts remain saveable. Row alignment and Table-specific type discovery remain unverified; generated metadata, reference refactoring and Problems integration remain open.
+
+## Table-specific compatibility and Row alignment
+
+The [Table discovery slice](table-compatibility.md) adds collection/Row/Attribute choices, Table-specific bean rules and conservative positional Row-binding diagnostics in both hosts. Binding discovery includes captured open Row drafts and rejects changed revisions. Known type errors block preview; mismatches and uncertain alignment offer explicit Row navigation without rearranging shared layouts. Generated metadata, structural reference repair and Problems integration remain open.

docs/table-column-inspector.md

@@ -4,7 +4,7 @@ Open **Bindings → Table / Columns** in either host. Select an existing Table o
 
 Columns expose Attribute, header and optional starting width. **New Column**, **Apply Column**, **Remove Column**, **Column up** and **Column down** each produce one host-owned undo command. Blank width removes the width attribute and restores the runtime's equal-share default. Table removal removes its complete declaration and Columns. It does not repair other binding references; those remain visible to existing diagnostics.
 
-**Open selected Row Component** uses the same shared navigation service as canvas Component navigation. Column order is positional in NeitzelLib. Reordering Columns never rearranges or edits the shared Row FXML. The inspector explicitly marks Column/Row alignment and type compatibility as unverified and offers Row navigation for review. Detecting correspondence between Row fields and Column Attributes is a later discovery slice.
+**Open selected Row Component** uses the same shared navigation service as canvas Component navigation. Column order is positional in NeitzelLib. Reordering Columns never rearranges or edits the shared Row FXML. The subsequent [Table discovery slice](table-compatibility.md) now checks Table-specific types and declared Column/Row correspondence, retaining warnings where evidence is incomplete.
 
 ## Source and history
 
@@ -12,7 +12,7 @@ The authoritative host document remains the only persisted representation. Table
 
 Nested property syntax is retained and remains Source-only for field edits. Mixed Column containers are rejected rather than rewritten. Source changes invalidate the form's captured source; stale or read-only edits are refused. Each Apply, removal or move is one ordinary standalone/IntelliJ Undo/Redo transaction. Discovery or form typing does not change source.
 
-Structural diagnostics cover missing/invalid collection and Row names, empty Column lists, invalid or duplicate Attributes, missing headers, and nonpositive/nonfinite widths. Invalid drafts remain editable and saveable, while these errors block new previews. Runtime collection types, simple Column Attribute types, Row construction and positional field alignment are not certified by this authoring slice; target preview remains the execution check. No application reflection or classes enter either host.
+Structural diagnostics cover missing/invalid collection and Row names, empty Column lists, invalid or duplicate Attributes, missing headers, and nonpositive/nonfinite widths. Invalid drafts remain editable and saveable, while these errors block new previews. The [Table discovery slice](table-compatibility.md) now checks declared collection/Attribute types and positional binding evidence. Row construction and runtime layout remain preview checks. No application reflection or classes enter either host.
 
 ## Automated qualification
 

docs/table-compatibility.md

@@ -0,0 +1,37 @@
+# Table compatibility and declared Row alignment
+
+In **Bindings → Table / Columns**, select a Table and use **Discover / Validate Table** after Build and Refresh. The shared inspector lists Table-compatible collections, Row Components, and Column Attributes. Choosing a collection refreshes the comparisons; choosing a Row or Attribute only prepares the form. Explicit selections are preserved, and source changes still require Apply with ordinary host Undo/Redo.
+
+Document diagnostics describe applied declarations. Choices compare the collection requested by the form. Source/build changes clear choices, and obsolete responses cannot populate a changed form. The same target-side validation runs before preview: known errors block new previews, warnings allow preview, and invalid drafts remain saveable.
+
+## Table-specific runtime rules
+
+Table uses a direct read/write bean collection Attribute to obtain its element class, in addition to the ViewModel property providing an ObservableList. Generic ViewModels and subclasses use their Model's bean metadata; replacement ViewModels need bean metadata on the replacement itself. A property accessor alone can work for Repeat but does not satisfy Table's element-type lookup. Nested collection paths and raw/unresolvable generic element declarations are rejected when the known bean signatures prove the runtime cannot resolve them. Missing context, custom BeanInfo, unavailable classes and uncertain observable backing remain unverified.
+
+Columns must name direct simple read/write Attributes on that element class. The classifier follows NeitzelLib Table's rules: String, boolean, numeric primitives except char, Number, enum, Date/Calendar and TemporalAccessor/TemporalAmount. Complex objects, collections, arrays, char, missing setters/getters and nested paths are incompatible. No application BeanInfo, accessor, getter, constructor or static initializer is executed. Compatibility is declared type evidence, not a guarantee about null values, dynamic contents, injection or runtime code.
+
+Row candidates reuse Component resource/model-property checks and compare both declared Model and typed modelProperty with Table's element type. Manually typed Row classes are validated even if conventional resource scanning does not enumerate them. Named-module resource visibility and reflective access requirements remain those of the target runtime.
+
+## Alignment evidence and Row drafts
+
+The runtime assigns widths to the first N immediate Row children in Column order; trailing controls are allowed. For a Row declared as an HBox, discovery reads direct children or its explicit `children` wrapper and the root BindingList's Direct bindings. Each Column must correspond to a uniquely identified field with one unambiguous direct Attribute binding. Matching declarations receive an informational result. Different Attributes or too few declared fields produce a mismatch warning and **Open selected Row Component** remains available.
+
+Missing bindings, Computed bindings, Converters, nested property syntax, custom Row ViewModels, non-HBox layouts and unresolved content produce an unverified warning. Construction and runtime layout changes remain unverified even when declarations match. Warnings never silently rearrange either the Columns or the shared Row layout.
+
+Binding discovery now overlays captured open FXML documents from the active reactor, including unsaved Row drafts, and checks every captured document revision before returning. The request identity carries all captured revisions. A Row edit invalidates parent discovery through existing document notifications. This extends the same draft capture to the other binding inspectors; Java changes still require Build and Refresh.
+
+## Protocol and qualification
+
+Metadata format 5 and `bindings-v5` add bounded Table collection, Row and Attribute lists. Older binding capabilities are rejected; existing payload, snapshot, document identity and worker boundaries remain intact. No application classes enter either host.
+
+Automated tests cover the Table-specific bean rules, simple Attribute classifier, Row mismatch/unverified cases, non-initialization and metadata round trips. Both real target launch modes exercise discovery and error diagnostics. The shared host scenario checks choices, explicit selection/source preservation, an unsaved Row mismatch and restoration, invalid Column preview blocking, save and exact Undo/Redo. Run the bootstrap and registered IntelliJ checks in the [README](../README.md). No manual testing is required; previously skipped checks remain skipped.
+
+Generated metadata, automatic structural reference repair and IDE Problems integration remain subsequent work. Alignment inference deliberately remains conservative for arbitrary Row layouts and runtime behavior.
+
+### Qualification — 2026-11-13
+
+The full bootstrap gate passed: 115 unit/adapter tests with no failures, 36 target processes with 512 assertions, both native standalone modes, 48 lifecycle cycles, connected adapters and plugin packaging. Registered IntelliJ classpath and module-path qualification passed the new discovery/Row-draft scenario, exclusive JavaFX 26 native-library checks and worker shutdown. No manual testing was used.
+
+An initial fixture assertion was updated to accept informational alignment results while still rejecting warnings/errors. The first registered IntelliJ attempt encountered the previously recorded intermittent exact-source save assertion in an older projection scenario, before Table tests. Its diagnostic's second file read equaled the expected text (both 1,191 characters). The unchanged registered rerun passed both modes. No save implementation or exact-source assertion was weakened; the intermittent persistence-check issue remains a separate reliability follow-up.
+
+Local evidence: `/tmp/table-discovery-bootstrap-final.log`, `/tmp/table-discovery-registered-ide.log`, `/tmp/table-discovery-registered-ide-retry.log`, `target/connected-workflow/` and `target/ide-workflow/`. Generated qualification artifacts are not repository inputs.

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 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.
+Application classes stay in the target worker and are loaded without initialization. The current `bindings-v5` capability and metadata format 5 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.