claude-toolkit 0.16.0 → 0.17.0

package/docs/best-practices/capacitor/channels-and-rollouts.md

@@ -1,101 +0,0 @@
-# Channels & Staged Rollouts
-
-> A channel is a pointer to one JS bundle. Devices subscribe to a channel; you change which bundle the channel points to. That indirection is what makes rollout and rollback instant and rebuild-free.
-
-## The Channel Ladder
-
-Mirror your release pipeline with channels, and version bundles with semver pre-release tags so relationships are obvious:
-
-| Channel       | Bundle version | Audience                  |
-| ------------- | -------------- | ------------------------- |
-| `development` | `1.2.3-dev.1`  | dev / emulator builds     |
-| `qa`          | `1.2.3-qa.1`   | QA verification           |
-| `staging`     | `1.2.3-rc.1`   | production-like sign-off  |
-| `production`  | `1.2.3`        | end users (store version) |
-
-Promote a build up the ladder by uploading (or re-pointing) it to the next channel — no native rebuild between stages.
-
-```bash
-npx @capgo/cli@latest bundle upload --channel=staging       # ship to staging
-# ...QA signs off...
-npx @capgo/cli@latest bundle upload --channel=production     # promote to production
-npx @capgo/cli@latest channel set production -s default      # ensure it's the cloud default
-```
-
-## Channel Precedence
-
-When a device checks for updates, Capgo resolves the channel in this order (highest wins):
-
-1. **Forced device mapping** — pin specific device IDs (testing/exception layer).
-2. **Cloud per-device override** — dashboard/API change for one device (up to ~2 min to propagate).
-3. **Config `defaultChannel`** — set in `capacitor.config` (baked into the binary).
-4. **Cloud Default Channel** — the fallback ~99% of users follow.
-
-**Production rule:** ship production binaries **without** `defaultChannel`. If you bake a channel into the binary, those users stop following the cloud default — which is exactly the lever you use for instant rollout and rollback. Reserve `defaultChannel` for builds you hand directly to testers.
-
-## Runtime Switching with setChannel()
-
-Let users opt into a beta from inside the app:
-
-```typescript
-import { CapacitorUpdater } from "@capgo/capacitor-updater";
-
-await CapacitorUpdater.setChannel({ channel: "beta", triggerAutoUpdate: true });
-```
-
-- Requires **"Allow device self-assignment"** enabled on the target channel; otherwise the call fails.
-- In **plugin v8+**, `setChannel` stores the choice **locally on the device** and takes effect on the next update check — no 2-minute backend replication lag. The backend still validates the self-assignment permission at check time.
-
-```bash
-npx @capgo/cli@latest channel set beta --self-assign        # enable opt-in
-```
-
-## Version Gates: Enforce the Native/Web Contract
-
-Channels can refuse updates that cross a version boundary the native shell can't honor:
-
-```bash
-# Block cross-major OTA on production (e.g. don't push a 2.x bundle to 1.x shells)
-npx @capgo/cli@latest channel set production --disable-auto-update major
-```
-
-| `--disable-auto-update` | Allows                                              |
-| ----------------------- | --------------------------------------------------- |
-| `major`                 | minor + patch within the same major                 |
-| `minor`                 | patch only within the same major.minor              |
-| `patch`                 | patch increments only                               |
-| `metadata`              | requires minimum version metadata on bundles        |
-| `none`                  | all semver-compatible updates                       |
-
-Also available: **disable auto-downgrade** (don't send a bundle older than the device's native version) and per-platform targeting (`--ios`, `--android`). These gates are how you keep a web bundle from landing on a shell that can't run it.
-
-## Staged Rollout Playbook
-
-1. **Canary** — point the channel at the new bundle for ~10% of users (or a dedicated `canary` channel).
-2. **Observe** — watch the success signal for 1–2 hours (next section).
-3. **Widen** — ramp to 100% over ~24h if healthy.
-4. **Schedule** — time heavy rollouts for **1–4 AM local**, Wi-Fi-preferred, so downloads don't compete with active use.
-
-**Benchmarks:** aim for **~95% adoption within 24h** and **~82% global success rate**. Falling short is a signal to pause and investigate, not to widen.
-
-## Rollback
-
-Instant and rebuild-free — the core OTA payoff:
-
-1. Open the channel in the Capgo dashboard.
-2. Find the previous good build and click the **crown icon**.
-3. Confirm. The channel now points at the old bundle; devices pick it up on next check-in.
-
-Because rollback is this cheap, bias toward shipping small and reverting fast over holding releases for exhaustive pre-launch testing.
-
-## Monitoring
-
-- **`appReady` vs `downloadFailed`** — the health ratio. A `downloadFailed` spike, or `appReady` events not keeping pace with downloads, means bundles are failing to boot → roll back.
-- **Capgo stats dashboard** — adoption curve and per-version success rate. Compare against the 95% / 82% benchmarks.
-- **Alert, then act** — wire a threshold alert so a bad canary pages you before you widen.
-
-## See Also
-
-- [Live Updates & OTA Strategy](live-updates-ota.md) — why staged rollout is the whole point
-- [Capacitor 8 Platform](capacitor-8.md) — what makes a bundle native-incompatible
-- [Security & Encryption](security-encryption.md) — signing the bundles a channel serves

package/docs/best-practices/capacitor/live-updates-ota.md

@@ -1,75 +0,0 @@
-# Live Updates & OTA Strategy
-
-> OTA is a delivery mechanism for the **web layer**, not a way around the app stores. The strategy is mostly about discipline: knowing what you can ship over the air, keeping bundles small, and rolling out so a mistake is recoverable.
-
-## What You Can — and Cannot — Ship Over the Air
-
-| Change                                          | OTA? | Why                                                          |
-| ----------------------------------------------- | ---- | ----------------------------------------------------------- |
-| Bug fix in JS/TS                                | ✅   | Pure web layer                                              |
-| Copy, translations, styling                     | ✅   | Static assets in the bundle                                 |
-| New feature built on existing native APIs       | ✅   | No new native contract                                      |
-| Web-only dependency upgrade                     | ✅   | Compiles into the bundle                                    |
-| New Capacitor **plugin** (native code)          | ❌   | Native shell lacks the implementation → crash              |
-| Native dependency / SDK upgrade                 | ❌   | Native binary change                                        |
-| Capacitor **major** version bump                | ❌   | Native runtime change                                       |
-| Permission / entitlement / manifest change      | ❌   | Declared in the native binary                               |
-
-The failure mode is concrete: a bundle that calls `SomePlugin.doThing()` on a shell where that plugin isn't compiled in throws at runtime. **Match every bundle to the native version that can run it.**
-
-## Store Compliance
-
-OTA of interpreted code is explicitly permitted:
-
-- **Apple** — Developer Agreement **§3.3.2** allows OTA of JavaScript and assets executed by the system WebView (since iOS 4.3).
-- **Google Play** — the restriction on non-Play code updates **does not apply** to code running in a VM with limited API access, i.e. JavaScript in a WebView.
-
-What gets apps pulled is shipping *native* executable code OTA. Stay in the web layer and you stay compliant.
-
-## Performance: Keep Bundles Small
-
-Smaller bundles download faster, fail less, and adopt quicker.
-
-- **Delta / differential updates.** Capgo transfers only the files that changed between versions (auto-enabled with direct/instant updates). The win depends on file-level stability — see below.
-- **Deterministic builds.** Strip build timestamps and pin your build tooling so unchanged source produces byte-identical output. Otherwise every file looks "changed" and the delta degrades to a full download.
-- **Compression.** Capgo applies ZSTD compression to full-image updates; you don't configure it, but deterministic builds are what let delta + compression actually shrink the payload.
-- **Prioritize the critical path.** Load auth and main navigation eagerly; lazy-load analytics, settings, animations, and heavy media after first paint. A small critical bundle reaches `notifyAppReady()` faster, which matters because of the rollback timeout.
-
-## Update Timing & Scheduling
-
-- **Off-peak rollouts.** Schedule heavy rollouts for **1–4 AM local time** and prefer Wi-Fi so you're not competing with active use or burning cellular data.
-- **Background application.** The default `atBackground` mode downloads silently and applies when the app backgrounds, so users never watch a spinner. Reserve `onLaunch` / `always` for updates that must take effect immediately (e.g. a hotfix).
-- **Respect `periodCheckDelay`.** Minimum 600s (10 min). Don't try to poll faster — it's clamped.
-
-## Roll Out So You Can Roll Back
-
-The whole point of OTA is that mistakes are cheap to undo. Treat every release as staged:
-
-1. **Canary** to ~10% of users.
-2. **Watch** the success signal (`appReady` vs `downloadFailed`, Capgo stats) for 1–2 hours.
-3. **Widen** to 100% over ~24h if healthy.
-4. **Roll back instantly** from the channel dashboard if not — devices pick up the previous bundle on next check-in.
-
-Healthy benchmarks: **~95% adoption within 24h**, **~82% global success rate**. Below that, investigate before widening.
-
-## The notifyAppReady() Safety Net
-
-This is what makes the above safe. The plugin starts a timer (`appReadyTimeout`, default 10s) when a new bundle loads. If your JS calls `notifyAppReady()` before it fires, the bundle is "confirmed." If it doesn't — because the bundle white-screened or threw on boot — the plugin **automatically reverts** to the last good bundle. A broken OTA release self-heals on the next launch even before you notice.
-
-Call it as early as possible, before heavy async work, so a slow boot doesn't trip the timeout on an otherwise-fine bundle.
-
-## Anti-Patterns
-
-| Anti-pattern                                | Consequence                                                       |
-| ------------------------------------------- | ----------------------------------------------------------------- |
-| OTA-ing a native change                     | Runtime crash on the mismatched shell                            |
-| Non-deterministic builds                    | Delta updates degrade to full downloads                          |
-| 100% rollout, no canary                     | A bad bundle hits the entire user base at once                   |
-| Eager-loading everything                    | Slow boot risks tripping `appReadyTimeout` → false rollback      |
-| Polling faster than 600s                    | Silently clamped; wasted assumption                             |
-
-## See Also
-
-- [Capacitor 8 Platform](capacitor-8.md) — keeping native and OTA in lockstep
-- [Capgo Setup & API](capgo-setup.md) — config and the manual update lifecycle
-- [Channels & Staged Rollouts](channels-and-rollouts.md) — the mechanics of canarying and rollback

package/docs/best-practices/capacitor/security-encryption.md

@@ -1,68 +0,0 @@
-# Security & Encryption
-
-> An OTA bundle travels over the network and lands on devices you don't control. End-to-end encryption with code signing makes each update unreadable in transit and verifiable on arrival — only your users can decrypt it, and only your signed bundles are accepted.
-
-## Why Encrypt
-
-A channel controls *who is eligible* for an update; it does **not** keep the bundle secret. An unencrypted bundle should be treated as a public asset. If your web layer contains anything you don't want readable — proprietary logic, embedded config — encryption is the only thing that keeps it private end to end, including from Capgo itself.
-
-## How v2 Encryption Works (Hybrid RSA + AES)
-
-RSA can't efficiently encrypt large payloads, so Capgo uses a hybrid scheme:
-
-1. A **random AES-256 key** is generated for every upload and encrypts the bundle.
-2. Your **private RSA-2048 key** encrypts (signs) the AES key and the bundle checksum.
-3. The app holds your **public RSA key** (injected at build) and decrypts the AES key + signature.
-4. The app decrypts the bundle with the AES key, recomputes the checksum, and compares it against the decrypted signature.
-
-The result: the bundle is confidential (AES) **and** authenticated (RSA signature over the checksum). Tampering breaks the checksum match; a bundle not signed by your private key won't validate.
-
-> Industry baseline this matches: **AES-256** for payloads, **RSA-2048** for key exchange, **SHA-256** for integrity.
-
-## Setup
-
-```bash
-npx @capgo/cli@latest key create                            # generate the RSA key pair
-npx @capgo/cli@latest bundle upload --key-v2 --channel=production
-```
-
-`key create` writes two files and injects the public key into your Capacitor config:
-
-| File                  | Sensitivity | Rule                                                       |
-| --------------------- | ----------- | ---------------------------------------------------------- |
-| `.capgo_key_v2`       | **Private** | **Never commit.** Store as a CI secret. Loss = can't sign. |
-| `.capgo_key_v2.pub`   | Public      | Safe to commit — it's a backup of the embedded public key. |
-
-Add `.capgo_key_v2` to `.gitignore` immediately. The private key only ever lives on trusted dev machines and in CI secret storage; it's used at upload time to sign, never shipped to devices.
-
-## Strict Enforcement
-
-Once encryption is configured, the plugin **requires** a valid signature on every update — this is enforced, not advisory. An unsigned or tampered bundle is **rejected**, not applied. Practical consequences:
-
-- Every CI upload must run with `--key-v2` and access to the private key, or devices will reject the bundle.
-- Rotating keys requires shipping a new native binary with the new public key; plan it as a store release, not an OTA.
-- `--no-key` (unencrypted) and encrypted uploads don't mix on the same channel for the same audience — pick one posture per channel.
-
-## Integrity Beyond Encryption
-
-- **Checksums** verify the decrypted bundle matches what you signed — corruption or tampering fails closed.
-- **`notifyAppReady()`** is the runtime backstop: even a validly-signed bundle that crashes on boot rolls back automatically (see [Capgo Setup](capgo-setup.md)). Signing proves *authenticity*; `notifyAppReady` proves *it actually runs*. You want both.
-
-## Store Compliance
-
-Encryption doesn't change what you're allowed to ship — it just protects the payload. The compliance rule is unchanged: OTA of **JavaScript/HTML/CSS** is permitted (Apple Developer Agreement §3.3.2; Google Play's webview/JS-VM exemption). Encrypting that web bundle is fine. Encrypting and shipping *native* executable code OTA is still not allowed — encryption is not a loophole around the native/web boundary.
-
-## Checklist
-
-- [ ] `npx @capgo/cli key create` run; `.capgo_key_v2` added to `.gitignore`.
-- [ ] Private key stored as a CI secret; `--key-v2` used on every production upload.
-- [ ] `.capgo_key_v2.pub` committed as a backup.
-- [ ] `notifyAppReady()` present so signed-but-broken bundles still self-heal.
-- [ ] Key rotation planned as a native binary release, not an OTA.
-- [ ] Only web-layer code shipped OTA — never native code, encrypted or not.
-
-## See Also
-
-- [Capgo Setup & API](capgo-setup.md) — the upload flow and `publicKey` config
-- [Channels & Staged Rollouts](channels-and-rollouts.md) — per-channel encryption posture
-- [Live Updates & OTA Strategy](live-updates-ota.md) — what's legal to ship over the air

package/docs/best-practices/solidjs/README.md

@@ -1,43 +0,0 @@
-# SolidJS Best Practices
-
-> A curated collection of SolidJS best practices, patterns, and guidance sourced from the [official SolidJS documentation](https://docs.solidjs.com/), [Ryan Carniato](https://dev.to/ryansolid) (SolidJS creator), and the SolidJS community.
-
-SolidJS uses **fine-grained reactivity** with no virtual DOM. Components run once; only reactive expressions re-execute when dependencies change. This is fundamentally different from virtual DOM frameworks — and most best practices stem from this core difference.
-
-## Reactivity
-
-Understanding reactivity is the foundation of everything in Solid.
-
-| Guide | Summary |
-|---|---|
-| [Reactivity Model](reactivity-model.md) | How fine-grained reactivity works — signals, tracking, subscriptions. |
-| [Signals & State](signals-and-state.md) | `createSignal`, `createMemo`, derived values, and when to use what. |
-| [Stores & Nested State](stores-and-nested-state.md) | `createStore`, path syntax, `produce`, `reconcile` for complex state. |
-| [Effects & Lifecycle](effects-and-lifecycle.md) | `createEffect`, `onMount`, `onCleanup` — and when NOT to use effects. |
-
-## Components
-
-Patterns for building and composing components.
-
-| Guide | Summary |
-|---|---|
-| [Props Patterns](props-patterns.md) | Never destructure. Use `mergeProps`, `splitProps`, `children` helper. |
-| [Component Patterns](component-patterns.md) | Composition, typed components, generic components, refs. |
-| [Control Flow](control-flow.md) | `<Show>`, `<For>`, `<Switch>`/`<Match>`, `<ErrorBoundary>`, `<Suspense>`. |
-
-## Architecture
-
-Scaling patterns for real applications.
-
-| Guide | Summary |
-|---|---|
-| [Data Fetching](data-fetching.md) | `createResource`, `createAsync`, Suspense, error handling, optimistic updates. |
-| [Context & Global State](context-and-global-state.md) | Context + stores pattern, provider factories, avoiding prop drilling. |
-| [TypeScript Integration](typescript-integration.md) | Component types, typed signals/stores/context, event handling, TSConfig. |
-
-## Performance & Pitfalls
-
-| Guide | Summary |
-|---|---|
-| [Performance](performance.md) | `lazy`, `batch`, `untrack`, code splitting, and what Solid optimizes for you. |
-| [Anti-Patterns](anti-patterns.md) | The most common mistakes and how to avoid them. |

package/docs/best-practices/solidjs/anti-patterns.md

@@ -1,166 +0,0 @@
-# Anti-Patterns
-
-> Common SolidJS mistakes sourced from the [SolidJS documentation](https://docs.solidjs.com/), community guides, and [Ryan Carniato's articles](https://dev.to/ryansolid).
-
-## 1. Destructuring Props
-
-The single most common Solid mistake. Props use getters for reactivity — destructuring extracts the value once.
-
-```typescript
-// BROKEN
-const Card = ({ title, count }) => <div>{title}: {count}</div>;
-
-// FIXED
-const Card = (props) => <div>{props.title}: {props.count}</div>;
-```
-
-If you need to separate props, use `splitProps`. If you need defaults, use `mergeProps`.
-
-## 2. Forgetting to Call Signals
-
-Signals are getter functions. Forgetting `()` passes the function itself, not the value.
-
-```typescript
-// BROKEN — passes the function, not the value
-<span>{count}</span>
-
-// FIXED
-<span>{count()}</span>
-```
-
-## 3. Reading Signals Outside Reactive Context
-
-The component body runs once. Reading a signal at the top level captures the initial value — it never updates.
-
-```typescript
-// BROKEN — layout is assigned once, never reactive
-const MyComponent = (props) => {
-  const layout = props.wide ? "grid" : "list"; // Evaluated once
-  return <div class={layout}>...</div>;
-};
-
-// FIXED — read in JSX (reactive context)
-const MyComponent = (props) => {
-  return <div class={props.wide ? "grid" : "list"}>...</div>;
-};
-
-// Also fixed — wrap in a function
-const MyComponent = (props) => {
-  const layout = () => props.wide ? "grid" : "list";
-  return <div class={layout()}>...</div>;
-};
-```
-
-## 4. Using Effects to Sync State
-
-Effects that set state from other state create ordering problems and glitchy intermediate renders.
-
-```typescript
-// BROKEN — effect-based synchronization
-const [count, setCount] = createSignal(0);
-const [doubled, setDoubled] = createSignal(0);
-createEffect(() => setDoubled(count() * 2));
-
-// FIXED — derivation
-const doubled = createMemo(() => count() * 2);
-// or: const doubled = () => count() * 2;
-```
-
-**Rule:** If a value can be computed from reactive sources, derive it.
-
-## 5. Using Effects for Data Fetching
-
-Effects run after render, have no built-in loading/error states, and create race conditions on dependency changes.
-
-```typescript
-// BROKEN
-createEffect(async () => {
-  const res = await fetch(`/api/${id()}`);
-  setData(await res.json());
-});
-
-// FIXED
-const [data] = createResource(id, fetchData);
-```
-
-`createResource` integrates with Suspense, handles loading/error, and manages race conditions.
-
-## 6. Using `.map()` Instead of `<For>`
-
-JavaScript `.map()` recreates all DOM nodes whenever the array signal changes. `<For>` tracks items by reference and only updates what changed.
-
-```typescript
-// INEFFICIENT — full DOM rebuild on any array change
-<ul>{items().map(item => <li>{item.name}</li>)}</ul>
-
-// CORRECT — granular updates
-<ul><For each={items()}>{(item) => <li>{item.name}</li>}</For></ul>
-```
-
-## 7. Using `&&` for Conditional Rendering
-
-JavaScript short-circuit evaluation doesn't give Solid the boundaries it needs to optimize.
-
-```typescript
-// SUBOPTIMAL — no Solid optimization
-{isVisible() && <Modal />}
-
-// CORRECT — Solid can optimize the boundary
-<Show when={isVisible()}><Modal /></Show>
-```
-
-## 8. Mutating Store State Directly
-
-Stores use proxies. Direct mutation bypasses the reactive system.
-
-```typescript
-// BROKEN — Solid doesn't see this change
-state.tasks[0].completed = true;
-
-// FIXED — go through setState
-setState("tasks", 0, "completed", true);
-```
-
-## 9. Creating Unnecessary Reactivity
-
-Not everything needs to be a signal. Static configuration, constants, and values that never change don't benefit from reactivity.
-
-```typescript
-// UNNECESSARY
-const [apiUrl] = createSignal("https://api.example.com");
-
-// JUST USE A CONSTANT
-const API_URL = "https://api.example.com";
-```
-
-## 10. Missing `onCleanup`
-
-Effects that create subscriptions, timers, or event listeners without cleanup cause memory leaks.
-
-```typescript
-// LEAKS — interval is never cleared
-createEffect(() => {
-  setInterval(() => tick(), 1000);
-});
-
-// FIXED
-createEffect(() => {
-  const id = setInterval(() => tick(), 1000);
-  onCleanup(() => clearInterval(id));
-});
-```
-
-## Quick Reference
-
-| Mistake | Fix |
-|---|---|
-| Destructure props | Use `props.x` directly |
-| `count` without `()` | Always call signal getters |
-| Signal read at top level | Read in JSX or wrap in `() =>` |
-| Effect sets state from state | Use `createMemo` |
-| Effect fetches data | Use `createResource` |
-| `.map()` for lists | Use `<For>` |
-| `&&` for conditionals | Use `<Show>` |
-| Direct store mutation | Use `setState()` |
-| Signal for constants | Use a plain variable |
-| No `onCleanup` | Always clean up side effects |

package/docs/best-practices/solidjs/component-patterns.md

@@ -1,131 +0,0 @@
-# Component Patterns
-
-> Sources: [TypeScript](https://docs.solidjs.com/configuration/typescript), [Props](https://docs.solidjs.com/concepts/components/props) — SolidJS Docs
-
-## Component Type Hierarchy
-
-SolidJS provides four component types for TypeScript:
-
-```typescript
-import type { Component, ParentComponent, FlowComponent, VoidComponent } from "solid-js";
-```
-
-| Type | Children | Use Case |
-|---|---|---|
-| `Component<P>` | No opinion | Base type, generic components |
-| `ParentComponent<P>` | Optional `JSX.Element` | Components that accept children |
-| `FlowComponent<P, C>` | Required, typed | Control flow (`Show`, `For`-like) |
-| `VoidComponent<P>` | Forbidden | Leaf components (icons, inputs) |
-
-```typescript
-const Card: ParentComponent<{ title: string }> = (props) => {
-  return (
-    <div class="card">
-      <h2>{props.title}</h2>
-      {props.children}
-    </div>
-  );
-};
-
-const Icon: VoidComponent<{ name: string }> = (props) => {
-  return <svg class={`icon-${props.name}`} />;
-};
-```
-
-## Generic Components
-
-The `Component` types cannot be used for generic components. Use function declarations instead:
-
-```typescript
-function List<T>(props: { items: T[]; render: (item: T) => JSX.Element }): JSX.Element {
-  return <For each={props.items}>{props.render}</For>;
-}
-
-// Usage — T is inferred
-<List items={users()} render={(user) => <span>{user.name}</span>} />
-```
-
-## Refs
-
-Refs may be `undefined` before mount. Always account for this:
-
-```typescript
-const MyComponent: VoidComponent = () => {
-  let inputRef: HTMLInputElement | undefined;
-
-  onMount(() => {
-    inputRef?.focus(); // Safe access after mount
-  });
-
-  return <input ref={inputRef} />;
-};
-```
-
-Alternatively, use the definite assignment assertion in JSX: `ref={inputRef!}`.
-
-## Composition Over Inheritance
-
-Solid components are plain functions — compose them by passing components as props or using children:
-
-```typescript
-const Layout: ParentComponent<{ sidebar: JSX.Element }> = (props) => {
-  return (
-    <div class="layout">
-      <aside>{props.sidebar}</aside>
-      <main>{props.children}</main>
-    </div>
-  );
-};
-
-<Layout sidebar={<Navigation />}>
-  <PageContent />
-</Layout>
-```
-
-## Event Handling
-
-Inline event handlers get automatic type inference. For extracted handlers, use `JSX.EventHandler`:
-
-```typescript
-const onInput: JSX.EventHandler<HTMLInputElement, InputEvent> = (event) => {
-  // event.currentTarget is HTMLInputElement
-  // event.target may be any element within
-  console.log(event.currentTarget.value);
-};
-```
-
-### Custom Events
-
-Extend the JSX namespace:
-
-```typescript
-declare module "solid-js" {
-  namespace JSX {
-    interface CustomEvents {
-      customClick: CustomEvent<{ id: string }>;
-    }
-  }
-}
-```
-
-## Custom Directives
-
-Register with `use:` prefix. Declare via the JSX namespace:
-
-```typescript
-declare module "solid-js" {
-  namespace JSX {
-    interface Directives {
-      tooltip: string;
-    }
-  }
-}
-
-function tooltip(el: HTMLElement, accessor: () => string) {
-  // Set up tooltip on el using accessor()
-  onCleanup(() => { /* teardown */ });
-}
-
-// Usage
-<div use:tooltip={"Hello!"} />
-```