Roadmap

This document records future-facing work that is valuable for Buffalo Wings but is not required to complete the current stabilization work. It is intentionally directional rather than a release-by-release commitment.

Product Direction

The long-term plan is to support both library workflows and higher-level tools built on the same geometry foundation. That includes command-line tooling, GUI-based exploration, and downstream geometry export workflows.

The roadmap should be read as a dependency-aware sequence rather than as a flat backlog. Airfoil capabilities should mature before the wing workflows that depend on them. Both GUIs should grow from thin inspection tools into richer design applications only after the underlying APIs, schemas, and diagnostics are stable.

Planning Principles

The project should prioritize:

stable public geometry APIs before feature-rich applications,
schema-first workflows before ad hoc GUI-only state,
deterministic geometry generation before optimization and convenience features,
strong diagnostics and validation before automated repair behavior,
and thin vertical slices that can be used end to end before broad speculative feature expansion.

The first GUI releases should emphasize editing, validation, visualization, and export. They should not attempt to become full multidisciplinary design environments in the initial phases.

Capability Ladder

The recommended development sequence is:

Finish stabilizing the airfoil runtime, schema, examples, and diagnostics.
Add airfoil import, fitting, and export features needed by downstream wing construction.
Build a small but useful airfoil GUI on top of the stable public airfoil API.
Continue maturing the wing runtime, especially canonical geometry, surface fitting, joins, and query paths.
Add wing-focused diagnostics, export paths, and airfoil-to-wing integration examples.
Build a wing GUI on top of the stable public wing API and reuse shared application infrastructure from the airfoil GUI where practical.
Expand both applications carefully into richer design and analysis workflows once the shared geometry platform is dependable.

Delivery Horizons

The roadmap is easiest to execute when grouped into near-term, mid-term, and later horizons. These horizons are priority buckets rather than calendar promises.

Near Term

Near-term work should focus on the smallest set of capabilities that unlocks reliable end-to-end progress.

finish stabilizing public airfoil and wing APIs around the current schema-backed workflows,
improve validation and diagnostics so they are usable from examples, CLIs, and future GUIs,
add the airfoil import, normalization, fitting, and export groundwork needed by wing development,
continue maturing canonical wing construction, section placement, and deterministic panel generation,
and keep examples aligned with the public API and actual runtime support status.

Mid Term

Mid-term work should convert the stable geometry core into practical authoring and inspection tools.

deliver a thin but useful airfoil GUI for schema-backed editing, visualization, comparison, and export,
extend wing geometry work through joins, blending, and stronger query and export paths,
factor out shared GUI infrastructure such as save and load, undo and redo, debounced rebuilds, and diagnostic presentation,
and deliver a thin wing GUI that starts with validated schema editing and trustworthy preview geometry.

Later

Later work should expand supported geometry families and deepen the applications without breaking the schema-first model.

broaden airfoil family coverage according to actual downstream need,
enrich both GUIs with fitting diagnostics, guided workflows, and design-exploration tools,
strengthen interoperability with downstream meshing and analysis tools,
and add richer project, reporting, and batch-processing workflows around the same shared geometry foundation.

Phase 0: Shared Foundations

These items support both the library and future applications and should remain a steady background track. This phase should be treated as a set of enabling milestones rather than as a vague bucket of general improvements. The goal is to make later airfoil, wing, GUI, and downstream Buffalo-tool work easier to execute without reworking basic contracts.

Why Phase 0 Matters

Phase 0 is important because Buffalo Wings is intended to become geometry infrastructure for other tools rather than a standalone library in isolation. In particular, airfoil-to-Splipy fitting is a near-term dependency for Buffalo Panel and future Buffalo Mesh work. CST support is also a near-term integration milestone because Buffalo Panel already has CST-based optimization code that should be able to connect to Buffalo Wings as soon as the runtime and schema paths are ready.

Phase 0 Exit Criteria

Phase 0 should be considered mature enough when all of the following are true:

the public airfoil and wing APIs expose stable schema-backed construction paths for the currently supported runtime features,
runtime support status is documented clearly enough that planned schema families are not confused with constructable ones,
validation and fitting paths can report structured diagnostics suitable for direct CLI or GUI presentation,
at least one schema-backed save-load-rebuild workflow is demonstrated through examples or tests,
airfoil geometry can be exported in a form suitable for downstream Splipy fitting workflows,
and the shared application patterns for future GUIs are documented well enough to avoid re-inventing core state and rebuild behavior.

Public API And Schema Stability

keep the public entry points centered on buffalo_wings.airfoil and buffalo_wings.wing,
continue exposing implementation details only through internal/,
tighten the correspondence between runtime capabilities, schema documents, and examples,
and document feature maturity clearly so GUI work does not promise workflows the library cannot yet support.

Actionable Next Steps

keep AirfoilFactory.from_spec(...) and wing schema-backed construction as the canonical entry points for end-user workflows,
audit the documented schema families against actual runtime support and examples,
and document unsupported-but-planned schema families consistently in both schema and roadmap material.

Diagnostics And Validation

improve validation errors so they are localized, actionable, and suitable for GUI presentation,
add structured diagnostics for fitting quality, parameterization quality, and geometric validity,
distinguish hard errors, warnings, and informational diagnostics,
and make diagnostics queryable rather than only raising exceptions.

Actionable Next Steps

define a small structured diagnostics model that can be returned or attached by validation and fitting workflows,
identify where current validation behavior should stay exception-based and where it should also expose structured diagnostic data,
and make sure diagnostic outputs can identify the affected schema object, field, or geometric region clearly enough for GUI use.

Shared Data And Interchange

keep schema-driven project files as the source of truth for saved work,
support clean import and export paths for geometry data and sampled outputs,
define a project-persistence story that GUI applications can reuse,
and preserve deterministic rebuilds from saved definitions.

Actionable Next Steps

define the saved-project expectation for future GUIs as schema-first documents rather than app-only state,
add explicit import and export targets for airfoil geometry that are useful for Buffalo Panel and future Buffalo Mesh workflows,
and document what sampled outputs, parameter values, tangents, and curvature data should be available for downstream fitting or meshing tools.

Downstream Tool Integration

Phase 0 should explicitly support the geometry handoff needs of related Buffalo tools.

Actionable Next Steps

make airfoil geometry export and fitting-preparation workflows first-class near-term work rather than a vague future enhancement,
define the airfoil outputs needed to create reliable Splipy curve fits for Buffalo Panel and future Buffalo Mesh work,
prioritize CST runtime and schema support so Buffalo Panel can connect existing CST-based optimization workflows to Buffalo Wings,
and document any temporary gaps where Buffalo Panel must still rely on local CST or fitting code until Buffalo Wings becomes the shared source of truth.

Shared Application Infrastructure

define reusable patterns for edit-validate-rebuild-render loops,
provide undo and redo friendly data flows around schema-backed state,
standardize background rebuild and debouncing behavior for GUI responsiveness,
and identify common plotting, reporting, and export components that can be shared across applications.

Actionable Next Steps

document one reference application pattern for schema-backed state, debounced rebuilds, and undo or redo handling,
keep GUI prototypes aligned with the public runtime APIs instead of duplicating geometry logic in widget code,
and identify which plotting and export helpers should be reusable between the airfoil and wing GUIs.

Phase 0 Execution Tracking

Phase 0 implementation work is tracked in Codeberg issues #1 through #6. Those issues hold the actionable task breakdown and should be treated as the execution queue for this phase.

The main near-term Phase 0 deliverables are:

a public airfoil sampling and export path for downstream fitting preparation,
structured diagnostics for validation and fitting workflows,
CST schema and runtime support through the public airfoil API,
Splipy fit generation for supported airfoils,
fit-quality diagnostics for Splipy fitting,
and a schema-backed Buffalo Panel handoff example that demonstrates the intended integration path.

Phase 1: Airfoil Library Evolution

After the Phase 0 integration work is in place, future airfoil work should extend the library beyond the currently supported analytic families, CST support, and initial Splipy fitting workflows. This phase should stay focused on broadening the airfoil subsystem once the first downstream integration path is established cleanly.

Representation Growth

The airfoil subsystem should eventually support:

additional direct surface parameterizations such as PARSEC,
point-defined airfoils loaded from external coordinate data,
richer fitted curve representations and fitting controls for downstream NURBS workflows,
and additional analytic families where they are useful in practice.

Point-Defined Airfoil Support

Point-defined airfoils should eventually support common external formats such as Selig, Lednicer, VSP-compatible inputs, and explicit surface-curve inputs. This work should include normalization, orientation checks, trailing-edge handling, and diagnostics for malformed or noisy input data.

Analytic Family Expansion

Potential future analytic families include:

extended 4-digit airfoils,
16-series airfoils,
6-series airfoils,
7-series airfoils,
8-series airfoils,
Joukowski airfoils,
and conformal-mapping airfoils without cusped trailing edges.

These should be prioritized according to actual wing-design and geometry-tooling needs rather than implemented speculatively.

Schema And Construction Growth

As new post-Phase-0 airfoil families mature, the user-facing schema and factory construction paths should expand with matching validation rules and examples. Construction status should remain explicit in the schema documentation so planned families are not confused with runtime-supported families.

Fitting And Blending Preparation

The airfoil subsystem should eventually provide stronger support for:

more configurable fitted curve generation for downstream Splipy workflows,
export of sampled coordinates, tangents, curvature, and parameter values for fitting,
preparation for heterogeneous airfoil blending in the wing pipeline,
and diagnostics for fitting quality and approximation error.

Phase 2: Airfoil GUI

The airfoil GUI should start as a thin application that makes the existing geometry system easier to inspect and compare. It should build on the ideas behind examples/airfoil/surface_exploration.py without treating that example as the final architecture.

Airfoil GUI Step 1: Inspection Prototype

The first useful milestone should focus on:

selecting or creating one airfoil from supported schema-backed definitions,
plotting the airfoil shape, slope, curvature, and key geometric markers,
showing validation results and derived metrics in a compact inspector,
and exporting the current definition or sampled geometry.

This stage should avoid advanced editing workflows that require unsupported runtime families.

Airfoil GUI Step 2: Authoring Workflow

Once the basic inspection loop is stable, the GUI should add:

form-based editing of supported airfoil schema fields,
live rebuild with debounced validation,
side-by-side comparison of multiple airfoils,
and project save and load workflows based on schema documents.

Airfoil GUI Step 3: Import And Fitting Workflow

After point-defined airfoil support and fitting diagnostics exist in the library, the GUI should add:

import of external coordinate files,
visualization of raw versus normalized versus fitted representations,
fitting controls with clearly presented error metrics,
and export of fitted or sampled outputs for downstream use.

Airfoil GUI Step 4: Design Exploration

Later airfoil GUI growth may include:

parameter sweeps and quick comparisons across families,
higher-level derived metrics and reports,
interactive fit tuning for downstream wing readiness,
and richer integration with future CLI or batch workflows.

The GUI should not become the only way to access these capabilities. Each major function should remain grounded in reusable library APIs.

Phase 3: Wing Library Evolution

The wing subsystem should mature after the airfoil subsystem is dependable enough to supply normalized sections, fitted curve data, and blending inputs. This phase should follow the architecture and acceptance criteria in docs/design/wing_design.md.

Canonical Geometry And Section Placement

Priority work should include:

robust validated construction of canonical wing representations from schema input,
deterministic spanwise distribution evaluation,
consistent 3D placement of resolved airfoil sections,
and queryable intermediate geometry for debugging and visualization.

Surface Construction And Joins

The wing generator should then expand through:

deterministic panel-local upper and lower surface generation,
direct C0 enforcement for compatible boundaries,
direct G1 enforcement for compatible boundaries,
compatibility diagnostics for degree, knot-vector, and control-point mismatches,
and later optional constrained fitting or compatibility-repair workflows when justified.

Airfoil Blending And Heterogeneous Panels

Once fitted airfoil representations are available, the wing subsystem should add:

spanwise blending based on compatible fitted curve representations,
support for panels that transition across different airfoil families,
diagnostics that make blending quality visible,
and validation that catches unsupported or ill-conditioned blending setups.

Query, Export, And Downstream Interfaces

The wing subsystem should eventually provide:

section-curve and section-cut queries,
surface and derivative queries on final constrained geometry,
sampled outputs for downstream meshing or analysis tools,
and end-to-end examples that show airfoil-to-wing workflows clearly.

Phase 4: Wing GUI

The wing GUI should follow the airfoil GUI and should reuse shared patterns for schema-backed editing, debounced rebuilds, diagnostics, and export. It should build on the ideas behind examples/wing/wing_schema_gui_prototype.py while remaining tied to the public wing API rather than to a standalone prototype data model.

Wing GUI Step 1: Schema And Preview Prototype

The first useful milestone should focus on:

editing a small but real subset of the wing schema,
rebuilding a coarse but trustworthy preview from validated state,
showing panel, section, and join information in an inspector,
and surfacing validation errors in a way that supports debugging malformed inputs.

This stage should prefer correctness and clarity over visual sophistication.

Wing GUI Step 2: Geometry Inspection

After the preview loop is stable, the GUI should add:

interactive 3D inspection of generated sections and fitted surfaces,
visibility controls for panels, upper and lower patches, joins, and reference geometry,
section cuts and span-station probes,
and export of the current wing definition and sampled outputs.

Wing GUI Step 3: Join And Fitting Diagnostics

Once the wing library exposes suitable diagnostics, the GUI should add:

visual inspection of join compatibility and continuity status,
fitting-quality displays for panel surfaces,
clear reporting of incompatible patch settings,
and controlled access to advanced fitting settings without overwhelming routine users.

Wing GUI Step 4: Design Authoring

Later wing GUI growth may include:

richer panel editing and multi-panel workflows,
reusable named airfoil libraries within a project,
guided setup for common planform families,
and tighter integration with downstream analysis or meshing tools.

The GUI should remain schema-first and should avoid creating geometry state that cannot be serialized and rebuilt by the library.

CLI Direction

CLI tools remain useful because they support reproducible batch workflows, testing, and integration with other Buffalo tools.

Airfoil CLI

This tool should convert user-provided airfoil definitions into validated Buffalo Wings representations and downstream exchange formats. It should support schema-oriented input and output so generated artifacts can flow into the wing library and related tools.

Wing CLI

This tool should provide schema-driven wing construction and export workflows from the command line. It should remain a complement to the GUIs rather than an afterthought.

Cross-Cutting Gaps And Risks

The current roadmap needed a clearer dependency structure and a more explicit view of application scope. The following issues should stay visible while planning future work:

GUI work should not outrun the maturity of the public airfoil and wing APIs.
Airfoil import, normalization, and fitting diagnostics are prerequisites for several valuable wing features.
Saved-project format, undo and redo behavior, and diagnostic presentation are shared application concerns and should not be reinvented independently in each GUI.
Examples should continue acting as architectural stepping stones, but prototype examples should not quietly become the long-term application architecture without deliberate refactoring.

Next Milestones

The next milestones should be:

Finish the remaining airfoil-core items that improve import, fitting readiness, diagnostics, and export.
Use that stronger airfoil foundation to keep advancing canonical wing geometry, panel surfaces, and join enforcement.
Build the first airfoil GUI as a thin schema-backed inspector and editor.
Reuse the same application patterns to build the first wing GUI around validated schema editing and preview geometry.
Expand both GUIs only after the underlying library exposes the required diagnostics and query surfaces cleanly.

Documentation And Examples

The project should continue improving:

simple examples that show the intended public API,
documentation coverage for architecture and design decisions,
Sphinx integration for the design material that is most useful to contributors,
examples that demonstrate schema-first save and load workflows,
and examples that show clear progression from airfoil construction to wing construction to export.