@rosetears/aili-pi 0.1.0

package/skills/android-native-dev/references/visual-design.md

@@ -0,0 +1,246 @@
+# Visual Design Guidelines
+
+Detailed specifications for colors, typography, spacing, elevation, and shapes in Material Design 3.
+
+## Color System
+
+### Color Roles (Tokens)
+
+Material Design 3 uses a token-based color system with three accent groups:
+
+| Role | Usage |
+|------|-------|
+| **Primary** | Key components, FAB, prominent buttons |
+| **Secondary** | Less prominent components, filters, chips |
+| **Tertiary** | Accent, complementary elements |
+| **Error** | Error states, destructive actions |
+| **Surface** | Backgrounds, cards, dialogs |
+
+Each role includes variants: base color, onColor, container, onContainer.
+
+### Color Contrast Requirements
+
+| Element | Minimum Contrast Ratio | Notes |
+|---------|----------------------|-------|
+| Body text | **4.5:1** | WCAG AA compliance |
+| Large text (18sp+) | **3:1** | 14sp bold also qualifies |
+| UI components | **3:1** | Icons, borders, controls |
+| Focus indicators | **3:1** | Must be clearly visible |
+
+### Recommended Color Palettes
+
+#### Modern Professional (Business Apps)
+
+| Role | Color | Name |
+|------|-------|------|
+| Primary | #1976D2 | Blue 700 |
+| Secondary | #455A64 | Blue Grey 700 |
+| Tertiary | #00897B | Teal 600 |
+| Background | #FAFAFA | Grey 50 |
+
+#### Vibrant & Playful (Consumer Apps)
+
+| Role | Color | Name |
+|------|-------|------|
+| Primary | #6200EE | Deep Purple |
+| Secondary | #03DAC6 | Teal Accent |
+| Tertiary | #FF5722 | Deep Orange |
+| Background | #FFFFFF | White |
+
+#### Dark & Elegant (Premium Apps)
+
+| Role | Color | Name |
+|------|-------|------|
+| Primary | #BB86FC | Purple 200 |
+| Secondary | #03DAC6 | Teal 200 |
+| Tertiary | #CF6679 | Red 200 |
+| Background | #121212 | Dark surface |
+
+#### Nature & Wellness (Health Apps)
+
+| Role | Color | Name |
+|------|-------|------|
+| Primary | #4CAF50 | Green 500 |
+| Secondary | #8BC34A | Light Green 500 |
+| Tertiary | #FFEB3B | Yellow 500 |
+| Background | #F1F8E9 | Light Green 50 |
+
+#### Finance & Trust (Banking Apps)
+
+| Role | Color | Name |
+|------|-------|------|
+| Primary | #00695C | Teal 800 |
+| Secondary | #37474F | Blue Grey 800 |
+| Tertiary | #FFC107 | Amber 500 |
+| Background | #ECEFF1 | Blue Grey 50 |
+
+### Dark Theme Requirements
+
+- Background: #121212 or darker
+- Surface colors use elevation-based tonal overlay
+- Primary colors should be lighter variants (200-300 range)
+- Maintain contrast ratios in dark mode
+- Test all states (hover, focus, pressed) in dark mode
+
+## Typography System
+
+### Type Scale
+
+| Style | Size | Weight | Line Height | Usage |
+|-------|------|--------|-------------|-------|
+| Display Large | 57sp | 400 | 64sp | Hero text |
+| Display Medium | 45sp | 400 | 52sp | Large headers |
+| Display Small | 36sp | 400 | 44sp | Section headers |
+| Headline Large | 32sp | 400 | 40sp | Screen titles |
+| Headline Medium | 28sp | 400 | 36sp | Subsection titles |
+| Headline Small | 24sp | 400 | 32sp | Card titles |
+| Title Large | 22sp | 400 | 28sp | App bar titles |
+| Title Medium | 16sp | 500 | 24sp | List item titles |
+| Title Small | 14sp | 500 | 20sp | Tabs |
+| Body Large | 16sp | 400 | 24sp | Primary body text |
+| Body Medium | 14sp | 400 | 20sp | Secondary body text |
+| Body Small | 12sp | 400 | 16sp | Captions |
+| Label Large | 14sp | 500 | 20sp | Button text |
+| Label Medium | 12sp | 500 | 16sp | Navigation labels |
+| Label Small | 11sp | 500 | 16sp | Badges |
+
+### Recommended Fonts
+
+| Category | Fonts |
+|----------|-------|
+| Primary | Roboto (system default) |
+| Display | Roboto Serif, Google Sans |
+| Monospace | Roboto Mono, JetBrains Mono |
+
+### Text Readability
+
+- **Line length**: 45-75 characters per line (including spaces)
+- **Paragraph spacing**: 1.5x line height between paragraphs
+- **Letter spacing**: Use default unless brand requires adjustment
+- **Text alignment**: Left-aligned for body text (LTR languages)
+
+## Spacing & Layout
+
+### 8dp Grid System
+
+All spacing values should be multiples of 8dp (with 4dp for fine adjustments).
+
+| Token | Value | Usage |
+|-------|-------|-------|
+| xs | 4dp | Icon padding, fine adjustments |
+| sm | 8dp | Tight spacing, inline elements |
+| md | 16dp | Default padding, card content |
+| lg | 24dp | Section spacing |
+| xl | 32dp | Large gaps, group separation |
+| xxl | 48dp | Screen margins, major sections |
+
+### Component Dimensions
+
+| Component | Height | Min Width | Notes |
+|-----------|--------|-----------|-------|
+| Button | 40dp | 64dp | Touch target 48dp |
+| FAB | 56dp | 56dp | Standard size |
+| Mini FAB | 40dp | 40dp | Secondary actions |
+| Extended FAB | 56dp | 80dp | With text label |
+| Text Field | 56dp | 280dp | Including label |
+| App Bar | 64dp | - | Top app bar |
+| Bottom Nav | 80dp | - | With labels |
+| Nav Rail | - | 80dp | Tablet/desktop |
+| List Item | 56-88dp | - | Depends on content |
+| Chip | 32dp | - | Filter/action chips |
+
+### Touch Targets
+
+| Type | Size | Notes |
+|------|------|-------|
+| Minimum | 48 × 48dp | WCAG requirement |
+| Recommended | 56 × 56dp | Primary actions |
+| Kids apps | 56dp+ | Larger for motor skills |
+| Spacing | 8dp minimum | Between adjacent targets |
+
+## Elevation & Shadows
+
+### Elevation Levels
+
+| Level | Elevation | Usage |
+|-------|-----------|-------|
+| Level 0 | 0dp | Flat surfaces |
+| Level 1 | 1dp | Cards, elevated buttons |
+| Level 2 | 3dp | FAB (resting), raised elements |
+| Level 3 | 6dp | Navigation drawer, bottom sheet |
+| Level 4 | 8dp | FAB (pressed), menus |
+| Level 5 | 12dp | Dialogs, modal surfaces |
+
+### Shadow Guidelines
+
+- Use elevation consistently for same component types
+- Higher elevation = more important/prominent
+- In dark theme, use surface tint instead of shadows
+- Avoid excessive elevation (keeps UI grounded)
+
+## Shape System
+
+### Corner Radius
+
+| Size | Radius | Usage |
+|------|--------|-------|
+| None | 0dp | Sharp edges, dividers |
+| Extra Small | 4dp | Badges, small chips |
+| Small | 8dp | Buttons, chips, small cards |
+| Medium | 12dp | Cards, dialogs, text fields |
+| Large | 16dp | FAB, bottom sheets |
+| Extra Large | 28dp | Large sheets, expanded cards |
+| Full | 50% | Pills, avatars, circular buttons |
+
+### M3 Expressive Shapes
+
+Material 3 Expressive introduces 35 new decorative shapes:
+- Organic curves
+- Asymmetric corners
+- Cut corners
+- Scalloped edges
+
+Use sparingly for brand differentiation and visual interest.
+
+### Shape Consistency Rules
+
+- Same component type = same shape
+- Related components should share shape family
+- Don't mix too many shape styles on one screen
+- Consider shape in dark/light theme transitions
+
+## Icons
+
+### Size Specifications
+
+| Size | Dimensions | Usage |
+|------|------------|-------|
+| Small | 20 × 20dp | Compact UI, inline |
+| Standard | 24 × 24dp | Default for most uses |
+| Large | 40 × 40dp | Emphasis, empty states |
+
+### Icon Guidelines
+
+- **Touch target**: Always wrap in 48dp minimum clickable area
+- **Style**: Outlined (default), Filled (selected/active states)
+- **Stroke width**: 2dp for outlined icons
+- **Optical alignment**: May need visual adjustments
+- **Color**: Use semantic colors (primary, error, etc.)
+
+### Recommended Icon Sets
+
+| Set | Usage |
+|-----|-------|
+| Material Symbols | Recommended, variable font support |
+| Material Icons | Legacy, still widely used |
+
+### Adaptive Icons (App Icon)
+
+| Property | Value |
+|----------|-------|
+| Canvas size | 108 × 108dp |
+| Safe zone | 66 × 66dp (centered circle) |
+| Logo size | 48-66dp |
+| Max display | 72 × 72dp |
+| Layers | Foreground + Background (both 108dp) |
+| Android 13+ | Include monochrome layer for theming |

package/skills/api-and-interface-design/SKILL.md

@@ -0,0 +1,318 @@
+---
+name: api-and-interface-design
+description: Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
+---
+
+# API and Interface Design
+
+## Overview
+
+Design stable, well-documented interfaces that are hard to misuse. Good interfaces make the right thing easy and the wrong thing hard. This applies to REST APIs, GraphQL schemas, module boundaries, component props, and any surface where one piece of code talks to another.
+
+## When to Use
+
+- Designing new API endpoints
+- Defining module boundaries or contracts between teams
+- Creating component prop interfaces
+- Establishing database schema that informs API shape
+- Changing existing public interfaces
+
+## Contract Design Workflow
+
+1. **Identify consumers:** list current and expected clients, internal callers, SDKs, jobs, integrations, and tests that observe the interface.
+2. **Define the contract first:** write request/input, response/output, error shape, authorization expectations, idempotency, pagination, and versioning/deprecation notes before implementation.
+3. **Check compatibility:** classify every change as additive, behavior-preserving, or breaking; prefer optional additions over field removals or type changes.
+4. **Validate boundary data:** place validation at external boundaries and parse third-party responses before using them.
+5. **Design verification:** add or update contract tests, schema checks, typed clients, or examples that prove consumer-visible behavior.
+6. **Document the contract:** keep types, OpenAPI/GraphQL schema, route docs, or module docs in sync with the implementation.
+
+🔴 CHECKPOINT / 🛑 STOP: Before changing a public route, field type, enum value, error shape, authorization rule, pagination contract, or module interface, pause and confirm whether a breaking-change plan, migration path, or deprecation window is required.
+
+## Fallbacks for Unclear Contracts
+
+| Trigger condition | First response | If still unresolved |
+|---|---|---|
+| Consumers are unknown | Search callers, clients, docs, tests, schemas, and usage examples | Treat the interface as public and avoid breaking changes |
+| Versioning policy is unclear | Prefer one-version-compatible additive changes | Escalate for product/architecture decision before version forks |
+| Error semantics differ across existing endpoints | Follow the nearest established API family | Document the inconsistency and avoid introducing a third pattern |
+| Required behavior conflicts with compatibility | Propose an additive field/endpoint or feature flag | Stop until migration/deprecation is approved |
+| Third-party response shape is undocumented | Validate with a narrow schema and fail closed | Report the unverified external contract |
+
+## Core Principles
+
+### Hyrum's Law
+
+> With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody, regardless of what you promise in the contract.
+
+This means: every public behavior — including undocumented quirks, error message text, timing, and ordering — becomes a de facto contract once users depend on it. Design implications:
+
+- **Be intentional about what you expose.** Every observable behavior is a potential commitment.
+- **Don't leak implementation details.** If users can observe it, they will depend on it.
+- **Plan for deprecation at design time.** See `deprecation-and-migration` for how to safely remove things users depend on.
+- **Tests are not enough.** Even with perfect contract tests, Hyrum's Law means "safe" changes can break real users who depend on undocumented behavior.
+
+### The One-Version Rule
+
+Avoid forcing consumers to choose between multiple versions of the same dependency or API. Diamond dependency problems arise when different consumers need different versions of the same thing. Design for a world where only one version exists at a time — extend rather than fork.
+
+### 1. Contract First
+
+Define the interface before implementing it. The contract is the spec — implementation follows.
+
+```typescript
+// Define the contract first
+interface TaskAPI {
+  // Creates a task and returns the created task with server-generated fields
+  createTask(input: CreateTaskInput): Promise<Task>;
+
+  // Returns paginated tasks matching filters
+  listTasks(params: ListTasksParams): Promise<PaginatedResult<Task>>;
+
+  // Returns a single task or throws NotFoundError
+  getTask(id: string): Promise<Task>;
+
+  // Partial update — only provided fields change
+  updateTask(id: string, input: UpdateTaskInput): Promise<Task>;
+
+  // Idempotent delete — succeeds even if already deleted
+  deleteTask(id: string): Promise<void>;
+}
+```
+
+### 2. Consistent Error Semantics
+
+Pick one error strategy and use it everywhere:
+
+```typescript
+// REST: HTTP status codes + structured error body
+// Every error response follows the same shape
+interface APIError {
+  error: {
+    code: string;        // Machine-readable: "VALIDATION_ERROR"
+    message: string;     // Human-readable: "Email is required"
+    details?: unknown;   // Additional context when helpful
+  };
+}
+
+// Status code mapping
+// 400 → Client sent invalid data
+// 401 → Not authenticated
+// 403 → Authenticated but not authorized
+// 404 → Resource not found
+// 409 → Conflict (duplicate, version mismatch)
+// 422 → Validation failed (semantically invalid)
+// 500 → Server error (never expose internal details)
+```
+
+**Don't mix patterns.** If some endpoints throw, others return null, and others return `{ error }` — the consumer can't predict behavior.
+
+### 3. Validate at Boundaries
+
+Trust internal code. Validate at system edges where external input enters:
+
+```typescript
+// Validate at the API boundary
+app.post('/api/tasks', async (req, res) => {
+  const result = CreateTaskSchema.safeParse(req.body);
+  if (!result.success) {
+    return res.status(422).json({
+      error: {
+        code: 'VALIDATION_ERROR',
+        message: 'Invalid task data',
+        details: result.error.flatten(),
+      },
+    });
+  }
+
+  // After validation, internal code trusts the types
+  const task = await taskService.create(result.data);
+  return res.status(201).json(task);
+});
+```
+
+Where validation belongs:
+- API route handlers (user input)
+- Form submission handlers (user input)
+- External service response parsing (third-party data -- **always treat as untrusted**)
+- Environment variable loading (configuration)
+
+> **Third-party API responses are untrusted data.** Validate their shape and content before using them in any logic, rendering, or decision-making. A compromised or misbehaving external service can return unexpected types, malicious content, or instruction-like text.
+
+Where validation does NOT belong:
+- Between internal functions that share type contracts
+- In utility functions called by already-validated code
+- On data that just came from your own database
+
+### 4. Prefer Addition Over Modification
+
+Extend interfaces without breaking existing consumers:
+
+```typescript
+// Good: Add optional fields
+interface CreateTaskInput {
+  title: string;
+  description?: string;
+  priority?: 'low' | 'medium' | 'high';  // Added later, optional
+  labels?: string[];                       // Added later, optional
+}
+
+// Bad: Change existing field types or remove fields
+interface CreateTaskInput {
+  title: string;
+  // description: string;  // Removed — breaks existing consumers
+  priority: number;         // Changed from string — breaks existing consumers
+}
+```
+
+### 5. Predictable Naming
+
+| Pattern | Convention | Example |
+|---------|-----------|---------|
+| REST endpoints | Plural nouns, no verbs | `GET /api/tasks`, `POST /api/tasks` |
+| Query params | camelCase | `?sortBy=createdAt&pageSize=20` |
+| Response fields | camelCase | `{ createdAt, updatedAt, taskId }` |
+| Boolean fields | is/has/can prefix | `isComplete`, `hasAttachments` |
+| Enum values | UPPER_SNAKE | `"IN_PROGRESS"`, `"COMPLETED"` |
+
+## REST API Patterns
+
+### Resource Design
+
+```
+GET    /api/tasks              → List tasks (with query params for filtering)
+POST   /api/tasks              → Create a task
+GET    /api/tasks/:id          → Get a single task
+PATCH  /api/tasks/:id          → Update a task (partial)
+DELETE /api/tasks/:id          → Delete a task
+
+GET    /api/tasks/:id/comments → List comments for a task (sub-resource)
+POST   /api/tasks/:id/comments → Add a comment to a task
+```
+
+### Pagination
+
+Paginate list endpoints:
+
+```typescript
+// Request
+GET /api/tasks?page=1&pageSize=20&sortBy=createdAt&sortOrder=desc
+
+// Response
+{
+  "data": [...],
+  "pagination": {
+    "page": 1,
+    "pageSize": 20,
+    "totalItems": 142,
+    "totalPages": 8
+  }
+}
+```
+
+### Filtering
+
+Use query parameters for filters:
+
+```
+GET /api/tasks?status=in_progress&assignee=user123&createdAfter=2025-01-01
+```
+
+### Partial Updates (PATCH)
+
+Accept partial objects — only update what's provided:
+
+```typescript
+// Only title changes, everything else preserved
+PATCH /api/tasks/123
+{ "title": "Updated title" }
+```
+
+## TypeScript Interface Patterns
+
+### Use Discriminated Unions for Variants
+
+```typescript
+// Good: Each variant is explicit
+type TaskStatus =
+  | { type: 'pending' }
+  | { type: 'in_progress'; assignee: string; startedAt: Date }
+  | { type: 'completed'; completedAt: Date; completedBy: string }
+  | { type: 'cancelled'; reason: string; cancelledAt: Date };
+
+// Consumer gets type narrowing
+function getStatusLabel(status: TaskStatus): string {
+  switch (status.type) {
+    case 'pending': return 'Pending';
+    case 'in_progress': return `In progress (${status.assignee})`;
+    case 'completed': return `Done on ${status.completedAt}`;
+    case 'cancelled': return `Cancelled: ${status.reason}`;
+  }
+}
+```
+
+### Input/Output Separation
+
+```typescript
+// Input: what the caller provides
+interface CreateTaskInput {
+  title: string;
+  description?: string;
+}
+
+// Output: what the system returns (includes server-generated fields)
+interface Task {
+  id: string;
+  title: string;
+  description: string | null;
+  createdAt: Date;
+  updatedAt: Date;
+  createdBy: string;
+}
+```
+
+### Use Branded Types for IDs
+
+```typescript
+type TaskId = string & { readonly __brand: 'TaskId' };
+type UserId = string & { readonly __brand: 'UserId' };
+
+// Prevents accidentally passing a UserId where a TaskId is expected
+function getTask(id: TaskId): Promise<Task> { ... }
+```
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "We'll document the API later" | The types ARE the documentation. Define them first. |
+| "We don't need pagination for now" | You will the moment someone has 100+ items. Add it from the start. |
+| "PATCH is complicated, let's just use PUT" | PUT requires the full object every time. PATCH is what clients actually want. |
+| "We'll version the API when we need to" | Breaking changes without versioning break consumers. Design for extension from the start. |
+| "Nobody uses that undocumented behavior" | Hyrum's Law: if it's observable, somebody depends on it. Treat every public behavior as a commitment. |
+| "We can just maintain two versions" | Multiple versions multiply maintenance cost and create diamond dependency problems. Prefer the One-Version Rule. |
+| "Internal APIs don't need contracts" | Internal consumers are still consumers. Contracts prevent coupling and enable parallel work. |
+
+## Red Flags
+
+- Endpoints that return different shapes depending on conditions
+- Inconsistent error formats across endpoints
+- Validation scattered throughout internal code instead of at boundaries
+- Breaking changes to existing fields (type changes, removals)
+- List endpoints without pagination
+- Verbs in REST URLs (`/api/createTask`, `/api/getUsers`)
+- Third-party API responses used without validation or sanitization
+- Public interface changes without consumer inventory or migration notes
+- New versioned endpoints created only to avoid designing backward compatibility
+- Error messages or enum values changed without checking observable consumer behavior
+
+## Verification
+
+After designing an API:
+
+- [ ] Every endpoint has typed input and output schemas
+- [ ] Error responses follow a single consistent format
+- [ ] Validation happens at system boundaries only
+- [ ] List endpoints support pagination
+- [ ] New fields are additive and optional (backward compatible)
+- [ ] Naming follows consistent conventions across all endpoints
+- [ ] API documentation or types are committed alongside the implementation

package/skills/browser-qa/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: browser-qa
+description: Route an explicitly requested independent/delegated browser QA assignment or durable E2E evidence need; do not trigger for direct Playwright/DOM/console/network inspection, ordinary UI implementation, backend-only work, or production-mutating flows.
+---
+
+# Browser QA
+
+Use this skill only for the delegated browser path. Direct browser inspection is owned by `browser-testing-with-devtools`; the two paths are mutually exclusive for one current intent.
+
+## Trigger
+
+- The user explicitly requests independent/delegated browser QA.
+- One concrete browser evidence gap requires `browser-qa-runner` rather than direct browser tools.
+- Durable browser/E2E artifact evidence is explicitly required and placement is resolved.
+
+## Required Safety Gate
+
+- Resolve the target URL/environment from current user/project evidence. Ask only when target identity is materially ambiguous or the action could cross an external/production gate.
+- Avoid production mutation: no real purchases, messages, account changes, destructive forms, or production data writes without the exact operation-specific approval.
+- Before saving screenshots, traces, videos, reports, console logs, or network logs, obtain a repository-local artifact placement. If no placement exists, keep evidence inline/ephemeral and report no durable artifact.
+
+## Near Misses
+
+- Persistent E2E packaging, direct local browser inspection, or backend-only verification are different primary intents. Return the exact mismatch to ROSE; do not select another skill here or combine the direct/delegated browser paths.
+- Creating Playwright config or test directories: requires explicit implementation scope and placement decision.
+
+## Required Routing
+
+- Canonical owner: ROSE/`aili-delivery-flow`.
+- Optional agent: one fresh, terminal `browser-qa-runner` assignment after a new benefit decision.
+
+ROSE/`aili-delivery-flow` owns mode, exact external/production approvals, artifact placement decisions, and final verification. This skill may return one bounded delegation need but does not invoke another skill or create a retry/review chain. One fresh QA assignment is terminal; report `complete`, `need-user`, `need-evidence`, `material-delta`, `blocked`, or `Unverified`. Canonical claim-matched verification wins.