Add shared source-preserving Computed binding inspector

docs/computed-binding-inspector.md

@@ -0,0 +1,29 @@
+# Shared Computed-binding inspector
+
+Both hosts now provide **Bindings → Computed bindings**. Select a declaration or choose **New Computed binding**, enter the target control's fx:id, property and Controller method, then **Apply Computed binding**. **Remove Computed binding** deletes the selected declaration. Selecting a declaration selects its canvas target; selecting a bound canvas control selects its declaration.
+
+**Find methods / Validate** asks the target worker for public Controller methods and compares their return types with the entered target. Choose a method explicitly from the list or type its name; choosing a suggestion only prepares the form. The source changes on Apply. The list includes compatibility and unresolved/unavailable explanations. Existing unprefixed names remain accepted; discovered names use `#method`. Computed bindings have no Model path, direction or Converter fields.
+
+## Source and history
+
+Direct and Computed inspectors share one lexical document editor and form lifecycle. Creation adds a fully qualified declaration and required containers without serializing the document or rewriting imports. Changes touch only control/property/method attributes, preserving their existing quoting, unrelated attributes, comments and whitespace. Removal deletes only the selected element. Alternate FXML prefixes, explicit BindingList elements wrappers and self-closing containers use the same tested insertion rules.
+
+Each Apply, Remove or explicit conflict replacement is one revision-checked host document command. Normal standalone and IntelliJ Undo/Redo restore the exact previous/new text. Source changes invalidate the active form selection, and read-only documents cannot be changed. Declarations with nested property elements remain visible and explicitly removable, but editing them requires Source; the inspector does not flatten unfamiliar syntax.
+
+A target already used by a Direct or Computed declaration requires **Replace conflicting bindings**. Replacement removes the conflicting declarations and applies the requested binding atomically. This also provides explicit replacement between binding types; neither inspector silently takes over an occupied target.
+
+## Validation and limits
+
+Structural diagnostics include missing/ambiguous targets, missing properties and malformed method names. [Target-side validation](viewmodel-computed-validation.md) checks Controller method access, arity, return types and target compatibility without executing application methods. Errors block new previews while invalid drafts remain saveable and undoable. Build/draft freshness and explicit retained-build provenance continue to apply.
+
+The inspector does not generate Controller methods or evaluate their bodies. Generated metadata, full collection authoring, structural reference refactoring and complete IDE Problems integration remain later work. Existing skipped human checks remain skipped.
+
+## Automated qualification
+
+Lexical tests cover container creation, escaping, exact attribute edits, paired-tag removal, cross-type conflict replacement, nested syntax and import identity. The same live UI scenario in both hosts discovers and chooses a compatible method without changing source, creates/changes/removes Computed declarations, replaces a Direct binding explicitly, saves and renders valid edits, saves a type-invalid edit while previews are blocked, and checks exact single-command Undo/Redo. Classpath and module-path applications use the real NeitzelLib target runtime. No manual testing is required.
+
+Run `scripts/check-bootstrap.py` and `scripts/check-ide-host.py` using the pinned SDKs and commands in the [README](../README.md).
+
+Qualification on 2026-11-13 passed on the pinned macOS baseline: **95 unit/adapter tests** (88 Maven, 7 IntelliJ), **36 target processes / 484 fixture assertions**, **48 worker lifecycle cycles**, both native standalone modes and both registered IntelliJ modes. Registered IDE checks also verified exclusive JavaFX 26 natives and worker cleanup. The source file rename received a final whitespace-only formatter adjustment after the build; no behavior changed. No manual testing was used, and previously skipped checks remain skipped.
+
+Local evidence: `/tmp/computed-bootstrap.log`, `/tmp/computed-registered-ide.log`, `target/connected-workflow/` and `target/ide-workflow/{classpath,modulepath}.json`. Malformed-XML diagnostics are deliberate recovery-test inputs; no new native crash or uncaught application exception was found. This qualifies the pinned baseline, not additional OS/IDE versions.

docs/direct-binding-inspector.md

@@ -10,13 +10,13 @@ A secure DOM identifies declarations; a lexical range index edits only the relev
 
 Existing DirectBindings written with attributes are editable. Declarations using nested property elements remain visible and can be explicitly removed, but must be changed in Source. This does not flatten or guess unsupported syntax. Short class names require the library import; conflicting explicit imports are not treated as library declarations.
 
-A target occupied by another DirectBinding or ComputedBinding requires **Replace conflicting bindings**. Replacement removes those conflicting declarations and adds/changes the chosen binding in one undo command. ComputedBinding authoring is not included.
+A target occupied by another DirectBinding or ComputedBinding requires **Replace conflicting bindings**. Replacement removes those conflicting declarations and adds/changes the chosen binding in one undo command. The [Computed-binding inspector](computed-binding-inspector.md) uses the same editing and conflict machinery.
 
 ## Validation boundary
 
 Structural diagnostics cover duplicate targets, missing/ambiguous fx:id, empty property, malformed/missing Model path and invalid direction. [Converter discovery and binding validation](converter-validation.md) now add target-side path/property/type and capability checks, a shared chooser, and automatic validation before new previews. Saving and source repair remain available on errors.
 
-[Custom ViewModel discovery and Computed validation](viewmodel-computed-validation.md) are implemented. Generated metadata, Computed/Repeat/Table authoring, complete semantic diagnostics and identifier rename/copy/subtree-delete reference repair remain later stage-4 work.
+[Custom ViewModel discovery and Computed validation](viewmodel-computed-validation.md) are implemented. Generated metadata, Repeat/Table authoring, complete semantic diagnostics and identifier rename/copy/subtree-delete reference repair remain later stage-4 work.
 
 ## Automated qualification
 

docs/repository-bootstrap-plan.md

@@ -113,3 +113,7 @@ The [next shared stage-4 slice](converter-validation.md) adds optional concrete-
 ## Custom ViewModels and Computed bindings
 
 The [shared signature-based slice](viewmodel-computed-validation.md) implements explicit Controller/Component ViewModel selection, subclass/replacement property discovery and Computed-method validation. Generated metadata, cross-View selection conflicts, full collection authoring and Problems integration remain open.
+
+## Shared Computed-binding inspector
+
+The [Computed authoring slice](computed-binding-inspector.md) adds create/change/remove and explicit conflict replacement in both hosts through the same source-preserving editor as Direct bindings. Target method choices prepare the form without changing source; normal host Undo/Redo owns each operation. Full collection authoring, generated metadata, reference refactoring and Problems integration remain open.

docs/viewmodel-computed-validation.md

@@ -1,6 +1,6 @@
 # Custom ViewModels and Computed bindings
 
-The shared **Bindings → Discover targets** panel now identifies the declared Model, selected ViewModel and Controller, lists custom properties, and shows public zero-argument application methods as Computed sources. **Find Converters / Validate** and the automatic preview gate validate existing Direct and Computed declarations in both hosts. This slice validates Computed bindings edited in Source; it does not add a Computed-binding authoring form.
+The shared **Bindings → Discover targets** panel now identifies the declared Model, selected ViewModel and Controller, lists custom properties, and shows public zero-argument application methods as Computed sources. **Find Converters / Validate** and the automatic preview gate validate existing Direct and Computed declarations in both hosts. The subsequent [Computed-binding inspector](computed-binding-inspector.md) also uses this validation for declarations authored in the shared form.
 
 ## Runtime selection and property precedence
 
@@ -22,7 +22,7 @@ Computed validation still runs when a Model declaration is missing: that limits
 
 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.
 
-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 and a Computed authoring form remain later work.
+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.
 
 ## Automated qualification