Give the two stale examples the point types that replaced WING

[1-Bort-1]

TL;DR

sam_tutorial.jl and kps4_comparison.jl still passed the WING DynamicsType that v0.13.0 removed, so the tutorial died with UndefVarError: WING on the step that adds the kite and has been taking Setup Test down on main since 2026-09-07. Each example now carries the point type its own wing implies — DYNAMIC for the particle wing, BODY_STATIC for the rigid one — and the tutorial declares the stations a section-coupled rigid wing has needed since auto_create_twist_surfaces! went away.

Which type is not a judgement call

#324 left the choice open, on the grounds that BODY_STATIC versus DYNAMIC is a call about what a tutorial is for. It is not: the removal commit 8516368b says "points now carry real types — DYNAMIC (particle wing) or BODY_STATIC riding the wing body (rigid wing)", and the Point and DynamicsType docstrings say the same. The type follows the wing the example already builds, so each file has exactly one right answer and they are different answers.

kps4_comparison.jl builds PlateWing(...; dynamics_type=PARTICLE_DYNAMICS) and its three points are already the sole members of its three stations, so they are DYNAMIC and the rest of the file is untouched — three words.

sam_tutorial.jl calls SymbolicAWEModels.Wing(1, vsm_aero, vsm_wing, vsm_solver, ...), which dispatches to the pre-created-objects VSMWing. That constructor never forwards dynamics_type, so the wing is always RIGID_DYNAMICS with AeroLinearized, and its six points are BODY_STATIC riding it (wing=1: a wing is a body). That wing is also section-coupled and declared no stations, which is its own error now that auto_create_twist_surfaces! is gone — "Section-coupled aero on RIGID wing 1 requires explicit stations covering its LE/TE structural sections; none were declared". So step 4 builds one Station per LE/TE pair in the loop that already builds the pair, and hands them to the wing. validate_station_modes wants DYNAMIC twist to sit on a rigid wing and to have at least two points a station, which is what an LE/TE pair is, and moment_frac 0.25 matches data/2plate_kite/rigid_structural_geometry.yaml, the repo's own rigid wing.

The loop's wing_z moved three lines up so the wing and the points read one definition of it rather than two spellings of set.l_tether + 6.

What I found and did not fix

examples/kps4_comparison.jl cannot run in any environment this repository ships. Its line 18 is using KiteModels, and KiteModels appears in none of this repo's five Project.toml files. That is why it is absent from the Setup Test run list, and why its copy of this bug went unannounced. I could only exercise the half I changed; see Verification. Adding the dependency is a decision about whether that comparison is meant to be runnable, which is not mine to take inside this diff.

.github/workflows/setup-test.yml triggers on push to main and workflow_dispatch only. Nothing runs the examples on a pull request, so an example can break and only announce it after it is merged — which is exactly what happened here, and it is why no check on this pull request runs an example at all; the local run of that job's own script, below, is what stands in for it. I would add pull_request to the trigger, but at 120 minutes a run that is a real cost on every pull request, so it deserves its own thread rather than a line in this one.

test/test_helpers.jl:50 asserts that each tracked Manifest-v1.1x.toml.default is no older than Project.toml, as a "you changed the project, regenerate the manifests" reminder. The proxy is mtime, and the gate's own step 8 trips it: git merge origin/main rewrites every working-tree file whose content moved since the base, and aaf26519 "Release SymbolicAWEModels v0.17.0" changes Project.toml. The reflog reads 9de13b34 HEAD@{2026-09-12 22:05:25}: merge origin/main: Fast-forward and Project.toml's mtime is 22:05:25 to the second, while the .defaults still carry bin/install's 21:19:40 — so 1.7892407808324673e9 >= 1.7892435240518901e9 is false, for both manifests, forever in this worktree.

All three files are byte-identical to main (git diff origin/main -- Project.toml 'Manifest-*.default' is empty) and this branch touches none of them. CI cannot see it, because a fresh checkout stamps every file within the same second. #305 is open on exactly this and proposes the content check that replaces the mtime proxy; I left the test alone and put the mechanism, which the report there does not have, on that issue — regenerating the manifests to go green would be a lie in the diff, and rewriting the check is that issue's change, not this one's.

Verification

• Reproduced first: LoadError: UndefVarError: WING not defined, examples/sam_tutorial.jl:119 — the signature Two examples still use the removed WING DynamicsType, and Setup Test has been red on main since 2026-09-07 #324 quotes from CI
• examples/sam_tutorial.jl red before, green after (juliaserver): "RIGID_DYNAMICS wing 1: COM=[[0.0, 0.0, 56.0]], I=[0.4, 0.15, 0.55]", then "Wing model created successfully"
• examples/kps4_comparison.jl: its own SymbolicAWEModels section, run verbatim without the KiteModels half, red before with the same UndefVarError and green after — model kps4_particle_plate_dynamic_11pnt_15seg_3grp_1wng_1wch_1bdy built and initialised, SymAWE section twists [deg]=[4.0, 10.0, 10.0]
• test/setup_integration.jl — the job that is red — run whole on this branch: Test Summary: End-user setup | Pass 19 | Total 19 | 64m07.4s, no errors. All nine examples in its run list and both README blocks pass; before, run sam_tutorial.jl was the one error and 19 of 20 passed
• Local full suite (Julia 1.12.7, 36 min, one cell of the matrix): 1303 passed, 1 failed, and the one failure is test_helpers' manifest-staleness check is an mtime comparison, so a dev'd dependency turns the local suite red #305's mtime check rather than this branch (above). The mirror runs under JULIA_TEST_FAILFAST=true, so it stopped at test_helpers.jl and the 35 test files sorting after it ran on GitHub CI only. Nothing in the unit suite loads examples/
• GitHub CI: all seven checks pass — the five test cells (1.11 ubuntu, 1.12 ubuntu monolith and kernel, 1.12 macOS, 1.12 windows; 47 min to 1h51), Documentation, and reuse-lint, which is the licence gate ./bin/reuse_lint cannot cover on the box for want of reuse. test_helpers.jl passes there, as test_helpers' manifest-staleness check is an mtime comparison, so a dev'd dependency turns the local suite red #305 predicts for a fresh checkout, and those cells are the only run that covers the 35 files the local mirror skipped. Setup Test does not run on pull requests, so test/setup_integration.jl above is what stands for it
• Up to date with main (9de13b34; v0.17.0 released mid-task, so the changelog entry opens a fresh ## Unreleased)
• Docs: n/a, no new or renamed public symbol.
• Risk: the tutorial's step 4 only constructs the model, it never solves it, so this proves the structure is buildable and not that a rigid VSM wing hanging off nothing is physically sensible. If the tutorial is meant to end on a wing actually attached to the pulley, that is a bigger change than a migration.

Scope

+23 / -11 across 3 files; examples/kps4_comparison.jl is three occurrences of WING → DYNAMIC and nothing else. Closes #324.

Closes #324 · task SymbolicAWEModels.jl-324

[1-Bort-1]

Independent review (advisory)

Verdict: APPROVE WITH COMMENTS · 1 inline, 0 off the diff

Good

• kps4's three points are correctly DYNAMIC: its wing is PlateWing(...; dynamics_type=PARTICLE_DYNAMICS) and its existing 1-point STATIC stations at examples/kps4_comparison.jl:174-181 already carry the membership, so nothing else had to move.
• BODY_STATIC for the tutorial's rigid VSM wing matches the type's own docs (src/system_structure/types.jl:35 and :67: rigid wing → BODY_STATIC riding the body); the choice is derivable, not a judgement call, as the card argues.
• Station shape (name, [le, te], DYNAMIC, 0.25) and LE-before-TE order copy the repo's own rigid wing, data/2plate_kite/rigid_structural_geometry.yaml:105-107, rather than inventing a second convention.
• 3 stations against 3 wing_sections in data/2plate_kite/aero_geometry.yaml, LE x=-0.5 / TE x=+0.5 matching the pushed positions, so compute_spatial_station_mapping!'s n_stations ≤ n_unrefined holds 1:1.
• eachindex(stations) reaches the VSMWing 5th positional stations arg (src/system_structure/wing.jl:464) and resolves via to_name_ref on Int names 1..3 — the refs and the Station names agree.
• The wing_z hoist is genuine tidying of touched code: one spelling of set.l_tether + 6 where there were two, and it is named in the PR description.
• Scope matches the card: git diff HEAD~1 is exactly 3 files, +23/-11, no plan/scratch files tracked, no version bump, no dependency added.
• The card is honest about what was not proven — kps4's KiteModels half unrunnable, Setup Test not triggered on PRs, reuse_lint not run — rather than claiming green everywhere.

Not good

• examples/sam_tutorial.jl:121 — These stations are DYNAMIC with default stiffness=0.0, but no segment attaches to points n+1/n+2, so the twist DOF has no bridle couple to oppose an aero moment — the exact condition validate_station_modes says DYNAMIC exists for, and the ≥2-point check passes only on the count. The tutorial builds but never solves, so it costs nothing today; it teaches readers a station shape that would drift if it were ever integrated, where STATIC (prescribed section twist on a rigid wing) is the coherent choice for a wing with no bridles.
• The tutorial's station points carry no segments, so a DYNAMIC twist DOF is declared where validate_station_modes' stated reason for DYNAMIC (a bridle couple) does not exist; see finding.
• The comment on examples/sam_tutorial.jl:112 sits above wing_z = ..., which it does not describe, and mostly restates the loop below it — the rubric's default is zero.
• Both finds (kps4 can't run without a KiteModels dep; setup-test has no pull_request trigger) are documented only in the PR body; CLEAN_CODE §5 wants a genuinely different concern filed as a linked issue.
• The CHANGELOG entry runs six narrative lines including the v0.13.0 back-story; two or three would carry the same user-visible fact.

_{claude, rubric CLEAN_CODE.md. A different lab from the implementer
on purpose: a reviewer sharing its blind spots would not flag its mistakes.}

[1-Bort-1]

MINOR: These stations are DYNAMIC with default stiffness=0.0, but no segment attaches to points n+1/n+2, so the twist DOF has no bridle couple to oppose an aero moment — the exact condition validate_station_modes says DYNAMIC exists for, and the ≥2-point check passes only on the count. The tutorial builds but never solves, so it costs nothing today; it teaches readers a station shape that would drift if it were ever integrated, where STATIC (prescribed section twist on a rigid wing) is the coherent choice for a wing with no bridles.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[1-Bort-1]

Local full suite: FAIL (28 min, Julia 1.12.7, one cell of the matrix)

  point flap drives the polars      |   10           10   2m07.8s
  Flap δ + beam-anchored point      |   28           28     29.8s
  Flow curvature                    |   76           76   1m20.9s
  Getter allocations                |    6            6     23.9s
  Getter allocations with a wing    |    4            4     58.8s
  Heading - Circular Path           |   72           72      0.4s
  Heading - Horizontal Circle       |   48           48      0.1s
  Heading - Special Cases           |   22           22      0.2s
  Heading - Near-Vertical Placement |   10           10      1.4s
  Testing helper functions...       |    7     1      8      2.0s
RNG of the outermost testset: Random.Xoshiro(0x474923bef64e9c34, 0xded501685e99151c, 0x0ac13a45e77ade04, 0xfd2219c3d843f1cf, 0x057cffb0815bce45)
ERROR: LoadError: Some tests did not pass: 1303 passed, 1 failed, 0 errored, 0 broken.
in expression starting at /home/agent/worktrees/SymbolicAWEModels.jl-324/test/runtests.jl:75
ERROR: Package SymbolicAWEModels errored during testing
Stacktrace:
  [1] pkgerror(msg::String)
    @ Pkg.Types ~/.julia/juliaup/julia-1.12.7+0.x64.linux.gnu/share/julia/stdlib/v1.12/Pkg/src/Types.jl:68
  [2] test(ctx::Pkg.Types.Context, pkgs::Vector{PackageSpec}; coverage::Bool, julia_args::Cmd, test_args::Cmd, test_fn::Nothing, force_latest_compatible_version::Bool, allow_earlier_backwards_compatible_versions::Bool, allow_reresolve::Bool)
    @ Pkg.Operations ~/.julia/juliaup/julia-1.12.7+0.x64.linux.gnu/share/julia/stdlib/v1.12/Pkg/src/Operations.jl:2642
  [3] test
    @ ~/.julia/juliaup/julia-1.12.7+0.x64.linux.gnu/share/julia/stdlib/v1.12/Pkg/src/Operations.jl:2487 [inlined]
  [4] test(ctx::Pkg.Types.Context, pkgs::Vector{PackageSpec}; coverage::Bool, test_fn::Nothing, julia_args::Cmd, test_args::Cmd, force_latest_compatible_version::Bool, allow_earlier_backwards_compatible_versions::Bool, allow_reresolve::Bool, kwargs::@Kwargs{io::IOContext{IO}})
    @ Pkg.API ~/.julia/juliaup/julia-1.12.7+0.x64.linux.gnu/share/julia/stdlib/v1.12/Pkg/src/API.jl:552
  [5] test(pkgs::Vector{PackageSpec}; io::IOContext{IO}, kwargs::@Kwargs{})
    @ Pkg.API ~/.julia/juliaup/julia-1.12.7+0.x64.linux.gnu/share/julia/stdlib/v1.12/Pkg/src/API.jl:169
  [6] test(pkgs::Vector{PackageSpec})
    @ Pkg.API ~/.julia/juliaup/julia-1.12.7+0.x64.linux.gnu/share/julia/stdlib/v1.12/Pkg/src/API.jl:158
  [7] test(; name::Nothing, uuid::Nothing, version::Nothing, url::Nothing, rev::Nothing, path::Nothing, mode::PackageMode, subdir::Nothing, kwargs::@Kwargs{})
    @ Pkg.API ~/.julia/juliaup/julia-1.12.7+0.x64.linux.gnu/share/julia/stdlib/v1.12/Pkg/src/API.jl:186
  [8] test()
    @ Pkg.API ~/.julia/juliaup/julia-1.12.7+0.x64.linux.gnu/share/julia/stdlib/v1.12/Pkg/src/API.jl:175
  [9] top-level scope
    @ none:1
 [10] eval(m::Module, e::Any)
    @ Core ./boot.jl:489
 [11] exec_options(opts::Base.JLOptions)
    @ Base ./client.jl:283
 [12] _start()
    @ Base ./client.jl:550