docs+ci: add Native-Cinny design law; harden npm ci against transient ECONNRESET

- LOTUS_TODO.md: add a "Native-Cinny Law" — every feature must feel like stock
  Cinny (folds primitives + tokens, mirror existing patterns), the sole
  exception being opt-in Lotus Terminal (TDS) features. Links the Cinny repo.
- ci.yml: the last build failed on a transient registry ECONNRESET during
  `npm ci`. Raise npm fetch retries/timeouts and retry `npm ci` up to 3x with
  backoff so a flaky network read no longer fails the whole build.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.gitea/workflows/ci.yml

@@ -21,7 +21,24 @@ jobs:
           cache: npm
 
       - name: Install dependencies
-        run: npm ci
+        # Harden against transient registry network failures (ECONNRESET etc.):
+        # raise npm's built-in fetch retries/timeouts and retry `npm ci` up to
+        # 3 times with backoff before failing the build.
+        run: |
+          npm config set fetch-retries 5
+          npm config set fetch-retry-mintimeout 20000
+          npm config set fetch-retry-maxtimeout 120000
+          npm config set fetch-timeout 600000
+          for attempt in 1 2 3; do
+            echo "npm ci attempt $attempt…"
+            npm ci && break
+            if [ "$attempt" = "3" ]; then
+              echo "npm ci failed after 3 attempts" >&2
+              exit 1
+            fi
+            echo "npm ci failed; retrying in $((attempt * 15))s…" >&2
+            sleep $((attempt * 15))
+          done
 
       # ── Critical gate — if this fails, nothing deploys ──────────────────
       - name: Build

LOTUS_TODO.md

@@ -37,6 +37,20 @@
 
 ---
 
+## 🧩 NATIVE-CINNY LAW — EVERY FEATURE MUST FEEL LIKE STOCK CINNY
+
+> **Every feature we implement must feel native to the upstream Cinny app — indistinguishable from something the Cinny team would have shipped.** Reference: <https://github.com/cinnyapp/cinny>.
+>
+> Concretely this means:
+>
+> - **Use the `folds` design system, not bespoke UI.** Build with folds primitives (`Button`, `Chip`, `IconButton`, `Menu`, `MenuItem`, `Dialog`, `Modal`, `Input`, `Switch`, `Badge`, `SettingTile`, `SequenceCard`, etc.) and folds tokens (`color.*`, `config.space.*`, `config.radii.*`, `config.borderWidth.*`). No hardcoded hex/`rgba()` for UI chrome, no invented/undefined CSS variables.
+> - **Match Cinny's existing patterns.** Before adding UI, find the closest existing Cinny component/flow and mirror it (e.g. a new dropdown uses `Button`+`PopOut`+`Menu`+`MenuItem` like the rest; a new modal has a `Header` with a close `IconButton`; a new setting is a `SettingTile` inside a `SequenceCard`). Consistency with stock Cinny beats personal style.
+> - **Lotus-custom additions should be unobtrusive** and fit Cinny's visual language, spacing, and interaction conventions — a stranger using Cinny should not be able to tell which features are ours.
+>
+> **The ONE exception:** explicit **Lotus Terminal Design System (TDS)** features, which intentionally have their own distinct look and follow the **TDS Design Law** above. TDS styling is opt-in (only active in Lotus Terminal mode); everything else must look and feel like native Cinny.
+
+---
+
 Completed features are documented in [LOTUS_FEATURES.md](./LOTUS_FEATURES.md).
 
 ---