Expose weave_generator (and tow_weave_generator) through the JSON generator registry

[petlenz]

Why

weave_generator (PR #57) and tow_weave_generator are excellent additions for textile composites, but they currently sit outside the JSON generator_registry_t. Their ctors take typed C++ arguments (domain_box, n_warp_yarns, n_weft_yarns, yarn_radius, amplitude, n_segments_per_yarn) rather than the schema-driven parameter_handler_t const& pattern the registered generators use.

That means:

• The CLI's JSON config can't pick weave as a generator type — users have to drop into C++ to build a woven RVE
• Tessera's auto-discovered Generator dropdown skips it — the registry walker only sees registered types
• 6 textile templates in the Tessera GUI redesign plan (plain_weave, twill_weave, satin_weave, tow_weave, 3d_weave, braided) are blocked on this

What's needed

1. Schema for weave_generator: add the static parameters() method declaring the 5 typed fields:

   • n_warp_yarns (std::size_t, required, min ≥ 1)
   • n_weft_yarns (std::size_t, required, min ≥ 1)
   • yarn_radius (T, required, range > 0)
   • amplitude (T, required, range ≥ 0)
   • n_segments_per_yarn (std::size_t, required, min ≥ 2)

2. Schema-driven ctor: weave_generator(parameter_handler_t const& handler, std::array<T,3> const& domain_box) — same pattern number_of_inclusions and volume_fraction use (domain_box passed separately because it's project-level).

3. Polymorphic base: weave_generator doesn't currently derive from rve_generator_base<T>; either bring it under the same base (so compute() is callable via the registry) OR introduce a sibling polymorphic family for 'deterministic generators' that don't iterate through a termination predicate.

4. Registration: add register_weave_generator<T>() helper + call site in register_all_generators<T>() (same pattern as register_only_inside_generator<T>()).

5. tow_weave_generator: same treatment. It wraps weave_generator and adds its own typed fields (presumably tow geometry — n_fibres_per_tow, fibre_radius, etc.).

Design considerations

Generator base mismatch

weave_generator is deterministic and topology-driven, not a Monte-Carlo placer. It probably doesn't make sense for it to consume a termination_base<T> predicate. Options:

(a) Make compute(inputs, termination, domain, opts) simply ignore termination for weave generators — documented as 'deterministic generators run once, the termination is unused'. Pro: one registry, one base, no plumbing changes downstream. Con: surprising API contract.

(b) Introduce deterministic_generator_base<T> and a second registry deterministic_generator_registry_t<T>. Tessera's GUI then has TWO Generator dropdowns or auto-switches between them based on what the user picks. Pro: type-cleaner. Con: more moving parts; consumers need to know which registry to look in.

Recommendation: (a) for the smaller blast radius. The termination predicate becomes a no-op for deterministic generators — call termination(accepted) once at the end if you want to keep the signature uniform; it just returns false for the deterministic case.

Tessera-side after this lands

Zero Tessera code change required. The registry walker picks the new types up automatically; the existing Generator form panel renders the schema. The 6 textile templates in the Tessera redesign plan flip from 'stub (greyed out)' to 'shippable'.

Related

• Tessera redesign plan tracks these as blocked templates: plain_weave, twill_weave, satin_weave, tow_weave, 3d_weave, braided
• Closes part of Tessera TODO_RVEGEN_SYNC §B.2
• Sister issue: polyline_tube_input (and siblings): empty metadata string throws instead of being treated as no-op #72 (empty metadata throw) — unrelated but in the same review pass