# Reviewed FXML View generation

Both hosts now offer **Bindings → Generate View**, using the same Model metadata and target-side compatibility validation as the binding inspectors. Generation creates a new editable sibling FXML document. It never replaces an existing file or establishes a regeneration relationship.

## Workflow

1. Build and Refresh the application. Enter the qualified Model class (initially taken from the current View) and optionally an existing Controller class; select **Load Model fields**.
2. Include or omit Attributes, reorder them, and adjust labels, controls and binding directions. **Discover field choices** shows compatible Components/Rows, Converter capabilities and Table Column information. Explicit selections are retained.
3. For a nested Model, choose an existing compatible Component. For Model collections choose Repeat or Table, supply the existing Component/Row and, for a Table, ordered `attribute | header | optional width` lines. **Open selected Component / Row** uses normal host navigation. Simple collections can use ListView.
4. Choose a new sibling `.fxml` filename and select **Review generated View**. The panel shows the proposed structure and exact FXML. Target-side binding errors block creation; warnings, including unverified Converter capabilities, remain visible and permit creation. Omitted fields do not need valid configuration.
5. **Create reviewed View** writes exactly the reviewed text and opens it through normal host navigation: a standalone editor window or an IntelliJ editor tab. Subsequent editing, saving and Undo/Redo follow the ordinary document workflow. Build and Refresh includes the new resource in the target snapshot before rendering or interactive preview.

Scalar fields form a two-column GridPane. Nested Components and collection controls occupy separate full-width sections. Boolean fields default to CheckBox; other scalar fields default to TextField, with an explicit Converter required where types differ. A blank Controller uses NeitzelLib's existing declarative fallback. Supplying an existing Controller uses the shared validation rules; generation does not write handler methods.

## Ownership and validation

`ViewGeneration` in core deterministically emits FXML from immutable reviewed field choices. The shared Kit pane obtains Attributes, Component compatibility, Converter choices and diagnostics from the target worker. Application classes never enter either host classloader. Selecting a complex Attribute now exposes compatible nested Components through the existing discovery contract; no protocol change is required.

Review captures its choices, exact FXML, origin revision and current successful build identity. Changing choices or a document in the reactor invalidates approval. Before creation, the origin revision and build identity are checked again. Changed or obsolete builds require another review; generation does not silently use a retained build. The host document service creates with `CREATE_NEW`, so a collision cannot overwrite another file. Creation itself is not a text Undo command; later edits have normal host Undo/Redo.

The layout preview uses standard host controls and placeholders, not instantiated application Components. Target validation checks declarations without invoking application constructors. Full application behavior still belongs to the target preview workflow. The new document can use an existing compatible sample provider after an example descriptor points to its resource; this slice does not generate sample providers or descriptors.

## Automated qualification

The shared `ProjectionHostChecks.generation` scenario runs in native standalone and registered IntelliJ editors, against both classpath and named-module applications. It checks generated metadata provenance, nested Component and Converter choices, blocked incomplete configuration, omitted fields, visible permissive warnings, ordering, escaped labels, review invalidation, filename constraints, exact creation, navigation, collision refusal and document Undo/Redo. Repeat and Table forms are loaded by real NeitzelLib previews. After creation and Build and Refresh, an example descriptor in the disposable fixture loads the generated View at its own new resource path in a fresh target session.

The standalone check uses production editor navigation for the created file. IntelliJ uses the registered editor and native document service. Core unit tests cover deterministic XML, omission, identifier and XML-character validation, Table Columns and proposal defaults; both document adapters test non-overwriting creation and edit history.

Run the full bootstrap and the registered IDE qualification described in the README. A focused native module-path generation check is also available after the modules and smoke classpath have been built:

```sh
python3 scripts/check-view-generation.py --java-home "$JAVA_HOME" \
  --target-java-home "$TARGET_JAVA_HOME"
```

Two qualification issues were corrected during implementation: the new IntelliJ creation test needed the canonical macOS temporary-directory path in its allowed test roots; and the new shared test must use the source editor's existing `fxml-source` identifier rather than replacing it and breaking native quick-fix lookup. Neither correction weakens collision, history or quick-fix assertions. The initial failures are retained in `/tmp/view-generation-bootstrap.log` and `target/ide-workflow/runs-3mg_cwau`.

Qualification on 2026-11-13 completed all bootstrap gates: 158 unit/adapter tests with zero failures/errors/skips, bytecode and plugin dependency boundaries, 38 target processes with 548 checks, both native standalone workflows, 48 worker lifecycle cycles and abrupt owner death. After the source-selector correction, a fresh registered IntelliJ classpath run and a fresh module-path run both passed the complete shared workflow, native diagnostics/fixes, exclusive JavaFX 26 native-library checks and worker shutdown. A final focused standalone generation run also qualifies the corrected selector.

Evidence: `/tmp/view-generation-bootstrap.log` (Maven/runtime checks and the initial test-fixture failure), `/tmp/view-generation-ide-unit.log` (corrected adapter tests and packaging), `/tmp/view-generation-connected.log` and `target/connected-workflow` (both native standalone workflows, lifecycle and document adapters), `/tmp/view-generation-selector-build.log`, `/tmp/view-generation-selector-plugin.log`, `/tmp/view-generation-ide-final.log` and `target/ide-workflow/runs-mzrxahsf` (corrected build and registered IDE qualification), and `/tmp/view-generation-standalone-final.log` (final focused standalone run). These are disposable local records, not release artifacts. The pinned macOS/IDE/JavaFX combination is qualified; other platforms and versions are not established by these runs.

No manual testing was requested or substituted; previously skipped human checks stay skipped.

## Scope boundaries

This is an initial reviewed form generator, not a round-trip regeneration engine. The destination is a sibling resource, and class names currently use qualified top-level Java names. The control set is TextField, Label, CheckBox, ListView, Component, Repeat and Table. Existing Components and Controllers are selected, not generated. Computed bindings, event handlers, new Component scaffolding, arbitrary output directories, sample-provider generation and dedicated Java ViewModel generation-settings UI remain follow-up work. Existing binding inspectors can refine the resulting View normally.