The user wants a single-page web app with an L-system fractal tree that branches recursively and sways in the wind, using p5.js (pre-provided p5.min.js). Let me create index.html with inline CSS, JS, and a script tag loading p5.min.js.

Let me first check the current directory to see what's there.

Let me build an L-system fractal tree. I'll create an index.html with:
1. A script tag loading p5.min.js
2. CSS in a style tag
3. JS in a script tag

The L-system will be a classic fractal tree. I'll generate it procedurally using recursion, and add wind sway using a time-based sine wave that affects angles.

Let me think about the approach:

**L-System Approach:**
- Start with axiom "X" (where X is a placeholder for branching)
- Rules: 
  - X → F-[[X]+X]+[+FX]-X
  - F → FF
- F = draw forward
- f = move forward without drawing
- + = turn right
- - = turn left
- [ = save state
- ] = restore state

Actually, let me use a simpler but very classic tree L-system, like the one from the famous L-system example:
- Axiom: "X"
- X → "F-[[X]+X]+[+FX]-X" → hmm, but I want recursion with multiple generations.

Actually, for a nice fractal tree that "sways in the wind", I think the best approach is:
1. Generate the L-system string over a few generations
2. Render it as a turtle graphics tree
3. Add wind by perturbing angles based on a wave function of branch position and time

But for wind sway, doing it on the L-system string directly is tricky because the angle changes are absolute turns. A better approach for realistic wind is to use a recursive branch function, where each branch is drawn and its angle is offset by a wind factor based on its distance from the trunk/base and the time.

Actually, let me do a hybrid: I'll generate the L-system string, but when rendering, I'll apply wind-based angle offsets to each segment. Since each F in the string corresponds to a segment, I can add a wind angle based on the segment's position along the curve (or based on the branch depth).

Hmm, but the issue with L-system rendering and wind is that the turtle state stack makes per-segment wind tricky. Let me think differently.

**Approach: Recursive branch drawing with wind**

Actually, the cleanest way to get a "swaying" effect that looks good is:
- A recursive function that draws a branch from a point, splits into 2 children at angles, recurses.
- The angle of each branch is modified by a wind vector. The wind can be a sine wave that varies with time AND with the height/distance of the branch (so higher branches sway more, and they sway out of phase with lower ones for a natural wave).

This gives a very natural tree sway. But the user specifically asked for an "L-system". So let me combine: I'll generate the L-system string to define the structure (this is the "L-system" part — the grammar generates the branching topology), and then render it with wind.

To make wind work naturally with the L-system turtle, I can:
- Pre-compute the list of segments (each segment = a drawn F with start position, angle, length).
- The wind angle for each segment depends on:
  - Its index order along the traversal (or its depth)
  - Time

Actually, a really elegant approach: store segments as a flat list with depth info, then in draw(), recompute the wind offset per segment based on a wave that propagates. Segments at greater depth sway with greater amplitude and with a phase delay.

Let me design:

1. **Generate L-system:**
   - Axiom: "X"
   - Rules:
     - "X" → "F-[[X]+X]+[+FX]-X"  — wait this grows but let me pick a known-good one.
   
   Actually a simpler one that produces a full tree:
   - Axiom: "A"
   - A → "F[-A][+A]"  (or with branching)
   
   Hmm, let me think about what looks good. A common one:
   - Axiom: "X"
   - X → "F-[[X]+X]+[+FX]-X" — but this doesn't draw the trunk well.
   
   Let me use the well-known "tree" from the L-system Wikipedia examples / Felsuit:
   - Variables: X, F
   - Constants: +, -, [, ]
   - Axiom: X
   - Rules: X → F-[[X]+X]+[+FX]-X, F → FF
   
   Wait, but with F → FF, the lengths shrink... Actually F→FF doubles length each gen which is wrong for a tree. Let me not use F→FF.
   
   Better tree L-system:
   - Axiom: "X"
   - X → "F[+X][-X]"  (a Y-shaped tree, grows infinitely, each branch splits into 2)
   - But that's the simplest. With this rule, after 1 gen: F[+X][-X], X→F[+X][-X] so next gen: F[+F[+X][-X]][-F[+X][-X]]. That's a proper binary tree fractal. 

   Actually the issue is X→F[+X][-X] gives infinite recursion depth = generations. After n generations you get a full binary tree of depth n. That's exactly a fractal tree. 

   Let me use:
   - Axiom: "X"
   - Rule: X → "F[+X][-X]"
   - Generate to depth ~10

   This produces the "Pythagoras tree"-ish / fractal binary tree. The trunk is an F, then it splits at +angle and -angle, etc.

   Actually wait, with X → F[+X][-X], the segments near the trunk are drawn first. The + and - turn. So it draws F (trunk), then turns +angle, recurses X (which draws F[+X][-X] → a sub-trunk + 2 branches), turns back, then -angle, recurses. This creates a symmetric binary fractal tree. 

   For a more interesting, less regular tree (more natural), I might want varying angles and branch ratios. But for an L-system fractal tree, symmetry is fine and looks clean. I can add randomness to make it more natural, or keep it regular. Let me make it mostly regular but with the wind providing the organic motion.

2. **Render with wind:**
   I'll do a custom turtle that records each segment, then I apply wind. Actually, simpler: I'll just directly use a recursive draw function (not the string) for rendering with wind, but USE the L-system to generate the structure conceptually. 

   Hmm, the user said "grow a procedural L-system fractal tree that branches recursively and sways gently in the wind." So I should genuinely implement an L-system. Let me do the L-system properly: generate the string, then render it, applying wind.

   To apply wind to the turtle rendering: I'll modify the turtle's turn angle based on a wind function. But + and - in the string produce absolute turns. The wind effect would be best applied as a global rotation of the whole scene plus a per-branch sway.

   Let me do this: 
   - Generate the L-system string.
   - Parse it into a list of line segments. Each segment knows its generation/depth (I can track depth via branch count).
   - In draw(), render segments where each segment's angle is the base angle + wind offset.
   
   Wind offset for a segment: `windAmplitude * sin(2π * (timeFactor)) * depthFactor`. Higher depth = more sway amplitude, and phase shifts along the path so it ripples.

   Actually, the most natural-looking wind: the tree is anchored at the base. Wind applies a force that increases with height. So branches higher up sway more. The sway propagates as a wave from base to tip.

   Let me implement by tracking, for each segment, its cumulative "position index" along the branch path (or its depth and its order within depth). Then wind_angle = base + amplitude * sin(time * speed + phase). 

   Let me keep it manageable. I'll record segments with a "depth" (branch generation) and a "position" (continuous index along the drawn path). Wind on a segment = (amplitude * (depth/totalDepth)) * sin(time + position * 0.5). This makes it ripple.

   Actually, simpler and robust: I'll render recursively in JS (a recursive function), which IS the L-system grown procedurally. I'll track depth. The wind applies an angle offset to each branch based on depth and time. This is clean, performant, and produces great sway. And it IS an L-system in spirit (recursive branching with the rule A → F[+B][-B]).

   But "L-system" usually implies string rewriting. Let me do BOTH to be authentic: I'll implement the string-rewriting L-system (generate the sequence with production rules), then render it with a turtle that applies wind. This is the textbook L-system.

   Let me reconsider rendering with wind via string. The turtle approach with wind:

   The problem: when I encounter a "+", I turn left by angle. With wind, I want turns to be slightly perturbed based on... what? The issue is the wind should make the whole branch sway, but in an L-system string the turns are fixed. 

   One clean way: apply a global "wind rotation" to the entire tree that's a sine of time (whole tree leans left/right together). That's a simple sway. To make it look like a wave/ripple, I can additionally perturb each segment's angle based on its generation depth with a phase delay.

   Let me do: 
   - Global sway angle: `globalWind = windStrength * sin(time)` applied as a rotation around the base (translate to base, rotate, draw).
   - Per-branch additional perturbation during turtle rendering: I modify the turn amounts. Hmm, but turning is relative.

   Alternative clean approach used in many L-system demos: store segments with world coordinates and angles AFTER applying a time-varying wind to the angle at each step. I.e., the wind is a function of the segment's position (x, y) and time.

   I think the cleanest implementation that looks good:
   
   Parse L-system into segments (each: startX, startY, endX, endY, baseAngle). Store them in order with a depth. Then for rendering, recompute end positions based on baseAngle + wind(depth, time, orderIndex). Actually if I store segments I'd need to recompute positions because changing angle changes where subsequent segments go (since they're chained). 

   The turtle state makes it a chain. Recomputing the whole chain each frame with wind is doable: re-run the turtle interpretation each frame (not drawing, just computing positions) with wind applied to angles, then draw. Since the tree is regenerated each frame from the string with wind-modified angles.

   But applying wind to individual segment angles within the turtle is complex because of the chained nature + stack for brackets.

   OK let me simplify and go with the **recursive branch function** approach but frame it as growing the L-system. Actually, you know what, let me just implement a genuine L-system string rewrite AND render it directly with wind applied to segments via re-interpretation. Here's my plan:

   I'll generate the L-system string (X → F[+X][-X], depth ~10). Then in draw(), I interpret the string with a turtle where:
   - Each segment, instead of being at fixed angle, gets a wind offset.
   - Wind offset for the current segment = amplitude * sin(time * windSpeed + branchPhase) where branchPhase depends on the branch's depth/identity so that different branches sway out of phase.

   To make per-branch phases: I'll use the depth and a hash of the branch path. Since the L-system string doesn't encode which branch a segment belongs to directly, I'll compute it as: each time we push to the stack (encounter [), we start a new branch. I can give each branch a phase = depth * some constant, so deeper branches have different phases.

   Hmm, but within a branch, consecutive segments should sway together (it's a rigid-ish branch that bends). The natural effect: the branch bends, meaning the angle accumulates wind gradually.

   I think the recursive approach gives the most control and best visuals. Let me reconcile: I'll present it as an L-system. An L-system is defined by its alphabet, axiom, and production rules. I'll actually perform the string rewriting (that's the "L-system" part, unambiguous), and then render the resulting string. For rendering with wind, I'll re-interpret the string each frame, applying wind to turn angles.

   Let me define the wind applied during interpretation:
   - Maintain a "wind angle" that gets added to each turn.
   - Actually, the cleanest: when I turn (+/-), I add a wind perturbation to the turtle angle. And I also add a small perturbation to forward movement angles. The perturbation varies per branch.

   I'll make the wind a global lean + a height-based wave, computed per segment position.

   You know, I'm overcomplicating. Let me just do the recursive branch function — it's genuinely an L-system (recursive production), produces beautiful sway, is performant, and easy to make look great. I'll ALSO generate the L-system string in the code (with production rules and generations) and use the recursive rendering. Actually, let me do the string generation properly and render from it, because that's what "L-system" classically means and it's not much harder.

   Decision: 
   - Implement `generate()` that does string rewriting: axiom "X", rule X→"F-[[X]+X]+[+FX]-X"? or X→"F[+X][-X]". Let me pick X→"F[+X][-X]" for clean binary tree, OR a richer rule for more character. 
   
   Let me go with a rule that gives a nice tree with a trunk and branching:
   - Axiom: "X"
   - X → "F[+X][-X]"
   
   After generation to depth d, the string fully defines a binary fractal tree.
   
   - Render: interpret string with turtle. Apply wind.
   
   For wind during interpretation, I'll do this elegant thing: I'll compute the wind as a rotation applied to the *entire turtle coordinate system* that varies with the turtle's current position (height). Specifically, before drawing each 'F' segment, I can't easily rotate just that segment. 

   Hmm, let me just go with recursive rendering. It's the pragmatic choice for great sway. But I worry about authenticity. Let me do string generation + recursive-style parsing where I track branch depth and apply wind to each segment's angle based on depth and a per-branch phase, and recompute segment endpoints each frame from base angles + wind. Since the recursion with a string and stack can track depth (increment on [, decrement on ]), I can store all segments with their base geometry and depth, then transform each segment's angle with wind (depth-based phase), but the chain dependency...

   The chain dependency is the real issue. In a proper tree, each segment's position depends on all previous segments' angles in that branch path. If I perturb angles, positions shift. To handle this with wind, I'd recompute the full turtle path each frame WITH wind angles baked in. That requires re-running interpretation each frame. With depth 10, the string length is 2^10 = ~1000+ chars... actually X→F[+X][-X] doubles the number of X roughly each gen, but also F and brackets grow. After 10 gens the string is large but interpreting 1000-5000 chars per frame is totally fine (60fps). 

   So: re-interpret the string every frame, applying wind to each segment's angle. The wind for the current turtle heading: I'll perturb the *forward* direction. When I do 'F', I move forward in the current heading, but I add a wind wobble to the heading. When I do '+/-', the turn is slightly wind-augmented.

   Actually the simplest robust per-frame wind that looks like swaying: 
   - Global: `lean = windAmp * sin(t)` applied by rotating the whole canvas about the tree base. This makes the whole tree lean back and forth — a basic sway.
   - Plus, for each segment, add a small angle `segmentWobble = smallAmp * sin(t * 2 + depth * 0.7)` so branches ripple. Apply this to the heading at each segment.

   Combined this looks like a tree swaying in the wind with wave propagation. 

   Let me implement the turtle interpretation each frame with:
   - heading `a` (angle).
   - At each 'F': the actual drawing direction = `a + wind(here)`. But to keep chain consistency, I add wind to heading `a` itself and move forward, so the whole path is wind-bent. 
   - Actually, I'll fold wind into the heading by treating the wind as adding to `a` when turning, and the base lean as a global rotation.

   Let me just make the wind modify `a` continuously: `a += windDelta` where windDelta depends on time and branch. This bends the path.

   I'll go with: each frame, run the turtle through the string. The wind is defined as a function of time and the current stack depth (branch depth). When the turtle moves forward (F), I draw a line but I apply a per-frame wind angle to that segment = `windScale * depthWeight * sin(time + phase)`. The phase increments along the branch so it ripples.

   To get positions right with changing wind, I recompute everything from scratch each frame: start at base, heading down (or up). For each command, update heading and position using base heading + accumulated... no. Let me make wind a modifier on the heading that changes per segment but is recomputed fresh each frame based on a global time and the segment's "index along its branch".

   I think the cleanest correct approach: 

   Recursive function `branch(start, direction, depth, length)`:
   - if depth == 0 stop.
   - end = start + direction * length.
   - windAngle = windAmplitude * (depthFactor) * sin(time * speed + depth * phaseStep + somePosPhase).
   - Actually, apply wind to the direction: the branch direction is `baseDirection + windAngle`. Draw line start→end.
   - Compute two child directions by rotating baseDirection by ±angle, then recurse.

   This recursive approach naturally handles everything and sways beautifully. And it's an L-system in the recursive production sense. I'll ALSO include the string-generation L-system to be authentic, and maybe even parse it... 

   Ugh, I keep going back and forth. Let me make a decision and commit:

   FINAL DECISION: I'll implement a genuine string-rewriting L-system (axiom + production rules, multiple generations) stored as a string, and render it each frame with a turtle that applies a wind function to the heading. The wind function: a global lean + height/depth-dependent ripple. This is textbook L-system + wind sway. I'll recompute the turtle path each frame from the (static) string with (dynamic) wind applied to angles.

   For the wind to look like wave propagation along branches, I'll track, during interpretation, a "time accumulator" per branch using the stack. When I push state ([), I save the current phase accumulator; when I move forward, the segment's wind phase = basePhaseAtThisPoint + time. Hmm.

   Simpler: I'll apply wind based on the turtle's absolute Y position and the segment index. `wind = windAmp * sin(time*speed + y * 0.02 + idx * 0.1)`. Higher = more sway (y is height), and it ripples along the branch. And clamp amplitude to increase with height.

   Actually, the most visually pleasing and simple: wind angle for a segment = `windAmp * (heightFactor) * sin(time + heightFactor*2)`. Where heightFactor = (y - base) / treeHeight, normalized 0..1. Base doesn't move (heightFactor 0 → no sway), tips sway most. The sin(time + heightFactor*k) creates a phase delay so it looks like a wave traveling. This is great.

   But computing y requires interpreting with wind already... chicken-egg if wind depends on position. I can compute the BASE (windless) positions once, cache segment positions & heights, then each frame apply wind based on cached height. The wind changes angles → changes positions, but I can apply wind as an additional rotation around segment midpoint or as angular offset, and recompute the chain. 

   To avoid recomputing the whole chain, I'll cache the base (windless) geometry: each segment as a vector with start position and heading, organized as a tree with parent links. Then each frame, windAngle based on height (cached y from base geometry, good approximation) is added to the heading, and the world position is computed by traversing parent chain and summing vectors with winded angles. Depth ~10, segments ~1000-2000, re-traverse each frame = fine for 60fps.

   This is getting complex but will look fantastic. Let me simplify the data structure:

   I'll interpret the L-system string ONCE, producing a list of "segments" where each segment stores:
   - length (with shrink factor per depth)
   - baseAngle (relative to parent, the windless turn)
   - depth
   - I'll also store parent index so I can compute world position.

   Then each frame:
   - For each segment (in tree order / drawing order), compute its winded heading = parent's winded heading + baseAngle + wind(depth, heightApprox). Hmm, height approx.

   Actually, let me reconsider. The branch-depth-based wind is easiest: windAngle(seg) = windAmp * (depthWeight) * sin(time*speed + depth*depthPhase). Where depthWeight grows with depth (higher branches sway more). And depthPhase creates phase differences per depth level. This sways each depth-layer at a slightly different phase/time, giving a rippling wave down the tree. 

   But "depth" here = how far the branch is from base (generation). Deeper = higher up = sways more and with phase delay. That's exactly right for wind! Higher branches lag and move more.

   So:
   - Interpret L-system string into segments with a `depth` field (track via stack, increment on [, decrement on ]).
   - Also track per-segment base heading relative to parent, and store children structure for world-position computation. Actually I'll store absolute base heading and absolute base start position (windless), plus depth. The wind changes heading, so positions change. To keep it tractable, I'll store segments with a parent reference and recompute world positions each frame using winded headings (parent's winded heading + relative baseAngle + wind).

   Let me store each segment with: parentIndex, baseAngle (relative to parent's heading), length, depth. Then world heading = parent.worldHeading + baseAngle + wind(depth,time). Position = parent.worldPos + parent.worldDir*0 ... hmm length uses parent's dir.

   Let me define recursively:
   - segment.worldHeading = (parent ? parent.worldHeading : init) + baseAngle + wind(depth, time)
   - segment.worldPos = parent ? parent.worldPos + parentLenDir : basePos
   
   Wait, the segment's position is at the START of the segment (parent's end). The segment extends from start in parent's heading direction... no. Let me think.

   Standard turtle: we have current position P and heading H. On 'F': draw line from P to P + L*(cos H, sin H); then P = P + L*(cos H, sin H). On '+': H += angle. On '[': push (P, H). On ']': pop.

   So each segment (F) has: start position P, heading H at that moment, length L. The end position = P + L*dir(H). The NEXT segment starts at end position.

   To add wind: I want the heading H used for each segment to be base H plus a wind perturbation. But H is cumulative (each turn adds to it). If I perturb the heading at each segment, the chain naturally bends.

   Simplest correct method: re-interpret the string each frame, but replace the fixed turn angle with `angle + windPerturbation(depth, time)`. I.e., when I hit '+', I do `H += baseAngle + windDelta(depth)`. And the windDelta depends on current depth and time. This way the ENTIRE chain is recomputed with winded turns, positions stay consistent (it's a fresh turtle walk each frame), and we get natural sway.

   But then '+' getting windDelta means the turn itself wobbles, which bends branches. Combined with a global lean rotation, looks good.

   Hmm, but if every '+' and the forward heading all wobble, it might look jittery. Let me instead apply wind primarily to the FORWARD direction of each segment and a global lean.

   OK I'm spending too long. Let me just write a recursive branch renderer with excellent wind physics. This is the pragmatic, gorgeous solution. I'll frame the recursive rule as the L-system rule. Many L-system tree demos ARE recursive. And I'll ALSO generate the string via productions to honor "L-system", then... no, I'll just do recursive + mention the rule. Actually, let me do the string generation too because it's not hard and makes it legitimately an L-system, and it lets me have a richer rule.

   Let me go with this concrete plan:

   **L-system definition:**
   - Alphabet/variables: X (branch), F (draw forward)
   - Constants: +, -, [, ]
   - Axiom: "X"
   - Production: X → "F[+X][-X]"  ... 

   Wait, I want the tree to have a thick trunk and thinner branches (so the fractal looks like a real tree, not just lines). I'll handle thickness by drawing rectangles/ellipses based on depth, or use a branch width that decreases with depth. With lines, I can set strokeWeight proportional to depth.

   Let me use rule X → "F[+X][-X]" but with the angle being not too large so it's a spreading tree. Angle ~25°. Depth 10. Length shrinks by ~0.7 each level. This gives a classic fractal tree.

   **Rendering with wind (recursive, using the generated structure):**
   I'll generate the string, then write a turtle interpreter that, each frame, walks the string applying wind. Let me just do the turtle interpreter each frame — that recomputes positions correctly with wind integrated, guaranteeing visual correctness.

   Wind strategy in turtle:
   - `globalLean = windStrength * 0.6 * sin(time * windSpeed)` — whole-tree lean (rotate about base).
   - Per-segment: I'll perturb the heading by a small amount that depends on depth (height) and time, creating a wave. Define `windAt(depth) = windStrength * windScale(depth) * sin(time*windSpeed + depth*0.5)`. Where windScale grows with depth (e.g., depth/totalDepth) so higher branches sway more, and the +depth*0.5 phase makes it ripple from base to tip (wave traveling).
   - Apply windAt to the heading when drawing each segment: actual angle for segment = H + windAt(depth). Also apply it to turns.

   To keep the chain correct, I'll apply windAt as an additive rotation to the heading H right before each 'F' draw (affecting both the segment direction and subsequent position). And turns '+'/'-' use the baseAngle (not winded), so the structure's relative angles stay as defined; only the absolute heading drifts with wind. Hmm, if only 'F' heading is winded but turns aren't, then within a branch the wind resets... Let me apply wind to heading continuously: I'll do `H += windDelta` where windDelta = derivative... no.

   Cleanest: apply wind to the heading at each 'F' (segment). Because H carries over, and I add windAt(depth) before drawing F and move, the next segment's H starts where this one left off (already includes the wind drift of this segment). Plus turns add fixed angles. The depth-based wind means segments at different heights get different instantaneous offsets, so the branch curves with height — like wind bending a flexible branch. 

   Let me just try it and tune. I'll re-interpret the string each frame. The string for depth 10 has maybe a few thousand chars; interpreting 3x per frame... well each frame once. 3000 ops/frame = trivial.

   Actually, even simpler and equally valid: I'll generate the L-system string, and ALSO I'm allowed to render recursively. Let me just do recursion for rendering (cleaner code, perfect wind) and generate the string as the "L-system" representation shown optionally. No — let me commit to: **generate string via productions, interpret string each frame with wind.** This is the most defensible "L-system" implementation.

   Let me reconsider performance and correctness of "interpret string each frame with wind applied to heading at each F": 

   ```
   function interpret(string) {
     let pos, heading, depth;
     stack = [];
     for each char c:
       if c=='F': 
         // apply wind to heading for this segment
         let w = wind(depth);
         let a = heading + w;  // segment direction
         let next = pos + len(dir(a));
         drawLine(pos, next);
         pos = next;
         heading = a;  // carry winded heading forward
       else if c=='+': heading += angle;
       else if c=='-': heading -= angle;
       else if c=='[': stack.push({pos, heading, depth}); depth++;
       else if c==']': {pos,heading,depth} = stack.pop(); depth--;
   }
   ```

   Wait, if I set heading = a (winded) after the F, then the next turn '+' adds to the winded heading, accumulating wind. That might be fine — it means wind accumulates as we go up a branch. But depth is used for wind amplitude. Hmm, but the heading carrying wind means by the time we're deep, heading has drifted by sum of winds. That might over-rotate.

   Alternative: don't carry winded heading. Instead, apply wind to the segment's drawn direction but keep heading = base heading (so turns stay clean, structure preserved), and compute each segment's world position by... no, positions need the winded direction to chain.

   This is the crux: if wind bends the branch, positions change, and we recompute the chain. The heading that positions use SHOULD include wind (the branch is bent). So carrying winded heading forward is actually correct for a flexible branch — the branch bends continuously and subsequent segments follow the bent path. That looks natural! The only concern is drift, but with a smooth sin wind it'll be fine.

   But there's subtlety: depth for wind. When we go '[' then '[', depth increases. The wind amplitude per depth is fine.

   However, one issue: the SAME segment gets a different wind angle each frame, causing it to move — that's the sway, good. But the phase along the branch: I want a traveling wave. Using depth only gives discrete phase by level. Better phase = continuous, like the segment's "path length from base" or an index counter. Let me use a running `segIndex` that increments for every F, and wind = amp * sin(time + segIndex * 0.3). This makes a wave travel along the branch path (older segments near base have low index → different phase than tips). Combined with amplitude scaling by depth (height), we get higher branches swaying more with a traveling phase. 

   Actually a running global segIndex makes ALL segments across the whole tree participate in one wave with phase = segIndex. Segments near base (drawn first, low index) and segments at tips (drawn later, high index) have phase differences → looks like wind flowing through the tree. And amplitude scaled by depth so base barely moves, tips wobble a lot. This is the classic "wind in trees" shader approach. 

   Let me use phase based on segIndex, amplitude based on depth (normalized). And a global lean too. 

   I think this will look great. Let me also make branches thicker (strokeWeight) based on depth for a real-tree look, and maybe draw the trunk thicker.

   Let me also reconsider the L-system rule for a nicer tree. X → F[+X][-X] gives a perfectly symmetric binary tree. With wind it'll sway but symmetry might look too "fractal/regular". To make it more organic, I can:
   - Add randomness to branch angles per segment (a "natural" tree).
   - Use a rule with more variation.

   But the user asked for a fractal tree (L-system), so some regularity is expected and nice. I'll add mild randomness to angles and length shrink per branch to make it look alive but still clearly a fractal. Actually, randomness would change the string each generation. If I randomize at generation time, the string is fixed (deterministic after seed) — I can seed random once and apply consistent random angles. That gives a one-time natural-looking fractal, then wind animates it. 

   Hmm, but if I randomize angles in the string generation, the angles aren't uniform in the string — I'd need to store angles per branch. The string is just characters (+/-) with implied uniform angle. To have per-branch angle variation, I'd either use different angle values or a different representation.

   Simplification: keep uniform angle for the L-system (clean fractal), apply wind for life. Maybe add slight randomness to branch length shrink and use a non-symmetric rule. Actually symmetric is fine and elegant. Let me keep X → F[+X][-X] with uniform angle, depth ~9, and let wind provide organic motion. The result is a beautiful symmetric fractal tree swaying in the wind — exactly what's asked.

   Hmm, but a purely symmetric binary tree might look a bit sparse/regular. Let me use a richer rule to get more branches and a fuller tree. Classic richer rules:
   - X → F[+X][-X]//X  (the // = pitch/roll, ignore)
   - Or use F → FF style? 

   Let me use a well-known rich tree rule:
   - Axiom: "X"
   - X → "F[+X][-X]"  ... that's the binary one.
   
   Another popular one (produces bushy tree):
   - Axiom: "X"
   - X → "F-[[X]+X]+[+FX]-X"  (Felsuit-style) with F → "FF"
   
   The F→FF doubles forward length which is wrong (should halve). Let me not use F→FF. 

   I think the cleanest great-looking option: the binary tree X→F[+X][-X] is clean and clear. Let me ALSO add a third rule variation: maybe X → "FF[+X][-X]" so the trunk extends (F F = two segments) before splitting, giving longer branch segments. Or X → "F[+X][-X]" with length shrink 0.65 and angle 25°. 

   Let me go with:
   - Axiom: "X"
   - Rule: X → "F[+X][-X]"
   - angle = 25° (but I'll add slight randomness ±5° per generation for organic look — applied at generation time, stored as part of... no, uniform in string).

   I'll keep uniform angle 25°. With shrink 0.7 and depth 9, the tree is tall and branches nicely.

   Wait, with X→F[+X][-X] and depth 9, the number of F's = 2^9 - 1 ≈ 511 segments (minus 1, actually 2^(d+1)-1 segments roughly). That's a lot but fine. Actually each X spawns one F plus two X's, so number of F = number of X that got replaced = 2^d - 1... roughly 511 for d=9. Good, dense enough.

   Hmm, actually let me reconsider: with rule X→F[+X][-X], at depth d, the count of X = 2^d, count of F = 2^d - 1 (every X becomes one F plus 2 X, except base). So depth 9 → ~511 F segments. Fine.

   Let me increase shrink to make it fit: length0 = 120px, shrink 0.7 → at depth 9, length ≈ 120*0.7^9 ≈ 8px. Tip branches thin. Good. Depth maybe 10 for more branches. 1023 segments. Still fine.

   For thickness: strokeWeight = map(depth, 0, maxDepth, 8, 1). Base trunk thick.

   Now wind: amp = 0.06 rad per segment? Let me think in terms of visual. The global lean a few degrees, plus per-segment sway. Let me make wind perturb the heading by an amount that grows with depth and a traveling phase.

   Let me write wind as: 
   ```
   let windStrength = 0.15; // radians-ish influence
   let t = millis() * 0.001;
   wind(segIndex, depth) = windStrength * (0.3 + 0.7*depth/depthMax) * sin(t*0.6 + segIndex*0.25)
   ```
   Applied to heading each F. Plus global lean `globalWind = 0.08*sin(t*0.6)` applied via rotate about base.

   Actually, if I apply wind to heading per F and carry it forward, plus a global lean, the tree will look wind-blown. Let me just implement and the math will look right.

   One more: I worry carrying winded heading forward causes drift/compounding. Let me NOT carry it: keep `heading` as the clean L-system heading (only modified by +/- turns), and for each F, draw the segment at `heading + wind(depth,segIndex,t)` but position the NEXT segment at the END of the segment drawn in the winded direction. So:
   ```
   let a = heading + w;  // w = wind for this segment
   let nx = px + L*cos(a); let ny = py + L*sin(a);
   draw(px,py,nx,ny);
   px=nx; py=ny;
   // heading stays as the clean heading (L-system turns)
   ```
   This means each segment is bent by wind but the "intended" turn structure (heading) stays clean; the bends accumulate visually because each segment starts where the previous ended (in the winded direction). The heading (clean) only changes on +/- so branches split at correct angles relative to the intended parent direction, but each segment is locally winded. This creates a wavy branch that still splits correctly. 

   Hmm, but then the split point ([ push) is at the winded end, and children inherit the clean heading + wind... Let me think: when we hit '[', we push (px, py, heading) — current position (waved) and clean heading. Children continue from there. Their first segment direction = clean heading + their wind. Since clean heading is the intended branch direction, this works: children branches emanate from the split point in the intended directions, each locally winded. The whole thing ripples. 

   This is clean and correct. Heading never gets the wind added (stays clean), so no drift; only positions wind. The wave travels because wind depends on segIndex and time, so each segment waves, and connected segments form a smooth curve. 

   I'm happy with this. Let me also add the global lean as a rotation applied to all coordinates about the base, or just include it in the wind (it's naturally a low- frequency component). I'll add a global rotation of the canvas about the base each frame: `rotate(globalLean)`.

   Let me now also handle the base/anchor: the tree should be drawn from the bottom (base at top of tree? no, base at bottom of screen, branches go up). I'll draw trunk going upward: initial position at bottom center, heading = -PI/2 (up). Turns +/- spread children left/right.

   With heading up (-90°), '+' turns... I'll define + = turn left (counterclockwise) by angle, - = turn right. So a branch going up, + turns it left (toward 180... no, -90 + 25 = -65, that's going up-right). Let me just pick convention: '+' = rotate heading by +angle (counterclockwise), '-' = -angle. With heading up (-90°), +angle → -65° (up-right), -angle → -115° (up-left). So left child goes up-right, right up-left? Eh, whichever, it's symmetric and fine.

   Now let me also make the tree visually nice with leaves at the tips (depth == maxDepth, draw small circles/ovals green) instead of/in addition to line ends. Leaves add life. And maybe a brown trunk. strokeWeight for trunk.

   Let me finalize parameters:
   - depthMax = 10
   - len0 = 110, shrink = 0.72
   - angle = 24°
   - trunk color brown, leaf color green at tips.

   Wind:
   - t = millis()*0.001
   - globalLean = 0.06*sin(t*0.7)
   - per-segment w = 0.14 * (0.2 + 0.8*depth/depthMax) * sin(t*0.9 + segIndex*0.18)
     
   Wait segIndex grows huge (500+), *0.18 = large phase range → many oscillations along branch → might look noisy. Let me scale: segIndex grows along the branch path. With ~511 segments and phase 0.18, total phase ~94 radians → ~15 waves along the whole tree. That's too wavy/noisy per frame? Actually as time advances, the wave travels. Per frame it's a static-ish pattern waving. 15 waves along branches might look like a vibrating string — could be cool or noisy. Let me reduce to segIndex*0.05 (≈25 rad, ~4 waves). Hmm.

   Actually, the wave should propagate: leaves (high index) are ahead in phase of trunk. A traveling wave. Let me use phase = segIndex * 0.03 (~15 rad) and see. I'll tune by feel; since I can't render, I'll pick reasonable values. Let me go with amplitude growing with depth (taller sway) and phase step ~0.03 along index, plus time. 

   Actually, maybe a better phase for natural wave: phase based on the segment's DISTANCE from base along its branch (path length), normalized. But segIndex is a decent proxy. Let me use segIndex*0.04.

   I'll go with these and tune constants to look gentle ("sways gently").

   Let me reduce windStrength so it's gentle: 0.12 rad ≈ 7°. Tip sway ~ a few degrees each way + global lean. Gentle. Good.

   Let me also add subtle randomness to wind per segment for organic feel: add a fixed per-segment phase offset from a hash, so it's not perfectly uniform. I'll precompute a phase offset per segIndex using a cheap hash: `hash(i) = frac(sin(i*12.9898)*43758.5453)`. Then wind phase = t*0.9 + segIndex*0.04 + hash(segIndex)*6.28. This breaks uniformity nicely.

   OK, let me also make sure the tree re-generates deterministically each frame (the string is generated once on setup, then interpreted each frame with time-varying wind). The hash makes per-segment phase stable across frames (deterministic hash of index) — good, so branches stay connected and just sway.

   Wait, if per-segment phase is fixed (hash-based) and only time varies, then each segment sways at sin(t*0.9 + fixedPhase). Different segments have different fixed phases → they wave independently a bit but connected → ripple. Good. And depth-based amplitude → tips sway more. 

   Let me write the code.

   Structure of index.html:
   ```
   <!DOCTYPE html>
   <html lang="en">
   <head>
     <meta charset="UTF-8">
     <meta name="viewport" content="width=device-width, initial-scale=1.0">
     <title>L-System Wind Tree</title>
     <style> ... fullscreen canvas, dark bg with subtle gradient, maybe stars ... </style>
   </head>
   <body>
     <script src="p5.min.js"></script>
     <script>
       // L-system + rendering
     </script>
   </body>
   </html>
   ```

   Note: p5.min.js is in same dir, load with relative src "p5.min.js". 

   I'll write the p5 sketch. Global p5 mode: define setup() and draw() as global functions.

   Let me write:

   ```js
   // ---------- L-SYSTEM ----------
   const AXIOM = "X";
   const RULES = { X: "F[+X][-X]", F: "FF" }; // hmm F:FF doubles; skip
   const RULES = { X: "F[+X][-X]" };
   const ANGLE = radians(24);
   const ITERATIONS = 10;
   let lsystem = "";
   
   function generateLSystem() {
     lsystem = AXIOM;
     for (let i=0;i<ITERATIONS;i++) {
       let next = "";
       for (let c of lsystem) {
         if (RULES[c]) next += RULES[c];
         else next += c;
       }
       lsystem = next;
     }
   }
   ```
   Wait, F: "F[+X][-X]" — F stays F? In X→F[+X][-X], the F in the replacement stays as F (draws forward). Good, no F rule needed. But I want F→FF? No. Keep F as F. So RULES = {X: "F[+X][-X]"}. Good. But then F never gets replaced, and the string grows by replacing each X with F[+X][-X]. Each iteration doubles X count and adds F's. After 10 iters, lots of F. Fine.

   Actually, let me reconsider: I want branch length to shrink as we go deeper, but the L-system string doesn't encode length. I'll handle length via depth during interpretation: length = len0 * shrink^depth. And strokeWeight via depth. Good, so the string just defines topology + turns.

   Interpretation (each frame, with wind):
   ```js
   let stack = [];
   let px, py, heading, depth; // turtle state
   let segIndex = 0;
   // wind precompute? we compute per segment.
   
   function interpretDraw() {
     // reset turtle
     px = baseX; py = baseY; heading = -PI/2; depth = 0; segIndex = 0;
     stack = [];
     for (let c of lsystem) {
       if (c === 'F') {
         let len = len0 * pow(shrink, depth);
         let w = wind(segIndex, depth);
         let a = heading + w;
         let nx = px + len*cos(a);
         let ny = py + len*sin(a);
         // draw segment
         strokeWeight( map(depth,0,ITERATIONS,8,1) );
         stroke( lerpColor(trunkCol, leafCol, depth/ITERATIONS) ); 
         // maybe brown trunk, green tips
         line(px,py,nx,ny);
         // leaf at tip if last depth
         px=nx; py=ny; segIndex++;
       } else if (c==='+') {
         heading += ANGLE;
       } else if (c==='-') {
         heading -= ANGLE;
       } else if (c==='[') {
         stack.push({px,py,heading,depth});
         depth++;
       } else if (c===']') {
         let s = stack.pop();
         px=s.px; py=s.py; heading=s.heading; depth=s.depth;
         // depth-- ? we set depth from stack, so fine. Actually we decrement implicitly.
       }
     }
   }
   ```
   Wait, depth handling: I push current depth, then depth++ for entering branch. On pop, restore depth. But multiple nested branches need correct depth. Since we restore from stack, depth is correct. But I increment depth only on '[' — but depth should reflect nesting level, and nested [[ would depth 1,2. On pop restores. Good. But there's subtlety: when we pop back to a shallower level and continue, depth is restored correctly. 

   However, the leaves/tips: I want to draw leaves at the deepest branches. I'll check: if after this F, the next non-trivial... simpler: draw a leaf if depth >= ITERATIONS-1 (deepest). Or just always draw leaf-colored circles at segment ends when depth is high. Let me draw leaves: for segments at depth >= ITERATIONS-1, draw a small ellipse at the end in green, and maybe skip the line or keep it thin.

   Let me refine: 
   - branch segments: brown, width by depth.
   - at depth == max: draw leaf (green oval).

   I'll draw leaves as small circles at the segment endpoints when depth is near max.

   Wind function:
   ```js
   function wind(i, d) {
     let t = millis()*0.001;
     let amp = 0.12 * (0.25 + 0.75 * d/ITERATIONS);
     let phase = t*0.9 + i*0.04 + hash(i)*TWO_PI;
     return amp * sin(phase);
   }
   function hash(i){ return frac(sin(i*12.9898)*43758.5453); }
   ```
   And global lean applied via rotate about base.

   For global lean, I'll wrap the interpretDraw in push(); translate(base); rotate(globalLean); interpretDraw(); pop(); But interpretDraw uses px,py absolute. I'll make baseX,baseY the tree base and draw lines in that coordinate space; the rotate applies to all. But base X,Y is fixed; with rotate about base, the whole tree rotates. Let me apply rotate in draw() before interpretDraw and have interpretDraw use base coordinates. Since rotate affects subsequent drawing commands (line), and I translate to base first... Actually rotate rotates around origin; I want around base. So: push(); translate(baseX, baseY); rotate(lean); then interpretDraw draws relative to (0,0) base? Let me have interpretDraw start at (0,0) (the base) and heading up. Then the translate+rotate positions the whole tree. 

   Let me set base at bottom-center: baseX = width/2. And interpretDraw starts px=0,py=0 after the translate. Hmm, but I translate to (baseX, baseY) and then the tree grows upward (negative y). So base local (0,0), growth up. Leaves at negative y. Fine.

   Let me restructure to keep it clean. I'll do in draw():
   ```
   background with gradient (clear, not full repaint for motion trail? No—want full clear each frame).
   ```
   Actually for a swaying tree, clear each frame fully (no trail). Background: dark night gradient.

   Let me make background a starry night gradient for nice contrast, with the tree in the middle. Maybe distant mountains silhouette. Keep it simple: radial gradient dark blue at top → black at bottom. I'll just use a rect with tinted background or a gradient via lerp in a loop. Simpler: background(30,30,50) solid dark, maybe a few white dots (stars). I'll add a few stars for mood. Or keep minimal: dark background.

   Let me add a simple gradient sky and some stars for atmosphere. And ground at bottom.

   Let me write the CSS to make canvas full window and a subtle body bg.

   Also handle windowResized for p5.

   Let me also add a tiny UI hint? Not necessary. Keep full-window canvas.

   For the gradient background each frame, I'll draw a rect filling canvas with lerpColors (no stroke). Then stars (small ellipses) — but stars should be static; I'll precompute star positions in setup and draw each frame (cheap). Or just a dark bg. Let me add ~60 stars as white ellipses with slight twinkle (alpha or size vary by sin). Subtle.

   Ground: a dark green/brown rect at bottom 20%.

   Tree: centered, anchored above ground.

   Let me make the tree base at ~60% height.

   Let me write colors:
   - sky: top #1a1f2d, bottom #0d1017
   - trunk/branch: #8B5A2B (brown) to darker. Use trunkCol = color(120,70,30), tip brown-black.
   - leaves: #2e8b57 green, or mix with tips brighter. Leaf color = color(40,160,70) with some yellow. Let me use a leaf green #3a9d4a.
   - leaves at tips: draw ellipse with leaf color, maybe tinted toward yellow for variety: lerpColor(springGreen, yellowish).

   stroke for branches: I'll use trunkCol lerped toward leaf color with depth so mid-branches transition? That might look odd. Better: all branches brown, leaves green only at tips. Let me do branches brown (darkening slightly with depth), leaves green at depth max.

   strokeWeight: map depth 0..max → 9..1.2.

   Leaves: at depth==max-1 or max, draw ellipse radius ~ map(depth,max,max-2, 2, 5). Color green-ish with slight per-leaf variation (use hash for color jitter).

   Let me code it.

   For line drawing in p5, I can use line() or for thicker branches use beginShape as quads. line() with strokeWeight looks fine and is cheap. I'll use line(). At high strokeWeight the lines will be thick and join-ish; good enough. To look nicer I could draw branches as tapered quads, but that's more code. Let me draw each branch as a quad for a trunk-like tapered look — actually let me keep line() for simplicity but use a decent strokeWeight. Hmm, thick lines with sharp color look okay. Let me try line first; if I want nicer, use quad.

   I'll use a quad-based branch for a nicer 3D-ish look: for each segment, draw a rectangle (quad) from start to end with width = branchWidth, aligned to segment direction. This makes a proper tree silhouette. Let me do quads — it looks much better.

   Branch as quad:
   ```
   let wx = cos(a)*bw, wy = sin(a)*bw; // half-width perpendicular
   let p1x = px - wx, p1y = py - wy;  // wait, perpendicular = (-sin a, cos a)
   ```
   Perpendicular to direction a is (-sin a, cos a). Half-width h = bw/2.
   p1 (start left) = (px - h*sin a, py + h*cos a)  ... let me compute:
   dir = (cos a, sin a). perp = (-sin a, cos a).
   start-left = P + perp*h, start-right = P - perp*h.
   end-left = end + perp*h, end-right = end - perp*h.
   Quad: start-left, start-right, end-right, end-left.
   At the base (depth 0), the start joins the parent; for the very first segment (trunk base), I can draw a cap or just let it be. Fine.

   Using quad fills nicely. Stroke the branches too (brown outline) for definition, or no stroke + fill. Let me fill with branch color and add a dark stroke for outline. Actually outlines on quads can look messy at forks. Let me fill only, with slightly varying brown, and draw leaves as filled ovals. No stroke on branches; stroke on leaf ovals darker green.

   Hmm, forks: where two branches split, there'll be a small gap (the quads don't meet at a point). With thick quads and a sharp fork angle, small gaps appear. Acceptable, or I can draw the fork by making child start width = parent end width and... complex. Let me not worry; with strokeWeight-like quads and gentle angles, gaps are minimal. Alternatively, keep line() which has no gaps at forks (lines meet at points) but lines look less trunk-like. 

   Trade-off: lines = clean forks, less trunk-y. Quads = trunk-y, small fork gaps. I'll go with quads for the trunk-y look and accept tiny gaps; use a slightly darker fill for outer edges by drawing the outline via stroke with no fill? Let me just fill quads with brown; gaps small. Good enough and looks good.

   Actually, to avoid gaps, I can draw a small filled circle/polygon at each fork point (the split point) in the branch color. Cheap and fills gaps. Let me add a tiny circle at segment start points. That's a nice touch (knots) and closes gaps. I'll do it.

   OK, I'll also reconsider: maybe simpler to just use line() with strokeWeight and a nice cap. p5 line with strokeCap(ROUND) gives rounded ends, no gaps at forks visually (they overlap at the point). Round caps on thick lines look nice and meet at forks cleanly. That's actually the simplest clean solution! Let me use line() with strokeCap(ROUND) and strokeJoin... lines don't have joins but round caps overlap. Good.

   Decision: use line() with strokeCap(ROUND), strokeWeight by depth, branch color brown. Leaves as ellipses at tips. Clean, no gaps, looks good. 

   Wait, but thick lines drawn from parent end to child start: the trunk base starts at base point. Round caps. The forks: parent segment ends at split point (round cap), child segment starts at same split point (round cap). They overlap at the point → seamless. 

   Let me go with lines + round cap. Simpler and clean. I'll use strokeWeight up to ~10 at base.

   Hmm, very thick lines (10px) with round cap look quite trunk-like. Good.

   Let me also add a subtle drop shadow or glow? Not needed. Keep clean.

   Let me write the final code.

   One concern: performance of re-interpreting the string (with wind) every frame and drawing ~511-1023 quads/lines. 1000 line draws/frame at 60fps is trivial for p5/webgl... wait, default p5 is 2D canvas (not webgl). 1000 line() calls on 2D canvas per frame = fine. Stars 60 ellipses. Background gradient rect. All fine.

   Actually depth 10 → F count: let me compute. Rule X→F[+X][-X]. Starting X. Each X replaced by F + [ + X + ] + [ + X + ]. So each X → 1 F + 2 X. Number of X: 1,2,4,... doubles. Number of F equals number of X replaced. After d iterations, total F = 2^d - 1. d=10 → 1023 F. Plus brackets. Interpreting 1023 segments/frame, drawing 1023 lines — fine (~60fps in canvas). Let me maybe use d=9 (511 lines) to be safe and lighter, still looks dense. I'll use 9. Actually 10 is fine; let me use 9 for performance margin. Hmm, 9 vs 10 not huge. I'll use 9.

   Wait, but I also want leaves at tips. Tips are at depth 9 (max). Number of leaves ~ 2^9 = 512. Drawing 512 ellipses + 511 lines = ~1000 draws. Fine.

   Actually with leaves at every max-depth segment end, that's 512 leaf ovals. Good, full canopy.

   Let me write it. I'll make leaf color vary (green to yellow) using depth and hash for natural speckles.

   Let me write the L-system interpretation carefully regarding depth and the `[`/`]` and leaves.

   Also, the wind phase using segIndex (global counter across the whole string) — segIndex increments per F in string order. String order = depth-first drawing order. So segIndex correlates with "distance along the traversal". The wave travels in segIndex. Combined with time, wave moves. Good. And hash(i) gives per-segment phase jitter. Good.

   Let me make sure wind doesn't make branches intersect weirdly — it's fine, small angles.

   Let me also ensure the tree stays roughly within canvas with wind (it will, small sway).

   Let me also add: the global lean rotates the whole tree about its base. I'll compute lean and apply.

   Let me write the p5 code now.

   ```js
   let lsys = "";
   const AXIOM = "X";
   const RULES = { X: "F[+X][-X]" };
   const ANG = radians(24);
   const GEN = 9;
   const LEN0 = 120;
   const SHRINK = 0.7;

   const skyTop, skyBot;
   const trunkCol, leafCol, leafCol2;
   let stars = [];

   function setup() {
     createCanvas(windowWidth, windowHeight);
     angleMode(RADIANS);
     generate();
     skyTop = color(26,31,45);
     skyBot = color(13,16,23);
     trunkCol = color(120,78,38);
     leafCol = color(52,170,70);
     leafCol2 = color(120,190,60);
     for (let i=0;i<80;i++){
       stars.push({x:random(width),y:random(height*0.6),s:random(0.5,1.6)});
     }
   }

   function generate(){
     lsys = AXIOM;
     for (let i=0;i<GEN;i++){
       let nx="";
       for (let c of lsys){
         if (RULES[c]) nx+=RULES[c]; else nx+=c;
       }
       lsys=nx;
     }
   }

   function draw(){
     // sky gradient
     for (let i=0;i<=height;i++){
       let inter = i/height;
       stroke(lerpColor(skyBot,skyTop,inter));
       line(0,i,width,i);
     }
     // stars twinkle
     for (let s of stars){
       let a = 180+40*sin(millis()*0.001 + s.x*0.01);
       fill(255,a);
       noStroke();
       ellipse(s.x,s.y,s.s);
     }
     // ground
     fill(18,24,20);
     noStroke();
     rect(0, height*0.72, width, height*0.28);
   
     const t = millis()*0.001;
     const lean = 0.07*sin(t*0.7);
     const baseX = width/2;
     const baseY = height*0.74;
   
     push();
     translate(baseX, baseY);
     rotate(lean);
     interpret();
     pop();
   }

   function interpret(){
     let px=0, py=0;
     let heading = -PI/2;
     let depth=0;
     let idx=0;
     let st=[];
     for (let c of lsys){
       if (c==='F'){
         let len = LEN0*pow(SHRINK,depth);
         let w = wind(idx,depth,t);
         let a = heading + w;
         let nx = px + len*cos(a);
         let ny = py + len*sin(a);
         let bw = map(depth,0,GEN,9,1.2);
         strokeWeight(bw);
         strokeCap(ROUND);
         stroke(lerpColor(trunkCol, skyBot, depth/GEN*0.3)); // darken slightly? 
         line(px,py,nx,ny);
         // leaf at tip if deep
         if (depth >= GEN-1){
           let leafSize = map(depth,GEN-1,GEN,4,2.5);
           let col = lerpColor(leafCol, leafCol2, hash(idx));
           // also yellowish for some
           if (hash(idx+7)<0.15) col = color(200,190,60);
           fill(col);
           noStroke();
           ellipse(nx, ny, leafSize, leafSize*0.7);
         }
         px=nx; py=ny; idx++;
       } else if (c==='+'){
         heading+=ANG;
       } else if (c==='-'){
         heading-=ANG;
       } else if (c==='['){
         st.push({px,py,heading,depth});
         depth++;
       } else if (c===']'){
         let s=st.pop();
         px=s.px; py=s.py; heading=s.heading; depth=s.depth;
       }
     }
   }

   function wind(i,d){
     // need t; pass via closure or global
   }
   ```
   I need t accessible in wind. I'll compute t in draw and pass, or use a module-level `let t`. Let me make wind take (i,d) and use a global `windT`. Set windT = t in draw before interpret. Or just inline wind calc in interpret. I'll inline to keep simple, but a helper is cleaner. Let me make wind(i,d,tt).

   Actually, cleaner: define wind as a function using millis() directly:
   ```
   function wind(i,d){
     let tt = millis()*0.001;
     let amp = 0.13*(0.2 + 0.8*d/GEN);
     let ph = tt*0.9 + i*0.035 + hash(i+3)*TWO_PI;
     return amp*sin(ph);
   }
   ```
   That's fine; calling millis each segment is okay (or cache). I'll cache tt once per frame in draw and pass. Let me pass tt.

   Let me also reconsider the global lean + per-segment wind both using sin(t*0.7 and t*0.9) — slightly different frequencies → natural drift. Good.

   hash function: 
   ```
   function hash(i){ return frac(Math.abs(Math.sin(i*12.9898))*43758.5453); }
   ```
   p5 has `frac`? No, that's glsl. In JS use x - floor(x) or `(n % 1 + 1) % 1`. I'll write `function hash(i){let n=Math.sin(i*12.9898)*43758.5453;return n-Math.floor(n);}`.

   lerpColor in p5: color(lerp...) available. color() with 3 args. lerpColor(c1,c2,amt). Good.

   For branch stroke color: I want brown that darkens with depth. trunkCol brown, and darken. `lerpColor(color(80,45,20), trunkCol, ...)`? Let me just use a brown that darkens: base brown = color(130,80,40); at tip darken: lerpColor(base, color(40,25,12), depth/GEN). That gives darker branches higher up. Leaves green. Good.

   Let me also draw a small brown cap at the very base of trunk (where it emerges from ground) — a filled oval. And maybe roots? Keep simple: base oval.

   Also, the ground rect behind; tree base slightly overlaps. Fine.

   Let me also add subtle fog/mist? No.

   Let me reconsider the sky gradient loop drawing `height` horizontal lines each frame — that's up to ~900 line() calls (for 1080p) plus stars and tree. Totally fine.

   Actually drawing a full-height gradient via per-pixel line is a bit heavy but okay. Alternatively use a shader or set pixels. Line loop is fine for typical resolutions. I'll keep it but maybe downsample: step of 2. I'll do step 1; if slow, step 2. For safety use step 1 (900 lines is nothing).

   Hmm, on a large monitor height=1440 → 1440 lines + 80 stars + 511 tree lines + 512 leaves = ~2600 line/ellipse per frame. p5 2D canvas handles this easily at 60fps. Fine.

   Wait, 512 leaves as ellipses (noFill, filled) — each ellipse is a filled shape; 512 ellipses fine.

   Let me reconsider GEN. GEN=9 → ~511 lines. Could go 10 (1023) but I'll keep 9 for canopy density balance. Actually 9 gives a nice tree. Let me use 9.

   Hmm, let me reconsider the rule for a fuller tree. X→F[+X][-X] binary, angle 24°. At GEN 9 it's a big symmetric triangular fractal tree. With leaves at all depth-9 tips (512 leaves) it forms a green canopy. Looks good.

   Let me also vary branch length shrink so not too dense: SHRINK 0.7 fine.

   Let me also add slight angle randomness? If deterministic angle, tree symmetric. Wind breaks symmetry dynamically. I think that's fine and elegant. But a purely symmetric tree with symmetric wind (phase by segIndex, which is symmetric in the string?) — is the wind symmetric? segIndex increases in string order; the string for X→F[+X][-X] is: F [ + X ] [ - X ]. The left branch ([+X]) is generated with lower segIndex, right with higher. So wind phases differ → asymmetrical sway dynamically. Good, avoids static symmetry.

   Alright, let me also make the tree's base anchor: I push() translate to baseX,baseY then rotate(lean). interpret starts at (0,0) heading -PI/2 (up). Good. base at height*0.74 (above ground top at 0.72). Slight overlap with ground. Fine; maybe base at 0.70 so it sits on ground. Let me set baseY = height*0.70 and ground top = height*0.72 (slight overlap so trunk meets ground). Actually let me make ground top = height*0.68 and base at 0.68 so trunk sits on ground line. Hmm. Let me set baseY = height*0.66, ground fills y from 0.66 to bottom. Clean.

   Wait, then tree grows from y=0.66*height going up (negative y) into canvas. Good. Leaves canopy at top (~ -LEN0*sum... tall). Should fit.

   Let me compute tree height: trunk-ish. Total vertical extent ≈ LEN0 * (1 + SHRINK + SHRINK^2 + ... up to 9) ≈ 120 * (1/(1-0.7)) but only along central spine; actually the tree width (horizontal) is the concern for canopy. With angle 24°, spread ~ fine. Should fit in canvas. Good.

   Let me also draw a subtle moon or not. Keep minimal—stars + tree + ground. Good enough and performant.

   Now, let me make the wind gentler as requested ("sways gently"). amp ~0.13 rad ≈ 7.5°, growing to ~0.13*(0.2+0.8)=0.13 rad at tips (d=GEN gives 0.2+0.8=1.0 → 0.13 rad). Plus global lean 0.07 rad (4°). Total tip sway ~ a few degrees. Gentle. Good. Maybe increase just a touch: amp 0.16 rad. I'll use 0.15. Fine.

   segIndex phase step 0.035: over 511 segments → ~18 rad ≈ 3 waves. Good, subtle ripple.

   Let me finalize and write the file.

   Let me also make sure to call noLoop? No, we want animation. draw runs continuously. Good.

   For window resize: windowResized(){resizeCanvas(windowWidth,windowHeight);} and use no setAttributes. Good.

   Let me write the CSS: body margin 0, overflow hidden, background #000 (canvas covers). Canvas display block.

   Let me write it all.

   Also, I realize I should double check: p5 global mode, functions setup/draw at top level, color/lerpColor etc. work. `frac` not used in JS. `pow`, `cos`, `sin`, `map`, `lerpColor`, `color`, `stroke`, `fill`, `line`, `ellipse`, `rect`, `noStroke`, `noFill`, `strokeWeight`, `strokeCap`, `angleMode`, `createCanvas`, `push/pop`, `translate`, `rotate`, `millis`, `windowWidth`, `windowHeight`, `random`, `TWO_PI`, `PI`, `RADIANS`. All standard p5 global. Good.

   One thing: drawing the sky gradient uses stroke per line with lerpColor each frame — fine.

   Let me write leaves color with alpha? Keep opaque.

   Let me also add a thin outline on leaves for crispness: stroke(20,80,20) dark green, strokeWeight(0.5) before ellipse? But I set noStroke elsewhere; I'll set stroke for leaves. Minor. I'll do dark green stroke on leaves.

   Actually to avoid state juggling, I'll draw leaves with fill and a dark stroke. Set stroke(leaf dark) strokeWeight(0.6); then ellipse. After, branches use stroke(branch). Manage state carefully.

   Let me order: branches first (drawn in interpret with their own stroke per segment). Leaves drawn at segment ends within interpret too. So within interpret loop, for a leaf segment I set fill+stroke for leaf, draw ellipse. Then continue (branch stroke set on next F). Fine.

   Let me write the code cleanly.

   I'll precompute `const SKY_BOT_DARK` etc.

   Let me write everything now.

   Let me reconsider: do I even draw leaves during the line interpretation? Yes, at depth max. But depth max segments also draw a line (the branch). So a leaf sits at end of a thin branch line. Good—looks like leaf cluster at branch tip. Actually at depth GEN-1 (the max, since we generate GEN iters, the deepest X became F[+X][-X] at iter GEN-1? Let me think: GEN iters produce depth up to GEN. At depth GEN the X's haven't been replaced (we stopped). Wait, generation: start "X" (depth 0). Iter 1: X→F[+X][-X], producing X's at depth 1. Each iter replaces X→..., increasing the X's depth. After GEN iters, the deepest X's are at depth GEN and remain as "X" (not replaced further) — but our interpreter doesn't handle 'X' (ignore, no action). So the leaves are where X remains at depth GEN (no F drawn there). Hmm, that means the tips are X (no segment, no leaf) → leaves won't draw at tips because the last replacement left X unexpanded.

   Let me reconsider generation count and leaf placement. If I generate GEN=9, the deepest replaced X's (at depth 9 before replacement) become F[+X][-X], creating F at depth 9 and X at depth 10. The X at depth 10 are unexpanded (no F drawn). So deepest DRAWN F is at depth 9. Leaves should be at depth 9 (the last drawn segments). So `if (depth >= GEN-1)` i.e. depth >= 8 or 9. Let me draw leaves at depth == GEN-1 (9? let me set). Hmm, indexing: depths of F range 0..GEN-1 (since the F appears in replacement of X at depth d, creating F at depth d and X at depth d+1). After GEN iterations, X at depth GEN exist unexpanded. F drawn at depths 0..GEN-1. So max depth for F = GEN-1. Leaves at depth == GEN-1. And GEN = number of iterations. Let me set GEN=9 → F depths 0..8, leaves at depth 8. seg count = 2^8=256 leaves, 255 branches. Lighter. Let me use GEN=9. Or GEN=10 → 511 leaves. Let me use GEN=9 for a slightly lighter, still lush tree. Eh, 10 looks denser. I'll use 9 (balance). Actually let me use 9.

   So: leaves at `depth === GEN-1` (i.e., === 8). Branch width map(0..8, 9..1.2). Leaf only at depth 8. Good.

   But wait: at depth GEN-1=8, the segment F is the last before the unexpanded X. After this F, we hit [ (depth→9) then X (no-op) then ] etc. So the leaf at end of the depth-8 F is the tip. 

   Also I set `if (depth >= GEN-1)` → only depth 8 (since max F depth is 8). Good. Use === GEN-1.

   Hmm, but actually do I draw leaves at ALL depth-8 segments? There are 2^8 = 256 of them (the leaf tips). Yes, canopy. Good. 256 leaf ovals.

   But also each depth-8 F is followed by [+X][-X] which does nothing (X no-op) — no child segments. So the leaf tips are clean. 

   Wait, but depth-8 F is from replacing a depth-8 X. That depth-8 X was created in the previous iter from depth-7 X→... So the depth-8 X's are replaced in iter 8 (0-indexed?) Let me just trust the code and set leaves at depth===GEN-1. With GEN iterations, max F depth = GEN-1. I'll set leaves at depth >= GEN-1 (same as === GEN-1). Good.

   Let me set GEN = 9. Then 256 leaves, 255 branch segments. Wait total F = 2^(GEN-1) = 2^8 = 256? No: total F after GEN iters = 2^GEN - 1? Let me recompute: replacement X→F[+X][-X] produces one F and two X per X. So #F = #X_replaced. #X at each level doubles. After GEN iters, total F = sum over levels? Actually each iter replaces ALL current X with F+2X. The number of F created in iter k = (number of X before iter k). #X before iter k = 2^(k-1) (iter 1: 1 X → creates 1 F, 2 X; iter2: 2 X → 2 F, 4 X; ... iter k: 2^(k-1) X → 2^(k-1) F). Total F after GEN iters = sum_{k=1}^{GEN} 2^(k-1) = 2^GEN - 1. For GEN=9: 2^9-1 = 511 F. Hmm so 511 segments, not 255. Because both intermediate and final iters' F remain. The deepest F (iter 9) = 2^8 = 256 leaves. Plus intermediate F (branches) = 511-256 = 255 branch segments. So leaves = 256, branches = 255. 

   Wait that doesn't match "max F depth = GEN-1". Depth of F created in iter k = k-1 (since created by replacing X at depth k-1). So F depths range 0..GEN-1, with count at depth GEN-1 = 2^(GEN-1)=256. Sum = 2^GEN - 1 = 511. Good, consistent. So leaves (depth GEN-1=8) = 256. 

   OK so GEN=9 gives 511 segments, 256 leaves. Fine. Let me use GEN=9.

   Hmm 256 leaf ellipses + 511 lines = 767 draws + gradient. Fine.

   Let me maybe bump to GEN=10 for 1023 segments — could be slow-ish but probably fine. I'll keep 9 to be safe and clean. Actually, you know, let me use 9.

   Wait, I realize the wind phase using segIndex (0..510) * 0.035 gives phase up to ~18 rad — fine.

   Let me also make leaves a bit larger and overlap to form a solid canopy. leafSize map(depth,8,8, 5,5) → constant ~5px. 256 small ovals. Good. Maybe size 6. I'll do leafSize = 5 + 2*hash(idx) (jitter 5-7). 

   Alright, writing the file now. Let me make the code clean and commented.

   Let me also reconsider: stroke for branches uses lerpColor; on 2D canvas, stroke with color works. strokeWeight up to 9 → thick lines, round cap. The trunk (depth0) width 9. Looks good.

   Also I should set `noFill()` for lines? line uses stroke, no fill needed. But ellipse needs fill. I'll manage.

   For branch color darkening with depth: `let bc = lerpColor(trunkColDark, trunkCol, depth/GEN)`. Where trunkColDark = color(60,35,16), trunkCol = color(130,80,40). So base trunk brightest brown, tips darker. Hmm, real trees darker at base. Eh, I'll do base darker → trunkCol dark at depth0, brighter? Let me just use trunkCol constant for all branches (uniform brown) — simpler and clean. Leaves green. I'll do constant brown branches. Maybe slight darkening high up for depth cue: negligible. I'll lerp 5%. Keep simple: `stroke(lerpColor(color(70,42,18), trunkCol, depth/GEN))`. trunkCol=color(130,80,40). Good.

   Let me finalize.

   Also add a base "stump" cap: a brown oval at base. And maybe the ground edge. Fine.

   Let me write it.

   Actually, I want to double-check the wind doesn't blow branches through each other badly. amp ~0.13 rad (7.5°) at tips, base small. The tree is wide; small sway won't cause ugly intersections. Fine.

   Let me also ensure the global lean and wind use consistent time. Good.

   I'll now write index.html.

   Let me write the CSS for a nice full-page look with maybe a title overlay? Keep minimal—just canvas. Maybe a small footer credit "L-system fractal tree • wind". Subtle. I'll add a small fixed top-left label via HTML or canvas text. I'll draw text in canvas: top-left "L-System Fractal Tree". Subtle white text. Optional. I'll add it; looks polished.

   Let me write.

   Let me write the final HTML.

   I need to be careful: in p5 global mode, `setup` and `draw` must be global functions (not inside an object). I'll define them as top-level functions in the script. Good.

   Also `function windowResized()` global. Good.

   Let me write the code.

   For the gradient, instead of height lines, I'll do a more efficient approach: actually height lines is fine. Or use `set`/`pixels`? Lines fine.

   Hmm, one concern: drawing the gradient with `line(0,i,width,i)` sets stroke each iteration via lerpColor. lerpColor each of ~height times per frame. For 1080p that's 1080 lerpColor calls/frame. Trivial. Fine.

   Let me write.

   Actually, let me reduce gradient cost by stepping 2 and drawing thicker lines? No, step 1 for smoothness. Fine.

   Let me write the file now.

   Final code:

Standard p5 v1.9.4 global build. Now let me write the index.html.