compact-agent 1.10.0 → 1.11.0

package/resources/ecc/rules/{swift-security.md → swift/security.md}

@@ -1,17 +1,17 @@
 ---
-description: "Swift security extending common rules"
-globs: ["**/*.swift", "**/Package.swift"]
-alwaysApply: false
+paths:
+  - "**/*.swift"
+  - "**/Package.swift"
 ---
 # Swift Security
 
-> This file extends the common security rule with Swift specific content.
+> This file extends [common/security.md](../common/security.md) with Swift specific content.
 
 ## Secret Management
 
-- Use **Keychain Services** for sensitive data (tokens, passwords, keys) -- never `UserDefaults`
+- Use **Keychain Services** for sensitive data (tokens, passwords, keys) — never `UserDefaults`
 - Use environment variables or `.xcconfig` files for build-time secrets
-- Never hardcode secrets in source -- decompilation tools extract them trivially
+- Never hardcode secrets in source — decompilation tools extract them trivially
 
 ```swift
 let apiKey = ProcessInfo.processInfo.environment["API_KEY"]
@@ -22,7 +22,7 @@ guard let apiKey, !apiKey.isEmpty else {
 
 ## Transport Security
 
-- App Transport Security (ATS) is enforced by default -- do not disable it
+- App Transport Security (ATS) is enforced by default — do not disable it
 - Use certificate pinning for critical endpoints
 - Validate all server certificates
 

package/resources/ecc/rules/{swift-testing.md → swift/testing.md}

@@ -1,11 +1,11 @@
 ---
-description: "Swift testing extending common rules"
-globs: ["**/*.swift", "**/Package.swift"]
-alwaysApply: false
+paths:
+  - "**/*.swift"
+  - "**/Package.swift"
 ---
 # Swift Testing
 
-> This file extends the common testing rule with Swift specific content.
+> This file extends [common/testing.md](../common/testing.md) with Swift specific content.
 
 ## Framework
 
@@ -22,7 +22,7 @@ func userCreationValidatesEmail() throws {
 
 ## Test Isolation
 
-Each test gets a fresh instance -- set up in `init`, tear down in `deinit`. No shared mutable state between tests.
+Each test gets a fresh instance — set up in `init`, tear down in `deinit`. No shared mutable state between tests.
 
 ## Parameterized Tests
 

package/resources/ecc/rules/typescript/coding-style.md

@@ -0,0 +1,199 @@
+---
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.js"
+  - "**/*.jsx"
+---
+# TypeScript/JavaScript Coding Style
+
+> This file extends [common/coding-style.md](../common/coding-style.md) with TypeScript/JavaScript specific content.
+
+## Types and Interfaces
+
+Use types to make public APIs, shared models, and component props explicit, readable, and reusable.
+
+### Public APIs
+
+- Add parameter and return types to exported functions, shared utilities, and public class methods
+- Let TypeScript infer obvious local variable types
+- Extract repeated inline object shapes into named types or interfaces
+
+```typescript
+// WRONG: Exported function without explicit types
+export function formatUser(user) {
+  return `${user.firstName} ${user.lastName}`
+}
+
+// CORRECT: Explicit types on public APIs
+interface User {
+  firstName: string
+  lastName: string
+}
+
+export function formatUser(user: User): string {
+  return `${user.firstName} ${user.lastName}`
+}
+```
+
+### Interfaces vs. Type Aliases
+
+- Use `interface` for object shapes that may be extended or implemented
+- Use `type` for unions, intersections, tuples, mapped types, and utility types
+- Prefer string literal unions over `enum` unless an `enum` is required for interoperability
+
+```typescript
+interface User {
+  id: string
+  email: string
+}
+
+type UserRole = 'admin' | 'member'
+type UserWithRole = User & {
+  role: UserRole
+}
+```
+
+### Avoid `any`
+
+- Avoid `any` in application code
+- Use `unknown` for external or untrusted input, then narrow it safely
+- Use generics when a value's type depends on the caller
+
+```typescript
+// WRONG: any removes type safety
+function getErrorMessage(error: any) {
+  return error.message
+}
+
+// CORRECT: unknown forces safe narrowing
+function getErrorMessage(error: unknown): string {
+  if (error instanceof Error) {
+    return error.message
+  }
+
+  return 'Unexpected error'
+}
+```
+
+### React Props
+
+- Define component props with a named `interface` or `type`
+- Type callback props explicitly
+- Do not use `React.FC` unless there is a specific reason to do so
+
+```typescript
+interface User {
+  id: string
+  email: string
+}
+
+interface UserCardProps {
+  user: User
+  onSelect: (id: string) => void
+}
+
+function UserCard({ user, onSelect }: UserCardProps) {
+  return <button onClick={() => onSelect(user.id)}>{user.email}</button>
+}
+```
+
+### JavaScript Files
+
+- In `.js` and `.jsx` files, use JSDoc when types improve clarity and a TypeScript migration is not practical
+- Keep JSDoc aligned with runtime behavior
+
+```javascript
+/**
+ * @param {{ firstName: string, lastName: string }} user
+ * @returns {string}
+ */
+export function formatUser(user) {
+  return `${user.firstName} ${user.lastName}`
+}
+```
+
+## Immutability
+
+Use spread operator for immutable updates:
+
+```typescript
+interface User {
+  id: string
+  name: string
+}
+
+// WRONG: Mutation
+function updateUser(user: User, name: string): User {
+  user.name = name // MUTATION!
+  return user
+}
+
+// CORRECT: Immutability
+function updateUser(user: Readonly<User>, name: string): User {
+  return {
+    ...user,
+    name
+  }
+}
+```
+
+## Error Handling
+
+Use async/await with try-catch and narrow unknown errors safely:
+
+```typescript
+interface User {
+  id: string
+  email: string
+}
+
+declare function riskyOperation(userId: string): Promise<User>
+
+function getErrorMessage(error: unknown): string {
+  if (error instanceof Error) {
+    return error.message
+  }
+
+  return 'Unexpected error'
+}
+
+const logger = {
+  error: (message: string, error: unknown) => {
+    // Replace with your production logger (for example, pino or winston).
+  }
+}
+
+async function loadUser(userId: string): Promise<User> {
+  try {
+    const result = await riskyOperation(userId)
+    return result
+  } catch (error: unknown) {
+    logger.error('Operation failed', error)
+    throw new Error(getErrorMessage(error))
+  }
+}
+```
+
+## Input Validation
+
+Use Zod for schema-based validation and infer types from the schema:
+
+```typescript
+import { z } from 'zod'
+
+const userSchema = z.object({
+  email: z.string().email(),
+  age: z.number().int().min(0).max(150)
+})
+
+type UserInput = z.infer<typeof userSchema>
+
+const validated: UserInput = userSchema.parse(input)
+```
+
+## Console.log
+
+- No `console.log` statements in production code
+- Use proper logging libraries instead
+- See hooks for automatic detection

package/resources/ecc/rules/{typescript-hooks.md → typescript/hooks.md}

@@ -1,11 +1,13 @@
 ---
-description: "TypeScript hooks extending common rules"
-globs: ["**/*.ts", "**/*.tsx", "**/*.js", "**/*.jsx"]
-alwaysApply: false
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.js"
+  - "**/*.jsx"
 ---
 # TypeScript/JavaScript Hooks
 
-> This file extends the common hooks rule with TypeScript/JavaScript specific content.
+> This file extends [common/hooks.md](../common/hooks.md) with TypeScript/JavaScript specific content.
 
 ## PostToolUse Hooks
 

package/resources/ecc/rules/{typescript-patterns.md → typescript/patterns.md}

@@ -1,11 +1,13 @@
 ---
-description: "TypeScript patterns extending common rules"
-globs: ["**/*.ts", "**/*.tsx", "**/*.js", "**/*.jsx"]
-alwaysApply: false
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.js"
+  - "**/*.jsx"
 ---
 # TypeScript/JavaScript Patterns
 
-> This file extends the common patterns rule with TypeScript/JavaScript specific content.
+> This file extends [common/patterns.md](../common/patterns.md) with TypeScript/JavaScript specific content.
 
 ## API Response Format
 

package/resources/ecc/rules/{typescript-security.md → typescript/security.md}

@@ -1,11 +1,13 @@
 ---
-description: "TypeScript security extending common rules"
-globs: ["**/*.ts", "**/*.tsx", "**/*.js", "**/*.jsx"]
-alwaysApply: false
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.js"
+  - "**/*.jsx"
 ---
 # TypeScript/JavaScript Security
 
-> This file extends the common security rule with TypeScript/JavaScript specific content.
+> This file extends [common/security.md](../common/security.md) with TypeScript/JavaScript specific content.
 
 ## Secret Management
 

package/resources/ecc/rules/typescript/testing.md

@@ -0,0 +1,18 @@
+---
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.js"
+  - "**/*.jsx"
+---
+# TypeScript/JavaScript Testing
+
+> This file extends [common/testing.md](../common/testing.md) with TypeScript/JavaScript specific content.
+
+## E2E Testing
+
+Use **Playwright** as the E2E testing framework for critical user flows.
+
+## Agent Support
+
+- **e2e-runner** - Playwright E2E testing specialist

package/resources/ecc/rules/web/coding-style.md

@@ -0,0 +1,96 @@
+> This file extends [common/coding-style.md](../common/coding-style.md) with web-specific frontend content.
+
+# Web Coding Style
+
+## File Organization
+
+Organize by feature or surface area, not by file type:
+
+```text
+src/
+├── components/
+│   ├── hero/
+│   │   ├── Hero.tsx
+│   │   ├── HeroVisual.tsx
+│   │   └── hero.css
+│   ├── scrolly-section/
+│   │   ├── ScrollySection.tsx
+│   │   ├── StickyVisual.tsx
+│   │   └── scrolly.css
+│   └── ui/
+│       ├── Button.tsx
+│       ├── SurfaceCard.tsx
+│       └── AnimatedText.tsx
+├── hooks/
+│   ├── useReducedMotion.ts
+│   └── useScrollProgress.ts
+├── lib/
+│   ├── animation.ts
+│   └── color.ts
+└── styles/
+    ├── tokens.css
+    ├── typography.css
+    └── global.css
+```
+
+## CSS Custom Properties
+
+Define design tokens as variables. Do not hardcode palette, typography, or spacing repeatedly:
+
+```css
+:root {
+  --color-surface: oklch(98% 0 0);
+  --color-text: oklch(18% 0 0);
+  --color-accent: oklch(68% 0.21 250);
+
+  --text-base: clamp(1rem, 0.92rem + 0.4vw, 1.125rem);
+  --text-hero: clamp(3rem, 1rem + 7vw, 8rem);
+
+  --space-section: clamp(4rem, 3rem + 5vw, 10rem);
+
+  --duration-fast: 150ms;
+  --duration-normal: 300ms;
+  --ease-out-expo: cubic-bezier(0.16, 1, 0.3, 1);
+}
+```
+
+## Animation-Only Properties
+
+Prefer compositor-friendly motion:
+- `transform`
+- `opacity`
+- `clip-path`
+- `filter` (sparingly)
+
+Avoid animating layout-bound properties:
+- `width`
+- `height`
+- `top`
+- `left`
+- `margin`
+- `padding`
+- `border`
+- `font-size`
+
+## Semantic HTML First
+
+```html
+<header>
+  <nav aria-label="Main navigation">...</nav>
+</header>
+<main>
+  <section aria-labelledby="hero-heading">
+    <h1 id="hero-heading">...</h1>
+  </section>
+</main>
+<footer>...</footer>
+```
+
+Do not reach for generic wrapper `div` stacks when a semantic element exists.
+
+## Naming
+
+- Components: PascalCase (`ScrollySection`, `SurfaceCard`)
+- Hooks: `use` prefix (`useReducedMotion`)
+- CSS classes: kebab-case or utility classes
+- Animation timelines: camelCase with intent (`heroRevealTl`)

package/resources/ecc/rules/web/design-quality.md

@@ -0,0 +1,63 @@
+> This file extends [common/patterns.md](../common/patterns.md) with web-specific design-quality guidance.
+
+# Web Design Quality Standards
+
+## Anti-Template Policy
+
+Do not ship generic template-looking UI. Frontend output should look intentional, opinionated, and specific to the product.
+
+### Banned Patterns
+
+- Default card grids with uniform spacing and no hierarchy
+- Stock hero section with centered headline, gradient blob, and generic CTA
+- Unmodified library defaults passed off as finished design
+- Flat layouts with no layering, depth, or motion
+- Uniform radius, spacing, and shadows across every component
+- Safe gray-on-white styling with one decorative accent color
+- Dashboard-by-numbers layouts with sidebar + cards + charts and no point of view
+- Default font stacks used without a deliberate reason
+
+### Required Qualities
+
+Every meaningful frontend surface should demonstrate at least four of these:
+
+1. Clear hierarchy through scale contrast
+2. Intentional rhythm in spacing, not uniform padding everywhere
+3. Depth or layering through overlap, shadows, surfaces, or motion
+4. Typography with character and a real pairing strategy
+5. Color used semantically, not just decoratively
+6. Hover, focus, and active states that feel designed
+7. Grid-breaking editorial or bento composition where appropriate
+8. Texture, grain, or atmosphere when it fits the visual direction
+9. Motion that clarifies flow instead of distracting from it
+10. Data visualization treated as part of the design system, not an afterthought
+
+## Before Writing Frontend Code
+
+1. Pick a specific style direction. Avoid vague defaults like "clean minimal".
+2. Define a palette intentionally.
+3. Choose typography deliberately.
+4. Gather at least a small set of real references.
+5. Use ECC design/frontend skills where relevant.
+
+## Worthwhile Style Directions
+
+- Editorial / magazine
+- Neo-brutalism
+- Glassmorphism with real depth
+- Dark luxury or light luxury with disciplined contrast
+- Bento layouts
+- Scrollytelling
+- 3D integration
+- Swiss / International
+- Retro-futurism
+
+Do not default to dark mode automatically. Choose the visual direction the product actually wants.
+
+## Component Checklist
+
+- [ ] Does it avoid looking like a default Tailwind or shadcn template?
+- [ ] Does it have intentional hover/focus/active states?
+- [ ] Does it use hierarchy rather than uniform emphasis?
+- [ ] Would this look believable in a real product screenshot?
+- [ ] If it supports both themes, do both light and dark feel intentional?

package/resources/ecc/rules/web/hooks.md

@@ -0,0 +1,129 @@
+> This file extends [common/hooks.md](../common/hooks.md) with web-specific hook recommendations.
+
+# Web Hooks
+
+## Recommended PostToolUse Hooks
+
+Prefer project-local tooling. Do not wire hooks to remote one-off package execution.
+
+### Format on Save
+
+Use the project's existing formatter entrypoint after edits:
+
+```json
+{
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Write|Edit",
+        "command": "pnpm prettier --write \"$FILE_PATH\"",
+        "description": "Format edited frontend files"
+      }
+    ]
+  }
+}
+```
+
+Equivalent local commands via `yarn prettier` or `npm exec prettier --` are fine when they use repo-owned dependencies.
+
+### Lint Check
+
+```json
+{
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Write|Edit",
+        "command": "pnpm eslint --fix \"$FILE_PATH\"",
+        "description": "Run ESLint on edited frontend files"
+      }
+    ]
+  }
+}
+```
+
+### Type Check
+
+Use `--incremental` so re-runs reuse the previous `.tsbuildinfo` (1-3s on unchanged code instead of 30-60s every time). Wrap in `timeout` so a stuck tsc gets reaped by the OS instead of accumulating across edits — this prevents the multi-process buildup that happens when edits fire faster than tsc finishes.
+
+```json
+{
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Write|Edit",
+        "command": "timeout 60 pnpm tsc --noEmit --pretty false --incremental --tsBuildInfoFile node_modules/.cache/tsc-hook.tsbuildinfo",
+        "description": "Type-check after frontend edits (incremental + timeout-capped)"
+      }
+    ]
+  }
+}
+```
+
+**Why both flags matter:**
+- Without `--incremental`, every edit re-checks the entire program from scratch. On a real Next.js project this stacks fast: edits at 5-10s intervals + 30-60s tsc runs = N concurrent tsc processes.
+- Without `timeout`, a tsc that hangs (transitive dep change, type-checker stuck on a recursive type) never exits and orphans when the parent shell does.
+- `--tsBuildInfoFile` is required because `--noEmit` normally suppresses the buildinfo write; specifying the path explicitly keeps incremental working.
+
+If you're on Windows without GNU coreutils, swap `timeout 60` for a PowerShell wrapper or rely on a Stop/SessionEnd hook to sweep stale tsc processes.
+
+### CSS Lint
+
+```json
+{
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Write|Edit",
+        "command": "pnpm stylelint --fix \"$FILE_PATH\"",
+        "description": "Lint edited stylesheets"
+      }
+    ]
+  }
+}
+```
+
+## PreToolUse Hooks
+
+### Guard File Size
+
+Block oversized writes from tool input content, not from a file that may not exist yet:
+
+```json
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Write",
+        "command": "node -e \"let d='';process.stdin.on('data',c=>d+=c);process.stdin.on('end',()=>{const i=JSON.parse(d);const c=i.tool_input?.content||'';const lines=c.split('\\n').length;if(lines>800){console.error('[Hook] BLOCKED: File exceeds 800 lines ('+lines+' lines)');console.error('[Hook] Split into smaller modules');process.exit(2)}console.log(d)})\"",
+        "description": "Block writes that exceed 800 lines"
+      }
+    ]
+  }
+}
+```
+
+## Stop Hooks
+
+### Final Build Verification
+
+```json
+{
+  "hooks": {
+    "Stop": [
+      {
+        "command": "pnpm build",
+        "description": "Verify the production build at session end"
+      }
+    ]
+  }
+}
+```
+
+## Ordering
+
+Recommended order:
+1. format
+2. lint
+3. type check
+4. build verification

package/resources/ecc/rules/web/patterns.md

@@ -0,0 +1,79 @@
+> This file extends [common/patterns.md](../common/patterns.md) with web-specific patterns.
+
+# Web Patterns
+
+## Component Composition
+
+### Compound Components
+
+Use compound components when related UI shares state and interaction semantics:
+
+```tsx
+<Tabs defaultValue="overview">
+  <Tabs.List>
+    <Tabs.Trigger value="overview">Overview</Tabs.Trigger>
+    <Tabs.Trigger value="settings">Settings</Tabs.Trigger>
+  </Tabs.List>
+  <Tabs.Content value="overview">...</Tabs.Content>
+  <Tabs.Content value="settings">...</Tabs.Content>
+</Tabs>
+```
+
+- Parent owns state
+- Children consume via context
+- Prefer this over prop drilling for complex widgets
+
+### Render Props / Slots
+
+- Use render props or slot patterns when behavior is shared but markup must vary
+- Keep keyboard handling, ARIA, and focus logic in the headless layer
+
+### Container / Presentational Split
+
+- Container components own data loading and side effects
+- Presentational components receive props and render UI
+- Presentational components should stay pure
+
+## State Management
+
+Treat these separately:
+
+| Concern | Tooling |
+|---------|---------|
+| Server state | TanStack Query, SWR, tRPC |
+| Client state | Zustand, Jotai, signals |
+| URL state | search params, route segments |
+| Form state | React Hook Form or equivalent |
+
+- Do not duplicate server state into client stores
+- Derive values instead of storing redundant computed state
+
+## URL As State
+
+Persist shareable state in the URL:
+- filters
+- sort order
+- pagination
+- active tab
+- search query
+
+## Data Fetching
+
+### Stale-While-Revalidate
+
+- Return cached data immediately
+- Revalidate in the background
+- Prefer existing libraries instead of rolling this by hand
+
+### Optimistic Updates
+
+- Snapshot current state
+- Apply optimistic update
+- Roll back on failure
+- Emit visible error feedback when rolling back
+
+### Parallel Loading
+
+- Fetch independent data in parallel
+- Avoid parent-child request waterfalls
+- Prefetch likely next routes or states when justified