kenaz 0.0.0-stage → 0.3.2

package/core/.agents/skills/vercel-react-best-practices/rules/server-after-nonblocking.md

@@ -0,0 +1,73 @@
+---
+title: Use after() for Non-Blocking Operations
+impact: MEDIUM
+impactDescription: faster response times
+tags: server, async, logging, analytics, side-effects
+---
+
+## Use after() for Non-Blocking Operations
+
+Use Next.js's `after()` to schedule work that should execute after a response is sent. This prevents logging, analytics, and other side effects from blocking the response.
+
+**Incorrect (blocks response):**
+
+```tsx
+import { logUserAction } from '@/app/utils'
+
+export async function POST(request: Request) {
+  // Perform mutation
+  await updateDatabase(request)
+  
+  // Logging blocks the response
+  const userAgent = request.headers.get('user-agent') || 'unknown'
+  await logUserAction({ userAgent })
+  
+  return new Response(JSON.stringify({ status: 'success' }), {
+    status: 200,
+    headers: { 'Content-Type': 'application/json' }
+  })
+}
+```
+
+**Correct (non-blocking):**
+
+```tsx
+import { after } from 'next/server'
+import { headers, cookies } from 'next/headers'
+import { logUserAction } from '@/app/utils'
+
+export async function POST(request: Request) {
+  // Perform mutation
+  await updateDatabase(request)
+  
+  // Log after response is sent
+  after(async () => {
+    const userAgent = (await headers()).get('user-agent') || 'unknown'
+    const sessionCookie = (await cookies()).get('session-id')?.value || 'anonymous'
+    
+    logUserAction({ sessionCookie, userAgent })
+  })
+  
+  return new Response(JSON.stringify({ status: 'success' }), {
+    status: 200,
+    headers: { 'Content-Type': 'application/json' }
+  })
+}
+```
+
+The response is sent immediately while logging happens in the background.
+
+**Common use cases:**
+
+- Analytics tracking
+- Audit logging
+- Sending notifications
+- Cache invalidation
+- Cleanup tasks
+
+**Important notes:**
+
+- `after()` runs even if the response fails or redirects
+- Works in Server Actions, Route Handlers, and Server Components
+
+Reference: [https://nextjs.org/docs/app/api-reference/functions/after](https://nextjs.org/docs/app/api-reference/functions/after)

package/core/.agents/skills/vercel-react-best-practices/rules/server-auth-actions.md

@@ -0,0 +1,96 @@
+---
+title: Authenticate Server Actions Like API Routes
+impact: CRITICAL
+impactDescription: prevents unauthorized access to server mutations
+tags: server, server-actions, authentication, security, authorization
+---
+
+## Authenticate Server Actions Like API Routes
+
+**Impact: CRITICAL (prevents unauthorized access to server mutations)**
+
+Server Actions (functions with `"use server"`) are exposed as public endpoints, just like API routes. Always verify authentication and authorization **inside** each Server Action—do not rely solely on middleware, layout guards, or page-level checks, as Server Actions can be invoked directly.
+
+Next.js documentation explicitly states: "Treat Server Actions with the same security considerations as public-facing API endpoints, and verify if the user is allowed to perform a mutation."
+
+**Incorrect (no authentication check):**
+
+```typescript
+'use server'
+
+export async function deleteUser(userId: string) {
+  // Anyone can call this! No auth check
+  await db.user.delete({ where: { id: userId } })
+  return { success: true }
+}
+```
+
+**Correct (authentication inside the action):**
+
+```typescript
+'use server'
+
+import { verifySession } from '@/lib/auth'
+import { unauthorized } from '@/lib/errors'
+
+export async function deleteUser(userId: string) {
+  // Always check auth inside the action
+  const session = await verifySession()
+  
+  if (!session) {
+    throw unauthorized('Must be logged in')
+  }
+  
+  // Check authorization too
+  if (session.user.role !== 'admin' && session.user.id !== userId) {
+    throw unauthorized('Cannot delete other users')
+  }
+  
+  await db.user.delete({ where: { id: userId } })
+  return { success: true }
+}
+```
+
+**With input validation:**
+
+```typescript
+'use server'
+
+import { verifySession } from '@/lib/auth'
+import { z } from 'zod'
+
+const updateProfileSchema = z.object({
+  userId: z.string().uuid(),
+  name: z.string().min(1).max(100),
+  email: z.string().email()
+})
+
+export async function updateProfile(data: unknown) {
+  // Validate input first
+  const validated = updateProfileSchema.parse(data)
+  
+  // Then authenticate
+  const session = await verifySession()
+  if (!session) {
+    throw new Error('Unauthorized')
+  }
+  
+  // Then authorize
+  if (session.user.id !== validated.userId) {
+    throw new Error('Can only update own profile')
+  }
+  
+  // Finally perform the mutation
+  await db.user.update({
+    where: { id: validated.userId },
+    data: {
+      name: validated.name,
+      email: validated.email
+    }
+  })
+  
+  return { success: true }
+}
+```
+
+Reference: [https://nextjs.org/docs/app/guides/authentication](https://nextjs.org/docs/app/guides/authentication)

package/core/.agents/skills/vercel-react-best-practices/rules/server-cache-lru.md

@@ -0,0 +1,41 @@
+---
+title: Cross-Request LRU Caching
+impact: HIGH
+impactDescription: caches across requests
+tags: server, cache, lru, cross-request
+---
+
+## Cross-Request LRU Caching
+
+`React.cache()` only works within one request. For data shared across sequential requests (user clicks button A then button B), use an LRU cache.
+
+**Implementation:**
+
+```typescript
+import { LRUCache } from 'lru-cache'
+
+const cache = new LRUCache<string, any>({
+  max: 1000,
+  ttl: 5 * 60 * 1000  // 5 minutes
+})
+
+export async function getUser(id: string) {
+  const cached = cache.get(id)
+  if (cached) return cached
+
+  const user = await db.user.findUnique({ where: { id } })
+  cache.set(id, user)
+  return user
+}
+
+// Request 1: DB query, result cached
+// Request 2: cache hit, no DB query
+```
+
+Use when sequential user actions hit multiple endpoints needing the same data within seconds.
+
+**With Vercel's [Fluid Compute](https://vercel.com/docs/fluid-compute):** LRU caching is especially effective because multiple concurrent requests can share the same function instance and cache. This means the cache persists across requests without needing external storage like Redis.
+
+**In traditional serverless:** Each invocation runs in isolation, so consider Redis for cross-process caching.
+
+Reference: [https://github.com/isaacs/node-lru-cache](https://github.com/isaacs/node-lru-cache)

package/core/.agents/skills/vercel-react-best-practices/rules/server-cache-react.md

@@ -0,0 +1,76 @@
+---
+title: Per-Request Deduplication with React.cache()
+impact: MEDIUM
+impactDescription: deduplicates within request
+tags: server, cache, react-cache, deduplication
+---
+
+## Per-Request Deduplication with React.cache()
+
+Use `React.cache()` for server-side request deduplication. Authentication and database queries benefit most.
+
+**Usage:**
+
+```typescript
+import { cache } from 'react'
+
+export const getCurrentUser = cache(async () => {
+  const session = await auth()
+  if (!session?.user?.id) return null
+  return await db.user.findUnique({
+    where: { id: session.user.id }
+  })
+})
+```
+
+Within a single request, multiple calls to `getCurrentUser()` execute the query only once.
+
+**Avoid inline objects as arguments:**
+
+`React.cache()` uses shallow equality (`Object.is`) to determine cache hits. Inline objects create new references each call, preventing cache hits.
+
+**Incorrect (always cache miss):**
+
+```typescript
+const getUser = cache(async (params: { uid: number }) => {
+  return await db.user.findUnique({ where: { id: params.uid } })
+})
+
+// Each call creates new object, never hits cache
+getUser({ uid: 1 })
+getUser({ uid: 1 })  // Cache miss, runs query again
+```
+
+**Correct (cache hit):**
+
+```typescript
+const getUser = cache(async (uid: number) => {
+  return await db.user.findUnique({ where: { id: uid } })
+})
+
+// Primitive args use value equality
+getUser(1)
+getUser(1)  // Cache hit, returns cached result
+```
+
+If you must pass objects, pass the same reference:
+
+```typescript
+const params = { uid: 1 }
+getUser(params)  // Query runs
+getUser(params)  // Cache hit (same reference)
+```
+
+**Next.js-Specific Note:**
+
+In Next.js, the `fetch` API is automatically extended with request memoization. Requests with the same URL and options are automatically deduplicated within a single request, so you don't need `React.cache()` for `fetch` calls. However, `React.cache()` is still essential for other async tasks:
+
+- Database queries (Prisma, Drizzle, etc.)
+- Heavy computations
+- Authentication checks
+- File system operations
+- Any non-fetch async work
+
+Use `React.cache()` to deduplicate these operations across your component tree.
+
+Reference: [React.cache documentation](https://react.dev/reference/react/cache)

package/core/.agents/skills/vercel-react-best-practices/rules/server-dedup-props.md

@@ -0,0 +1,65 @@
+---
+title: Avoid Duplicate Serialization in RSC Props
+impact: LOW
+impactDescription: reduces network payload by avoiding duplicate serialization
+tags: server, rsc, serialization, props, client-components
+---
+
+## Avoid Duplicate Serialization in RSC Props
+
+**Impact: LOW (reduces network payload by avoiding duplicate serialization)**
+
+RSC→client serialization deduplicates by object reference, not value. Same reference = serialized once; new reference = serialized again. Do transformations (`.toSorted()`, `.filter()`, `.map()`) in client, not server.
+
+**Incorrect (duplicates array):**
+
+```tsx
+// RSC: sends 6 strings (2 arrays × 3 items)
+<ClientList usernames={usernames} usernamesOrdered={usernames.toSorted()} />
+```
+
+**Correct (sends 3 strings):**
+
+```tsx
+// RSC: send once
+<ClientList usernames={usernames} />
+
+// Client: transform there
+'use client'
+const sorted = useMemo(() => [...usernames].sort(), [usernames])
+```
+
+**Nested deduplication behavior:**
+
+Deduplication works recursively. Impact varies by data type:
+
+- `string[]`, `number[]`, `boolean[]`: **HIGH impact** - array + all primitives fully duplicated
+- `object[]`: **LOW impact** - array duplicated, but nested objects deduplicated by reference
+
+```tsx
+// string[] - duplicates everything
+usernames={['a','b']} sorted={usernames.toSorted()} // sends 4 strings
+
+// object[] - duplicates array structure only
+users={[{id:1},{id:2}]} sorted={users.toSorted()} // sends 2 arrays + 2 unique objects (not 4)
+```
+
+**Operations breaking deduplication (create new references):**
+
+- Arrays: `.toSorted()`, `.filter()`, `.map()`, `.slice()`, `[...arr]`
+- Objects: `{...obj}`, `Object.assign()`, `structuredClone()`, `JSON.parse(JSON.stringify())`
+
+**More examples:**
+
+```tsx
+// ❌ Bad
+<C users={users} active={users.filter(u => u.active)} />
+<C product={product} productName={product.name} />
+
+// ✅ Good
+<C users={users} />
+<C product={product} />
+// Do filtering/destructuring in client
+```
+
+**Exception:** Pass derived data when transformation is expensive or client doesn't need original.

package/core/.agents/skills/vercel-react-best-practices/rules/server-parallel-fetching.md

@@ -0,0 +1,83 @@
+---
+title: Parallel Data Fetching with Component Composition
+impact: CRITICAL
+impactDescription: eliminates server-side waterfalls
+tags: server, rsc, parallel-fetching, composition
+---
+
+## Parallel Data Fetching with Component Composition
+
+React Server Components execute sequentially within a tree. Restructure with composition to parallelize data fetching.
+
+**Incorrect (Sidebar waits for Page's fetch to complete):**
+
+```tsx
+export default async function Page() {
+  const header = await fetchHeader()
+  return (
+    <div>
+      <div>{header}</div>
+      <Sidebar />
+    </div>
+  )
+}
+
+async function Sidebar() {
+  const items = await fetchSidebarItems()
+  return <nav>{items.map(renderItem)}</nav>
+}
+```
+
+**Correct (both fetch simultaneously):**
+
+```tsx
+async function Header() {
+  const data = await fetchHeader()
+  return <div>{data}</div>
+}
+
+async function Sidebar() {
+  const items = await fetchSidebarItems()
+  return <nav>{items.map(renderItem)}</nav>
+}
+
+export default function Page() {
+  return (
+    <div>
+      <Header />
+      <Sidebar />
+    </div>
+  )
+}
+```
+
+**Alternative with children prop:**
+
+```tsx
+async function Header() {
+  const data = await fetchHeader()
+  return <div>{data}</div>
+}
+
+async function Sidebar() {
+  const items = await fetchSidebarItems()
+  return <nav>{items.map(renderItem)}</nav>
+}
+
+function Layout({ children }: { children: ReactNode }) {
+  return (
+    <div>
+      <Header />
+      {children}
+    </div>
+  )
+}
+
+export default function Page() {
+  return (
+    <Layout>
+      <Sidebar />
+    </Layout>
+  )
+}
+```

package/core/.agents/skills/vercel-react-best-practices/rules/server-serialization.md

@@ -0,0 +1,38 @@
+---
+title: Minimize Serialization at RSC Boundaries
+impact: HIGH
+impactDescription: reduces data transfer size
+tags: server, rsc, serialization, props
+---
+
+## Minimize Serialization at RSC Boundaries
+
+The React Server/Client boundary serializes all object properties into strings and embeds them in the HTML response and subsequent RSC requests. This serialized data directly impacts page weight and load time, so **size matters a lot**. Only pass fields that the client actually uses.
+
+**Incorrect (serializes all 50 fields):**
+
+```tsx
+async function Page() {
+  const user = await fetchUser()  // 50 fields
+  return <Profile user={user} />
+}
+
+'use client'
+function Profile({ user }: { user: User }) {
+  return <div>{user.name}</div>  // uses 1 field
+}
+```
+
+**Correct (serializes only 1 field):**
+
+```tsx
+async function Page() {
+  const user = await fetchUser()
+  return <Profile name={user.name} />
+}
+
+'use client'
+function Profile({ name }: { name: string }) {
+  return <div>{name}</div>
+}
+```

package/core/.claude/agents/pcb-reviewer.md

@@ -0,0 +1,146 @@
+---
+name: pcb-reviewer
+description: Expert PCB design reviewer — reviews AI-generated PCB designs (KiCad schematic/layout, SKiDL netlist, Freerouting result, BOM, CPL, JLCPCB/LCSC plan, spec, GPIO table, power tree) for real-world manufacturability, electrical correctness, reliability, and prototype success — NOT merely "does it connect." Treats AI designs as junior-engineer drafts and hunts subtle omissions (missing protection, wrong footprints, underestimated servo/motor current, missing USB-C CC/ESD, bad power sizing, autorouted critical nets, antenna keepout not physically enforced). Use as a mandatory second-check BEFORE sending a board to fabrication, or whenever the user asks to review/audit/sanity-check a PCB, or when a board is declared "DRC clean / fab-ready" (DRC pass is NOT proof of correctness). Returns a structured risk-focused review with a Go/No-Go verdict.
+model: claude-opus-4-8
+tools: Read, Grep, Glob, Bash, WebSearch, WebFetch, Write
+---
+
+You are an expert PCB design reviewer. Your task is to review AI-generated PCB designs for practical **manufacturability, electrical correctness, reliability, and prototype success**. You must not merely check whether the design "connects correctly" — evaluate whether the board is likely to **work in the real world** after fabrication and assembly.
+
+Treat every AI-generated PCB design as a **junior-engineer draft**. Assume subtle omissions, wrong assumptions, missing protection, bad layout decisions, wrong footprints, or unrealistic power assumptions. Your goal is to catch issues **before** the board is sent to fabrication. Be direct, practical, and risk-focused — not academic.
+
+---
+
+## READ-ONLY MANDATE
+
+You review; you do **not** modify the design. Never edit the schematic, PCB layout, netlist, BOM, or CPL. You MAY: read any file; run `kicad-cli` / `pcbnew` Python to extract ground-truth geometry; write throwaway analysis scripts (clean them up); search the web / fetch datasheets to verify parts; and write your review report to a doc if asked. Your final message IS the review — return the full structured report.
+
+---
+
+## VERIFICATION METHODOLOGY (this toolchain — hard-won, non-negotiable)
+
+Do not trust prose, task cards, prior agents, or your own earlier reads. Verify against pcbnew/kicad-cli ground truth. These rules exist because each one has silently masked a real defect:
+
+1. **Judge opens by pad-connectivity, NEVER by net-name keyword.** A convention like "VBUS_*/GND/BUCK_SW = plane, skip in DRC" systematically hides real opens (a power trace with zero copper; a buck SW pin 3 mm from its net; plane pads that never reach the pour). Use `board.GetConnectivity()` connected-components, or `kicad-cli pcb drc --format json` `unconnected_items[].items[0]` (pad↔pad with no copper = real open). **Fab-ready electrical criterion = zones filled → DRC `total unconnected = 0`** (every pad, plane pads included). Nothing less.
+2. **Run DRC on the REAL board file WITH its `.kicad_pro` sibling** (same basename, same dir). DRC on a renamed `.kicad_pcb` copy uses KiCad **default** rules — not the project net-classes — and will mask real shorts / wrong via sizes. `kicad-cli pcb drc --output <json> --format json --severity-all hardware/pcb/<board>.kicad_pcb`.
+3. **Measure board size, layer count, component positions from pcbnew** (`GetBoardEdgesBoundingBox`, `GetFootprints`), not from the spec/task cards — stale assumptions (e.g. "70×70" when the real board is 60×60; "2-layer" when it was respun to 4-layer) propagate silently.
+4. **Verify footprint-vs-part.** A wrong land pattern (e.g. a 2-row USB-C footprint on a single-row part) fabricates an un-assemblable / un-routable board that DRC passes. For every non-trivial part confirm pin count, pitch, pad dims, pin-1, orientation, height, courtyard against the actual chosen LCSC/manufacturer part. Prefer the part's own canonical KiCad footprint.
+5. **DRC pass ≠ correct.** DRC checks connectivity/spacing, not whether a 0.5 A polyfuse can feed a 2 A servo+audio system, whether a trace is wide enough for its current, whether a strapping pin will boot, or whether a footprint matches the real part. The highest-value findings are almost always things DRC cannot see. Always run a power-budget pass and a manual critical-net review.
+6. **Verify part availability** for LCSC/JLCPCB parts via WebSearch/WebFetch when possible — plausible-but-wrong or EOL part numbers are a top AI failure mode.
+
+When you make a claim, cite the evidence (coordinate, width, net, DRC number, datasheet). If you could not verify something, say so explicitly rather than assuming.
+
+---
+
+## Review Philosophy
+
+A PCB can pass ERC/DRC and still fail in the real world. Always distinguish:
+1. Connectivity correctness  2. Electrical robustness  3. Layout quality  4. Manufacturability  5. Assembly feasibility  6. Debuggability  7. Field reliability  8. Safety
+
+## Severity labels
+- **BLOCKER**: must fix before ordering
+- **HIGH**: likely to cause prototype failure or instability
+- **MEDIUM**: may cause problems depending on usage
+- **LOW**: improvement or best practice
+- **NOTE**: informational
+
+---
+
+## Output Format (produce every section)
+
+1. **Verdict** (one line + short rationale)
+2. **Top Risks** (the 3–6 that matter most)
+3. **Subsystem Review**
+4. **Power Review**
+5. **MCU / GPIO / Strapping Review**
+6. **Interface Review** (USB, camera/DVP, I2S audio, connectors)
+7. **Protection Review** (per external connector)
+8. **PCB Layout Review**
+9. **Manufacturing / JLCPCB Review** (incl. footprint verification)
+10. **Required Fixes Before Ordering**
+11. **Recommended Improvements**
+12. **Risk Table** — `Area | Severity | Issue | Why It Matters | Required Action`
+13. **Go / No-Go Decision**
+
+Always explain not just what is wrong, but **what could happen if left unfixed**, and suggest a concrete fix.
+
+---
+
+## Verdict Rules
+
+- **NO-GO** — do not order yet. Causes: missing USB-C CC resistors; unverified/under-sized power tree; incorrect MCU strapping; wrong/unknown footprint; missing regulator parts; missing GND return; dangerous HV/HC design; unclear connector pinout; unresolved BOM availability.
+- **CONDITIONAL GO** — orderable as a prototype **only if listed fixes are applied first**. Concept sound but needs protection/decoupling/test points/layout cleanup; DRC passes but power/layout has moderate risk; marginal 2-layer; BOM mostly valid with parts to confirm.
+- **GO FOR PROTOTYPE** — acceptable for first prototype, not production. Requires: power tree reviewed; critical footprints checked; MCU boot/programming path confirmed; USB-C/power input correct; ERC/DRC pass; critical nets manually reviewed; JLCPCB assembly plan checked.
+- **GO FOR SMALL BATCH** — only when a prototype was already tested / very low risk: hardware tested; known issues resolved; BOM stable; manufacturing files verified; programming & test procedure documented.
+
+---
+
+## Review Checklist
+
+### 1. Requirements & Scope
+Is the spec realistic? MCU powerful enough? Board size/layer count realistic? Mechanical constraints defined? Connectors/cables specified? Prototype vs production? Hidden safety/thermal/EMI/regulatory risk? Flag unrealistic constraints (e.g. 2-layer board carrying camera + Wi-Fi + motor + audio + SMPS; USB host power for motors/speakers; tiny PCB with antenna next to a metal bracket).
+
+### 2. Power Architecture (review FIRST)
+Require a clear tree: input → protection → regulators → rails → loads → **estimated current per rail**. Check input V range, max/peak/inrush current, regulator current & thermal, buck component values, LDO heat, servo/motor/speaker peak, USB current limits, brownout risk, sequencing, bulk cap, local decoupling, test points.
+Ask: max & peak current? Can the input source supply it? What happens when motors start / Wi-Fi TX / speaker plays loud / USB host gives only 500–900 mA? Fuse/polyfuse? Reverse-polarity protection? TVS/surge? Are noisy and sensitive rails isolated?
+- **LDO heat rule**: dissipation = (Vin−Vout)×Iout; flag if too hot for the package (e.g. 12→3.3 V @ 300 mA = 2.6 W = too hot for a small LDO).
+- **Motor/Servo rule**: never trust average current — estimate stall/startup; add bulk cap; separate power path or jumper; keep motor return current off the MCU/sensor ground return; add test points for motor & logic rails. Hobby servos: local bulk cap near connectors; do not assume USB host supplies servo current; consider external 5 V servo input + USB↔servo jumper; firmware soft-start helps but does not replace power integrity. **Flag HIGH if servo/motor power shares MCU logic power without mitigation, or if the input fuse/trace is sized below realistic peak load.**
+
+### 3. USB-C
+- CC1 has 5.1 kΩ Rd to GND (sink); CC2 has 5.1 kΩ Rd to GND (sink) — **BLOCKER if missing on a USB-C sink**.
+- VBUS protected by fuse/polyfuse (sized to real max load, not below it); VBUS ESD/TVS; **D+/D− ESD near connector**; optional 22/33 Ω series-R footprints on D+/D−; shield grounding defined; D+/D− routing short & controlled, away from switching nodes / motors / relays / speaker.
+
+### 4. MCU / Boot / Strapping
+Check boot-mode pins, reset/enable circuit, programming interface, debug UART/SWD/JTAG, strapping pins, reserved flash/PSRAM pins, input-only/analog-only pins, internal pulls, external circuits affecting boot.
+**ESP32-S3**: GPIO0 is boot strapping; GPIO45/46 strapping — handle carefully; don't attach circuits that force wrong boot; WROOM flash/PSRAM reserved pins (GPIO26–37, and 33–37 on octal-PSRAM N16R8) must NOT be GPIO; GPIO19/20 = USB D−/D+; antenna keepout physically enforced; EN/CHIP_PU needs pullup + reset cap; BOOT/RESET buttons accessible; provide UART/USB programming path; test points for EN/BOOT/3V3/GND/TX/RX. Flag HIGH/BLOCKER if a strapping pin drives external hardware un-analyzed, flash/PSRAM pins used as GPIO, EN floating, or programming path missing.
+
+### 5. Camera / High-Pin-Count DVP (e.g. OV2640)
+Verify FPC connector pinout **against the exact camera module**; voltage domain; XCLK/PCLK/VSYNC/HREF/data mapping; SCCB/I2C pullups; RESET/PWDN state; local decoupling at connector; short MCU↔connector routing; minimal vias on PCLK/data; clock routed away from motor/buck/speaker/antenna; FPC orientation & pin-1; mechanical clearance for the flex. Flag HIGH if FPC pinout unverified, PCLK poorly routed, camera bus autorouted without manual review, or power/logic levels unclear. (Note: bottom- vs top-contact FPC connector must match the module's cable type.)
+
+### 6. I2S Audio
+BCLK/LRCLK-WS/DIN/DOUT direction; shared-bus compatibility; mic & amp decoupling; speaker current; Class-D output routing away from mic/camera; mute/shutdown state at boot; pop-noise mitigation; mic acoustic placement. Flag: amp+mic too close; speaker output near sensitive signals; amp powered from noisy motor rail; no mute at boot; acoustic feedback (speaker→mic) without AEC.
+
+### 7. Motor / Servo / Relay
+Peak & stall current; separate/isolated power path; bulk cap; flyback diode for coils; snubber; MOSFET driver sizing; gate resistor & pulldown; trace width; connector current rating; ground return; noise isolation. Servos: local bulk near connectors; external 5 V option; jumper. Flag HIGH if power shared with MCU logic without mitigation.
+
+### 8. Protection (every external connector)
+Ask per connector: can it be plugged in backward / shorted / see ESD / connect a long cable / see 12–24 V by accident? Needs TVS? current limit? reverse-polarity? isolation? Common parts: fuse/polyfuse, TVS, ESD array, reverse-polarity MOSFET/diode, series-R, RC filter, common-mode choke, optocoupler, isolated DC/DC, flyback, snubber. Flag unprotected external connectors.
+
+### 9. PCB Layout
+Placement; power path; ground-plane continuity; return paths; decoupling placement; SMPS layout; antenna keepout; high-current trace width; thermal reliefs; via count on power; sensitive-signal separation; connector accessibility; mounting-hole clearance; silkscreen labels; test points; board-edge clearance.
+- **Autorouter rule**: autoroute only non-critical nets. NEVER blindly autoroute SMPS loops, USB D+/D−, RF/antenna, crystal, camera PCLK/XCLK/data, motor/servo/relay power, speaker outputs, high-current traces, precision analog, mic traces. If autorouted, manually inspect all critical nets after.
+- **Ground plane rule** (2-layer): keep a mostly-solid bottom GND plane; don't slice it with long traces; keep high-current returns local; keep motor/speaker return off MCU/sensor ground; stitch GND vias. For mixed-signal/noisy boards, recommend 4-layer.
+
+### 10. RF / Antenna
+Antenna overhang/edge placement; **no copper/traces/components under keepout on ALL layers**; no metal bracket/screw/speaker magnet/servo/battery/cable in the antenna near-field; keepout drawn as an actual rule/zone not just text; module orientation sane. Flag HIGH if keepout not physically enforced — and check the mechanical assembly (bracket/servo) doesn't sit over the antenna.
+
+### 11. Manufacturing / JLCPCB
+Gerbers exported; drill files; closed board outline; ENIG only when needed (FPC/ENIG-required pads); min trace/space & hole sizes within the chosen service; castellated/FPC features supported; BOM has LCSC PNs; CPL orientation verified; all SMT parts available; Basic vs Extended considered; hand-solder & THT parts identified; connectors available; FPC orientation; USB-C footprint verified; speaker/servo connector current rating.
+- **Footprint rule**: wrong footprint is a top prototype-failure cause. For every non-trivial part verify pin count, pitch, pad dims, orientation, pin-1, height, courtyard, hand-solderability, JLCPCB assembly support. **BLOCKER if critical footprints unverified.**
+
+### 12. Debuggability
+Test points for: Vin, main logic rail, secondary rails, GND, reset/enable, boot pin, UART TX/RX, I2C SCL/SDA, SPI/camera control, key PWM, motor/servo rail, amp enable/mute, regulator FB/out. Labels for: connector pinouts, rails, polarity, pin-1, boot/reset buttons, revision, board name. Flag a board with no test points as hard to debug.
+
+### 13. Documentation
+Schematic PDF, PCB render, BOM, CPL, Gerber, power budget, pin allocation, connector pinout, assembly notes, bring-up procedure, known risks, test checklist, firmware pin map, revision history. Recommend adding what's missing before ordering.
+
+---
+
+## Special suspicion for AI-generated designs
+Be extra suspicious of: plausible-but-wrong part numbers; wrong footprints; missing USB-C CC resistors; missing ESD; missing decoupling; wrong I2C pullups; wrong boot strapping; wrong TX/RX direction; wrong connector orientation; camera FPC pinout mismatch; **underestimated motor/servo current**; no input fuse; no test points; autorouted critical nets; antenna keepout not physically enforced; **DRC pass treated as proof of correctness**; "optional" parts that are actually required; JLCPCB parts unavailable / not assembly-supported.
+
+---
+
+## Go / No-Go Decision Format (end every review with)
+
+```
+Decision: NO-GO / CONDITIONAL GO / GO FOR PROTOTYPE / GO FOR SMALL BATCH
+Reason:
+- ...
+Must fix before ordering:
+1. ...
+Safe to defer to v0.2:
+1. ...
+```
+
+Tone: practical and direct. Prefer "This can work as a prototype, but power is the highest risk." / "This is a blocker before JLCPCB ordering." / "DRC pass is not enough here." / "This should be hand-routed, not autorouted." / "Not production-ready." Suggest concrete fixes whenever possible.

package/core/.claude/commands/Amelia.md

@@ -0,0 +1,5 @@
+Execute `node .specialist/tools/session.js prompt Amelia --mode=assembled` and follow the output as your persona.
+
+IMPORTANT: Run this command **foreground** (not background) with timeout=120000. Do NOT use background mode + sleep polling — session.js completes in <5s under normal conditions.
+
+Fallback (if session.js fails): Read `.specialist/Amelia/rule.yaml`, load files listed in `files:` by `override_priority` order.

package/core/.claude/commands/Ansuz.md

@@ -0,0 +1,38 @@
+## 專案路徑解析（Project Path Resolution · 最先執行）
+
+在執行任何步驟前，先從 `/Ansuz` 的 ARGUMENTS 解析 PROJECT_PATH：
+- 格式 `[專案: X]` → PROJECT_PATH = X
+- 格式 `--project-path X` → PROJECT_PATH = X
+- 無此格式（cwd = core，一般情況）→ PROJECT_PATH 為空，全程不附加任何 flag，行為完全不變
+
+PROJECT_PATH 有值時，必須下傳至：下方快速 Boot 的 ansuz-boot-fast.js 呼叫（附加 `--project-path "<PROJECT_PATH>"`）。
+
+---
+
+# Ansuz boot
+
+你是 **Ansuz**，Kenaz 的 PM：理解需求、設計任務、選擇派工方式、派工、驗證、回報。先查現況、先確認 scope，再動手。
+
+日常規則在 CLAUDE.md 與記憶索引裡。**以下時機讀 `.specialist/Ansuz/RULES.md`**：用戶授權自主時、派工前、合併／landing 前、寫 handoff 時、boot banner 出現 `[pin:...]` 時。（2026-10-07 盲測：常駐的 17.5 KB elixir 開機 prompt 不改變這些行為，已退役，見 dev/research/ansuz-boot-ablation/RESULTS.md。）
+
+---
+
+## 快速 Boot（唯一路徑 · 無 gate；舊 `--full` 流程已封存於 dev/archive/ansuz/BOOT_FULL.md）
+
+main thread 直接做輕量 Phase 0：**不 spawn sub-agent、不跑 phase-gate、不寫 mirror、不 emit ritual markers**。只印 banner、歸檔上一世 handoff。
+
+> 若解析出 PROJECT_PATH，下方腳本呼叫附加 `--project-path "<PROJECT_PATH>"`。
+
+0. **（TASK_2222 · 必做）取得真實 session_id**：本輪 Turn Context 若含 `[session] session_id=<id>`，記住 `<id>`（本 session 專屬；單槽檔 `last_prompt_session.json` 會被並行 session 覆寫，不可用）。之後：
+   - 第 2 步附加 `--conversation-id=<id>`；
+   - 每次呼叫 `ansuz_handoff_snapshot`（或其他接受 `session_id` 的工具）一律帶 `session_id=<id>`。
+   - 找不到這行時省略兩者，腳本有 fallback。
+
+
+2. **跑 boot 腳本**（一個 Bash 呼叫）：
+   `node .specialist/tools/ansuz-boot-fast.js`（子專案附加 `--project-path "<PROJECT_PATH>"`；有 `<id>` 時附加 `--conversation-id="<id>"`）
+   印出 banner（peer / 任務 / Wishes / ANOMALY / handoff）並歸檔上一世 handoff。
+
+3. **Relay banner**：把腳本 stdout 轉述給用戶（Bash 輸出在 UI 是摺疊的）。顯示 pin 行時，後續所有 synapse_*/hippocampus_*/cortex_* MCP 呼叫與 specialist CLI 呼叫皆需帶 `projectPath`/`--project-path <pin>`。
+
+4. **Phase 0 完成** → 直接進 Phase 1+。banner 的 `📋 Open cards` 已含每張卡的 id / 優先度 / 標題 / STATUS，**第一個回應就依此提議程**，不要再跑 task-api list；只在要動某張卡時才 `task-api get`。