diff --git a/docs/ISSUES.md b/docs/ISSUES.md
index 79ece7b..1dad84c 100644
--- a/docs/ISSUES.md
+++ b/docs/ISSUES.md
@@ -292,10 +292,60 @@ missing is the plugin-API surface.
 
 ---
 
+## #27 — Cloud meshes appear missing or faint compared to retail
+
+**Status:** OPEN
+**Severity:** LOW (aesthetic feature-parity — doesn't break gameplay)
+**Filed:** 2026-04-26
+**Component:** sky / clouds
+
+**Description:** After fixing Bug B (#26 — stars-as-square), the user observed during visual verification that cloud coverage in the sky doesn't match retail. Cloud meshes are authored in the dat (e.g. `0x010015B6`, `0x01004C35`-`0x01004C38`, `0x01004C36` etc) and `tools/StarsProbe` confirms they're loaded into the SkyObject lists with non-zero TexVelocity (so they get GL_REPEAT correctly under the post-#26 code path). They're not strictly missing — they're rendered — but their visual presence falls short of retail.
+
+**Root cause / status:** Unknown. Hypotheses: (a) cloud surfaces' alpha/blend mode is too subtle (cloud surface flags or shader path under-emphasise the texture); (b) cloud meshes positioned/scaled wrong relative to the dome so they're inside the dome and occluded; (c) DayGroup keyframe interpolation suppresses cloud transparency at certain times of day; (d) some cloud SkyObjects we should be rendering are filtered out by a Properties bit we mis-handle (Props=0x02 might mean something more than "cloud — render it"); (e) retail uses an additive cloud blend that our Translucency classifier doesn't apply.
+
+**Files:**
+- `src/AcDream.App/Rendering/Sky/SkyRenderer.cs` — sky pass; check per-cloud blend / luminosity / transparency.
+- `src/AcDream.Core/World/SkyDescLoader.cs` — Properties bit decoding.
+- `src/AcDream.App/Rendering/Shaders/sky.frag` — cloud transparency math.
+- `tools/StarsProbe/` — already dumps cloud GfxObj UVs + bounds; extend to dump per-DayGroup cloud surface flags.
+
+**Research:** None yet. `tools/StarsProbe` output already enumerates which DayGroups reference which cloud meshes — start there.
+
+**Acceptance:** Side-by-side launch of acdream and a retail client at the same `ACDREAM_DAY_GROUP` shows visually-comparable cloud coverage in the sky.
+
+---
+
+## #28 — Aurora ("northern lights") effect not rendered
+
+**Status:** OPEN
+**Severity:** LOW (aesthetic feature-parity)
+**Filed:** 2026-04-26
+**Component:** sky / vfx
+
+**Description:** Retail occasionally renders an aurora-borealis-style "northern lights" effect in the sky during certain weather/time conditions. acdream renders no aurora at all.
+
+**Root cause / status:** Unknown — the mechanism hasn't been investigated. Aurora is NOT in the visible SkyObject lists (`tools/StarsProbe` shows the standard 7-object Sunny/Clear/Cloudy DayGroup composition, with extra weather objects in Rainy groups). Hypotheses: (a) it's a special PES on a low-probability DayGroup not yet enumerated; (b) it's a separate shader path not driven by `Region.SkyInfo`; (c) it requires a specific weather/time combo we haven't triggered; (d) it's an entirely separate `EnvironChangeType` system we don't decode.
+
+**Files:** Unknown.
+
+**Research:** None yet. Probably needs a retail-decomp grep for "aurora", "northern", a 360° survey of DayGroup PES contents, and possibly a deepdive into the `LScape::weather_enabled` and `EnvironChange*` paths.
+
+**Acceptance:** When retail shows an aurora at a specific in-game time / weather, acdream shows a visually-comparable effect at the same time.
+
+---
+
 ---
 
 # Recently closed
 
+## #26 — [DONE 2026-04-26] Stars rendered as a square in one corner of the sky
+
+**Closed:** 2026-04-26
+**Commit:** `7b88fde fix(sky): drive wrap mode from mesh UV range — fixes Bug B (stars-as-square)`
+**Resolution:** SkyRenderer's wrap-mode heuristic was `GL_CLAMP_TO_EDGE unless TexVelocity != 0`, which mis-classified the inner sky/star layer `0x010015EF` (UVs in `[0.398, 4.602]`, TexVel=0). Most of the dome sampled the texture's edge texels; only the small region where UVs fell in `[0,1]` showed actual texture content. Fixed by computing `NeedsUvRepeat` per submesh from the actual UV range during `GfxObjMesh.Build()` and driving the wrap-mode choice from that flag plus the existing scrolling check. Outer dome `0x010015EE/F0/F1/F2` (UVs strictly in `[0,1]`) keeps `CLAMP_TO_EDGE` so no seam regression. Probe `tools/StarsProbe/` (commit `991fb9a`) committed alongside as the diagnostic that found this.
+
+---
+
 ## #25 — [DONE 2026-04-26] Phase K.3 — Settings panel + click-to-rebind UI
 
 **Closed:** 2026-04-26