wings

Use WINGS's built-in widgets instead of hand-rolling them — button (w-button), text input (w-input), rich-text editor (w-text), tabbed containers (w-tabs/w-tabbutton/w-tab), dialogs (w-dialog), multi-select combobox (w-combobox), record navbar (w-navbar), and the skin picker (skin-switcher). Use when an app needs any of these controls.

Security peculiarities of Go-to-WASM in the browser, for apps you build with WINGS — the syscall/js trust boundary, panic = whole-app death, the innerHTML/XSS invariant, secrets in browser memory, single-thread concurrency, GOOS=js tooling gaps. Use when writing or reviewing any component (GOOS=js code), DOM interop via syscall/js, fetch, or browser-delivered features in your app.

Write a WINGS component (custom element in Go→WASM) — module file trio, wings.Register, the PranaMod lifecycle (InitData/Render), template binding syntax ({{expr}}, ?cond, *arr/**arr, &attr, @event), and parent-child events. Use when creating or editing a WINGS module, template, custom element, PranaMod, or any template binding.

Internationalize a WINGS app — author plain text that the gen_i18n build step extracts into per-language catalogs, runtime lookup via wi18n, translatable attributes, opting out, plurals/gender flexion ({{@g %n ~word}}), locale-aware formatting ({{%price}}), and runtime locale switching (SetLang). Use when adding translatable text, plurals/gender, number/currency/date formatting, or a language switcher.

Theme a WINGS app with --wings-* skin tokens — consume tokens in component CSS via var() with fallbacks, apply/compose built-in skins (ApplySkin), the ten disjoint skin categories and multi-skin composition, register your own skin, bundles (composed skins), and private categories. Use when styling components to be theme-aware, applying or composing skins, or building a theme.

Apollo AGC fail-operational design (priority shedding, bounded everything, restart protection, NASA Power of 10) applied to YOUR WINGS app — loops, goroutines, timers, fetch error paths, recovery. Use when writing component effects, background goroutines, polling/retry, or any code that must keep the app rendering when one part fails.

Continuous fuzzing with Go native fuzzing for any parser/decoder YOU add to a WINGS app — keeping parseable logic in portable (non-js) packages so it's fuzzable, writing targets, the properties to assert, corpus management. Use when you add or change any string/byte parser, custom wire format, or decoder in your app.

Input validation and parsing discipline for WINGS apps (djb "don't parse" + Margaret Hamilton's defensive design) — applied to YOUR boundaries — fetch/API responses, form fields, URL hash/query, postMessage, localStorage, and js.Values. Use when writing or changing any code in your app that reads data from outside the wasm module.

djb's trusted-code minimization applied to YOUR WINGS app — keep parsing at build time, design misuse-resistant APIs, add the fewest deps and config knobs, don't evaluate user strings at runtime. Use when designing a new component/package/public helper, adding a dependency or config option, or reviewing a diff that grows your app.

Dependency and artifact integrity for YOUR WINGS app — adding/updating Go modules, pinning the wings version, govulncheck (native + GOOS=js passes), SRI on served scripts, signing the catalogs you ship, Docker FROM wings, never baking secrets into images. Use whenever your go.mod/go.sum changes, you prepare a release, or you serve/fetch an artifact.

Set up, build, and serve a WINGS app — Go module setup, the WASM build (GOOS=js), copying the JS runtime helpers, a static dev server, and the cross-platform cmd/build orchestrator (targets + the camelCase binding lint + rebuild-on-save dev mode). Use when scaffolding a new WINGS project, configuring its build, wiring main.go, or setting up a dev server / dev loop.

Apollo AGC philosophy (restart protection, priority shedding, bounded everything, NASA/JPL Power of 10) applied to wings runtime and tooling. Use when writing loops, goroutines, recovery paths, watchers, schedulers, or any code that must keep working when something else fails.

Continuous fuzzing discipline for wings using Go native fuzzing — what to fuzz (expr parsers, gen_i18n, codec, signature verification), how to write targets, corpus management, CI budget. Use when adding/changing any parser or decoder, or when asked to improve test coverage of input handling.

Input validation and parsing discipline (djb "don't parse" + Margaret Hamilton's defensive design) for wings. Use when writing or changing any code that reads catalogs, templates, flex blocks, URLs, env vars, fetch responses, js.Values, or webdev-supplied attributes.

Apply djb's trusted-code minimization when adding features, dependencies, APIs, or config options to wings. Use when designing new packages, public APIs, build steps, or when reviewing a diff that grows the codebase.

Dependency and artifact integrity for wings — adding/updating Go modules, auditing transitive deps, govulncheck, reproducible builds, SRI, catalog signing, Docker base images. Use whenever go.mod/go.sum changes, a release is prepared, or fetched/served artifacts are touched.

Security peculiarities of Go compiled to WASM in the browser — syscall/js trust boundary, panic semantics, innerHTML/XSS invariant, secrets in browser memory, single-thread assumptions, GOOS=js tooling gaps. Use when writing or reviewing any GOOS=js code, DOM interop, or browser-delivered features.