@rosetears/aili-pi 0.1.0

package/skills/performance-optimization/SKILL.md

@@ -0,0 +1,364 @@
+---
+name: performance-optimization
+description: Optimize a measured performance problem when the user names a latency/load/Core Web Vitals/resource target or current profiling evidence identifies a bottleneck; do not trigger from generic implementation, review, or an unsupported suspicion that code may be slow.
+---
+
+# Performance Optimization
+
+## Overview
+
+Measure before optimizing. Performance work without measurement is guessing — and guessing leads to premature optimization that adds complexity without improving what matters. Profile first, identify the actual bottleneck, fix it, measure again. Optimize only what measurements prove matters.
+
+## When to Use
+
+- Performance requirements exist in the spec (load time budgets, response time SLAs)
+- Users or monitoring report slow behavior
+- Core Web Vitals scores are below thresholds
+- You suspect a change introduced a regression
+- Building features that handle large datasets or high traffic
+
+**When NOT to use:** Don't optimize before you have evidence of a problem. Premature optimization adds complexity that costs more than the performance it gains.
+
+## Core Web Vitals Targets
+
+| Metric | Good | Needs Improvement | Poor |
+|--------|------|-------------------|------|
+| **LCP** (Largest Contentful Paint) | ≤ 2.5s | ≤ 4.0s | > 4.0s |
+| **INP** (Interaction to Next Paint) | ≤ 200ms | ≤ 500ms | > 500ms |
+| **CLS** (Cumulative Layout Shift) | ≤ 0.1 | ≤ 0.25 | > 0.25 |
+
+## The Optimization Workflow
+
+```
+1. MEASURE  → Establish baseline with real data
+2. IDENTIFY → Find the actual bottleneck (not assumed)
+3. FIX      → Address the specific bottleneck
+4. VERIFY   → Measure again, confirm improvement
+5. GUARD    → Add monitoring or tests to prevent regression
+```
+
+### 🔴 CHECKPOINT / 🛑 STOP: No Speculative Optimization
+
+Do not optimize because a change "seems faster" or an anti-pattern is familiar. If there is no baseline measurement, user-reported symptom, production signal, or explicit performance budget, stop and return `BLOCKED_NEEDS_MEASUREMENT` instead of changing code.
+
+### Step 1: Measure
+
+Choose the smallest measurement source that can establish the accepted performance claim; use both only when the claim explicitly spans lab reproducibility and real-user impact:
+
+- **Synthetic (Lighthouse, OpenCode Playwright/browser tooling, DevTools Performance tab):** Controlled conditions, reproducible. Best for CI regression detection and isolating specific issues.
+- **RUM (web-vitals library, CrUX):** Real-user data in real conditions. Use when the claim concerns production/user impact and current policy allows the data source.
+
+**Frontend:**
+```bash
+# Synthetic: Lighthouse in CI/manual runs
+# OpenCode: return a concrete direct-browser evidence need to ROSE when runtime UI measurement is the smallest sufficient path
+# Manual reference: Chrome DevTools → Performance tab → Record
+
+# RUM: Web Vitals library in code
+import { onLCP, onINP, onCLS } from 'web-vitals';
+
+onLCP(console.log);
+onINP(console.log);
+onCLS(console.log);
+```
+
+**Backend:**
+```bash
+# Response time logging
+# Application Performance Monitoring (APM)
+# Database query logging with timing
+
+# Simple timing
+console.time('db-query');
+const result = await db.query(...);
+console.timeEnd('db-query');
+```
+
+### Where to Start Measuring
+
+Use the symptom to decide what to measure first:
+
+```
+What is slow?
+├── First page load
+│   ├── Large bundle? --> Measure bundle size, check code splitting
+│   ├── Slow server response? --> Measure TTFB in OpenCode browser network requests or DevTools Network waterfall
+│   │   ├── DNS long? --> Add dns-prefetch / preconnect for known origins
+│   │   ├── TCP/TLS long? --> Enable HTTP/2, check edge deployment, keep-alive
+│   │   └── Waiting (server) long? --> Profile backend, check queries and caching
+│   └── Render-blocking resources? --> Check network waterfall for CSS/JS blocking
+├── Interaction feels sluggish
+│   ├── UI freezes on click? --> Profile main thread, look for long tasks (>50ms)
+│   ├── Form input lag? --> Check re-renders, controlled component overhead
+│   └── Animation jank? --> Check layout thrashing, forced reflows
+├── Page after navigation
+│   ├── Data loading? --> Measure API response times, check for waterfalls
+│   └── Client rendering? --> Profile component render time, check for N+1 fetches
+└── Backend / API
+    ├── Single endpoint slow? --> Profile database queries, check indexes
+    ├── All endpoints slow? --> Check connection pool, memory, CPU
+    └── Intermittent slowness? --> Check for lock contention, GC pauses, external deps
+```
+
+### Measurement-Unavailable Fallbacks
+
+| Trigger | First action | If still unresolved |
+|---|---|---|
+| Browser profiling unavailable | Capture network timing, console warnings, screenshot/snapshot, and available Performance API entries | Mark Core Web Vitals as `[UNVERIFIED]`; do not claim frontend improvement |
+| Production/RUM data unavailable | Use reproducible synthetic measurements with device/network settings stated | Label the result `synthetic_only` and request RUM before broad rollout |
+| Backend profiler unavailable | Add bounded timing around the suspected path or inspect existing logs/APM | Mark root cause as `Hypothesis`; do not rewrite unrelated code |
+| Measurements conflict | Prefer production/RUM for user impact and synthetic traces for root cause | Hold optimization until the conflict is explained or scoped |
+
+### Step 2: Identify the Bottleneck
+
+Common bottlenecks by category:
+
+**Frontend:**
+
+| Symptom | Likely Cause | Investigation |
+|---------|-------------|---------------|
+| Slow LCP | Large images, render-blocking resources, slow server | Check network waterfall, image sizes |
+| High CLS | Images without dimensions, late-loading content, font shifts | Check layout shift attribution |
+| Poor INP | Heavy JavaScript on main thread, large DOM updates | Check long tasks in Performance trace |
+| Slow initial load | Large bundle, many network requests | Check bundle size, code splitting |
+
+**Backend:**
+
+| Symptom | Likely Cause | Investigation |
+|---------|-------------|---------------|
+| Slow API responses | N+1 queries, missing indexes, unoptimized queries | Check database query log |
+| Memory growth | Leaked references, unbounded caches, large payloads | Heap snapshot analysis |
+| CPU spikes | Synchronous heavy computation, regex backtracking | CPU profiling |
+| High latency | Missing caching, redundant computation, network hops | Trace requests through the stack |
+
+### Step 3: Fix Common Anti-Patterns
+
+#### N+1 Queries (Backend)
+
+```typescript
+// BAD: N+1 — one query per task for the owner
+const tasks = await db.tasks.findMany();
+for (const task of tasks) {
+  task.owner = await db.users.findUnique({ where: { id: task.ownerId } });
+}
+
+// GOOD: Single query with join/include
+const tasks = await db.tasks.findMany({
+  include: { owner: true },
+});
+```
+
+#### Unbounded Data Fetching
+
+```typescript
+// BAD: Fetching all records
+const allTasks = await db.tasks.findMany();
+
+// GOOD: Paginated with limits
+const tasks = await db.tasks.findMany({
+  take: 20,
+  skip: (page - 1) * 20,
+  orderBy: { createdAt: 'desc' },
+});
+```
+
+#### Missing Image Optimization (Frontend)
+
+```html
+<!-- BAD: No dimensions, no format optimization -->
+<img src="/hero.jpg" />
+
+<!-- GOOD: Hero / LCP image — art direction + resolution switching, high priority -->
+<!--
+  Two techniques combined:
+  - Art direction (media): different crop/composition per breakpoint
+  - Resolution switching (srcset + sizes): right file size per screen density
+-->
+<picture>
+  <!-- Mobile: portrait crop (8:10) -->
+  <source
+    media="(max-width: 767px)"
+    srcset="/hero-mobile-400.avif 400w, /hero-mobile-800.avif 800w"
+    sizes="100vw"
+    width="800"
+    height="1000"
+    type="image/avif"
+  />
+  <source
+    media="(max-width: 767px)"
+    srcset="/hero-mobile-400.webp 400w, /hero-mobile-800.webp 800w"
+    sizes="100vw"
+    width="800"
+    height="1000"
+    type="image/webp"
+  />
+  <!-- Desktop: landscape crop (2:1) -->
+  <source
+    srcset="/hero-800.avif 800w, /hero-1200.avif 1200w, /hero-1600.avif 1600w"
+    sizes="(max-width: 1200px) 100vw, 1200px"
+    width="1200"
+    height="600"
+    type="image/avif"
+  />
+  <source
+    srcset="/hero-800.webp 800w, /hero-1200.webp 1200w, /hero-1600.webp 1600w"
+    sizes="(max-width: 1200px) 100vw, 1200px"
+    width="1200"
+    height="600"
+    type="image/webp"
+  />
+  <img
+    src="/hero-desktop.jpg"
+    width="1200"
+    height="600"
+    fetchpriority="high"
+    alt="Hero image description"
+  />
+</picture>
+
+<!-- GOOD: Below-the-fold image — lazy loaded + async decoding -->
+<img
+  src="/content.webp"
+  width="800"
+  height="400"
+  loading="lazy"
+  decoding="async"
+  alt="Content image description"
+/>
+```
+
+#### Unnecessary Re-renders (React)
+
+```tsx
+// BAD: Creates new object on every render, causing children to re-render
+function TaskList() {
+  return <TaskFilters options={{ sortBy: 'date', order: 'desc' }} />;
+}
+
+// GOOD: Stable reference
+const DEFAULT_OPTIONS = { sortBy: 'date', order: 'desc' } as const;
+function TaskList() {
+  return <TaskFilters options={DEFAULT_OPTIONS} />;
+}
+
+// Use React.memo for expensive components
+const TaskItem = React.memo(function TaskItem({ task }: Props) {
+  return <div>{/* expensive render */}</div>;
+});
+
+// Use useMemo for expensive computations
+function TaskStats({ tasks }: Props) {
+  const stats = useMemo(() => calculateStats(tasks), [tasks]);
+  return <div>{stats.completed} / {stats.total}</div>;
+}
+```
+
+#### Large Bundle Size
+
+```typescript
+// Modern bundlers (Vite, webpack 5+) handle named imports with tree-shaking automatically,
+// provided the dependency ships ESM and is marked `sideEffects: false` in package.json.
+// Profile before changing import styles — the real gains come from splitting and lazy loading.
+
+// GOOD: Dynamic import for heavy, rarely-used features
+const ChartLibrary = lazy(() => import('./ChartLibrary'));
+
+// GOOD: Route-level code splitting wrapped in Suspense
+const SettingsPage = lazy(() => import('./pages/Settings'));
+
+function App() {
+  return (
+    <Suspense fallback={<Spinner />}>
+      <SettingsPage />
+    </Suspense>
+  );
+}
+```
+
+#### Missing Caching (Backend)
+
+```typescript
+// Cache frequently-read, rarely-changed data
+const CACHE_TTL = 5 * 60 * 1000; // 5 minutes
+let cachedConfig: AppConfig | null = null;
+let cacheExpiry = 0;
+
+async function getAppConfig(): Promise<AppConfig> {
+  if (cachedConfig && Date.now() < cacheExpiry) {
+    return cachedConfig;
+  }
+  cachedConfig = await db.config.findFirst();
+  cacheExpiry = Date.now() + CACHE_TTL;
+  return cachedConfig;
+}
+
+// HTTP caching headers for static assets
+app.use('/static', express.static('public', {
+  maxAge: '1y',           // Cache for 1 year
+  immutable: true,        // Never revalidate (use content hashing in filenames)
+}));
+
+// Cache-Control for API responses
+res.set('Cache-Control', 'public, max-age=300'); // 5 minutes
+```
+
+## Performance Budget
+
+Set budgets and enforce them:
+
+```
+JavaScript bundle: < 200KB gzipped (initial load)
+CSS: < 50KB gzipped
+Images: < 200KB per image (above the fold)
+Fonts: < 100KB total
+API response time: < 200ms (p95)
+Time to Interactive: < 3.5s on 4G
+Lighthouse Performance score: ≥ 90
+```
+
+**Enforce in CI:**
+```bash
+# Bundle size check
+npx bundlesize --config bundlesize.config.json
+
+# Lighthouse CI
+npx lhci autorun
+```
+
+## Inline Performance Checklist
+
+Use the workflow, bottleneck tables, budget, and verification checklist in this file as the source of truth. Do not reference external checklist files unless they exist in this skill directory.
+
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "We'll optimize later" | Performance debt compounds. Fix obvious anti-patterns now, defer micro-optimizations. |
+| "It's fast on my machine" | Your machine isn't the user's. Profile on representative hardware and networks. |
+| "This optimization is obvious" | If you didn't measure, you don't know. Profile first. |
+| "Users won't notice this delay" | Do not assume impact; compare the named budget or representative measurement. |
+| "The framework handles performance" | Frameworks prevent some issues but can't fix N+1 queries or oversized bundles. |
+
+## Red Flags
+
+- Optimization without profiling data to justify it
+- Speculative performance rewrites when measurement is unavailable
+- N+1 query patterns in data fetching
+- List endpoints without pagination
+- Images without dimensions, lazy loading, or responsive sizes
+- Bundle size growing without review
+- No performance monitoring in production
+- `React.memo` and `useMemo` everywhere (overusing is as bad as underusing)
+
+## Verification
+
+For the selected measured performance claim, apply only relevant rows and let the canonical owner choose the final evidence:
+
+- [ ] Before and after measurements exist (specific numbers)
+- [ ] The specific bottleneck is identified and addressed
+- [ ] Core Web Vitals are checked only when a Web Vitals claim is in scope
+- [ ] Bundle size is checked only when the changed bundle path is in scope
+- [ ] Query count is checked only when data-fetching/database behavior is in scope
+- [ ] Performance budget passes in CI (if configured)
+- [ ] Behavior-regression evidence is run only when the exact changed claim requires it

package/skills/planning-and-task-breakdown/SKILL.md

@@ -0,0 +1,290 @@
+---
+name: planning-and-task-breakdown
+description: Break a clear scope or accepted specification into ordered tasks/packages when the user explicitly asks for a plan, estimate, dependency order, or task breakdown; do not trigger for ordinary implementation, every multi-step task, speculative parallelism, review, or completion.
+---
+
+# Planning and Task Breakdown
+
+## Overview
+
+When explicit planning intent selects this skill, decompose the accepted scope into coherent, dependency-ordered tasks or packages with acceptance criteria and claim-matched evidence targets. Ordinary implementation with a clear next step remains direct.
+
+## When to Use
+
+- The user asks for an implementation plan, task breakdown, estimate, dependency order, or package split.
+- A formal DEFINE change has a dependency-ready tasks artifact to produce or revise.
+- One accepted scope is too large to execute coherently without an explicit bounded package order.
+
+**When NOT to use:** Ordinary implementation with a clear next step, a spec that already has usable tasks, generic discussion of possible parallelism, review, or verification.
+
+## Canonical loop contract
+
+This skill is one bounded ordinary-plan or DEFINE-tasks adapter. ROSE/`aili-delivery-flow` owns lifecycle state, artifact identity, approvals, progress, dispatch, and verification. Produce one dependency-ordered plan/task set and stop with `complete`, `need-user`, `need-evidence`, `material-delta`, `blocked`, or `Unverified`. Do not invoke spec, requirements, research, stress-test, implementation, TDD, review, or another process skill; return one named need to ROSE. No plan review/approval is added beyond material decisions and formal final `test-plan.md` acceptance. Canonical claim-matched verification overrides generic checklist commands.
+
+## The Planning Process
+
+### Step 1: Enter Plan Mode
+
+Before writing any code, operate in read-only mode:
+
+- Read the spec and relevant codebase sections
+- Identify existing patterns and conventions
+- Map dependencies between components
+- Note risks and unknowns
+
+**Do NOT write code during planning.** The output is a plan document, not implementation.
+
+### Step 2: Identify the Dependency Graph
+
+Map what depends on what:
+
+```
+Database schema
+    │
+    ├── API models/types
+    │       │
+    │       ├── API endpoints
+    │       │       │
+    │       │       └── Frontend API client
+    │       │               │
+    │       │               └── UI components
+    │       │
+    │       └── Validation logic
+    │
+    └── Seed data / migrations
+```
+
+Implementation order follows the dependency graph bottom-up: build foundations first.
+
+### Step 3: Slice Vertically
+
+Instead of building all the database, then all the API, then all the UI — build one complete feature path at a time:
+
+**Bad (horizontal slicing):**
+```
+Task 1: Build entire database schema
+Task 2: Build all API endpoints
+Task 3: Build all UI components
+Task 4: Connect everything
+```
+
+**Good (vertical slicing):**
+```
+Task 1: User can create an account (schema + API + UI for registration)
+Task 2: User can log in (auth schema + API + UI for login)
+Task 3: User can create a task (task schema + API + UI for creation)
+Task 4: User can view task list (query + API + UI for list view)
+```
+
+Each vertical slice delivers working, testable functionality.
+
+### Step 4: Write Tasks
+
+Each task follows this structure:
+
+```markdown
+## Task [N]: [Short descriptive title]
+
+**Description:** One paragraph explaining what this task accomplishes.
+
+**Acceptance criteria:**
+- [ ] [Specific, testable condition]
+- [ ] [Specific, testable condition]
+
+**Verification:**
+- [ ] Evidence: [smallest test, build, inspection, or manual observation required by the affected claim; omit or mark N/A when no package-local check is needed]
+
+**Dependencies:** [Task numbers this depends on, or "None"]
+
+**Files likely touched:**
+- `src/path/to/file.ts`
+- `tests/path/to/test.ts`
+
+**Scope boundary:** [coherent behavior/dependency, owner, risk, reversibility, and likely files]
+```
+
+### Prototype Before Committing to a Design
+
+Treat a throwaway prototype as a separately selected implementation action, not an automatic planning step. Use it only when explicitly in scope and it answers a concrete design question.
+
+Good prototype questions:
+- Does this state machine feel right?
+- Does this data model support the edge cases?
+- Which UI direction is clearer?
+- Can this integration path work with the current constraints?
+
+Prototype rules:
+- Mark prototype code clearly as throwaway.
+- Keep it close to the relevant module/page, but visibly non-production.
+- Make it runnable with one command.
+- Avoid persistence unless the question is specifically about persistence.
+- Skip polish, broad abstractions, and production hardening.
+- Surface state clearly after each interaction.
+- Delete it or absorb the validated decision into real code when done.
+- Capture the answer in a commit message, ADR, issue, or nearby note before deleting.
+
+### Issue-Shaped Work Packages
+
+When turning a plan into executable work, structure each unit like an issue even if no issue tracker is used.
+
+Each work package should include:
+- Title
+- Type: `AFK` or `HITL`
+- What to build
+- Acceptance criteria
+- Verification evidence or explicit N/A
+- Blocked by
+- User stories or requirements covered
+- Likely files
+- Explicit non-goals
+
+Prefer AFK slices when safe. Mark HITL when the slice requires product judgment, architecture choice, design review, credentials, environment access, or risky approval.
+
+Do not publish, close, or modify external issues unless the user explicitly asks.
+
+### Step 5: Order and Checkpoint
+
+Arrange tasks so that:
+
+1. Dependencies are satisfied (build foundation first)
+2. Each task leaves the system in a working state
+3. Verification points are attached only where a claim or dependency needs evidence
+4. High-risk tasks are early (fail fast)
+
+Add explicit checkpoints:
+
+```markdown
+## Checkpoint: After Tasks 1-3
+- [ ] The canonical owner selects the smallest check needed by the affected claim
+- [ ] Any material decision or exact risky operation is named before dependent work
+```
+
+### Plan Stress Test
+
+Before finalizing, run this direct plan consistency checklist. Use a separate stress-test only on explicit user intent or one named material loophole selected by ROSE.
+
+Check whether:
+
+- any task is still too large
+- any task combines independent outcomes that need separate ownership, ordering, or rollback
+- dependencies are missing or ordered incorrectly
+- shared mutable state requires sequential execution
+- parallel work packages would edit overlapping files
+- verification steps are too vague
+- likely files are missing for risky tasks
+- acceptance criteria are not testable
+- user judgment is required and should be marked `HITL`
+- external credentials, environment access, release approvals, or migrations are required
+
+Fix the plan when evidence supports the fix. Otherwise mark the item as `Open Question` or `Unverified`.
+
+### 🔴 CHECKPOINT / 🛑 STOP: Dispatch and Parallel Work Gate
+
+Before assigning work to another agent, session, issue, or parallel lane, confirm:
+
+- each package has non-overlapping files or an explicit sequential dependency
+- shared contracts, schemas, APIs, and acceptance criteria are settled first
+- each package has a single owner, expected evidence, and blocked-by field; package boundaries do not mandate a command
+- risky work is marked `HITL` when it needs product, architecture, credential, migration, or release approval
+
+If any item is missing, stop and revise the plan; do not dispatch ambiguous or overlapping packages.
+
+### Oversized or Blocked Task Fallbacks
+
+| Trigger | First action | If still unresolved |
+|---|---|---|
+| Task combines independent behaviors or subsystems | Split by vertical user-visible slice or dependency layer | Mark unresolved scope as `Open Question` and return material decisions to ROSE |
+| Acceptance criteria mix unrelated outcomes | Separate behavior, edge cases, and evidence by coherent ownership/dependency | Mark unclear criteria as `Open Question` |
+| Likely files overlap across parallel packages | Make the packages sequential or define a shared contract task first | Do not parallelize |
+| Task needs credentials, schema migration, release approval, or destructive action | Mark `HITL` and name the required approval/evidence | Block implementation until the human gate is cleared |
+
+## Task Boundary Guidelines
+
+Keep a task intact when its files and actions are necessary for one coherent accepted behavior and can be verified through one clear evidence path. Split when independent outcomes, owners, risky approvals, rollback boundaries, or dependency order would otherwise be hidden.
+
+File count, estimated elapsed time, title wording, or bullet count may help describe a task but never acts as a gate by itself.
+
+## Plan Document Template
+
+```markdown
+# Implementation Plan: [Feature/Project Name]
+
+## Overview
+[One paragraph summary of what we're building]
+
+## Architecture Decisions
+- [Key decision 1 and rationale]
+- [Key decision 2 and rationale]
+
+## Task List
+
+### Phase 1: Foundation
+- [ ] Task 1: ...
+- [ ] Task 2: ...
+
+### Checkpoint: Foundation
+- [ ] Savepoint records completed scope, unresolved dependencies, and next task
+
+### Phase 2: Core Features
+- [ ] Task 3: ...
+- [ ] Task 4: ...
+
+### Checkpoint: Core Features
+- [ ] End-to-end flow works
+
+### Phase 3: Polish
+- [ ] Task 5: ...
+- [ ] Task 6: ...
+
+### Checkpoint: Complete
+- [ ] All acceptance criteria met
+- [ ] Canonical owner has one claim-matched verification path
+
+## Risks and Mitigations
+| Risk | Impact | Mitigation |
+|------|--------|------------|
+| [Risk] | [High/Med/Low] | [Strategy] |
+
+## Open Questions
+- [Question needing human input]
+```
+
+## Parallelization Opportunities
+
+Include this section only when the user requests parallel work or at least two independent units have a clear wall-clock/context benefit. Otherwise omit it and keep the plan direct/serial.
+
+- **Safe to parallelize:** Independent feature slices, tests for already-implemented features, documentation
+- **Must be sequential:** Database migrations, shared state changes, dependency chains
+- **Needs coordination:** Features that share an API contract (define the contract first, then parallelize)
+- **Do not parallelize:** Packages with overlapping edit paths, unsettled public contracts, shared mutable state, or missing verification commands
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "I'll figure it out as I go" | Once planning is explicitly selected, record the dependency and risk decisions needed for execution. |
+| "The tasks are obvious" | When planning was explicitly requested, record only the dependency/order details that improve execution; do not manufacture ceremony. |
+| "Planning is overhead" | Use planning only when requested or selected for a concrete coordination need; otherwise keep ordinary implementation direct. |
+| "I can hold it all in my head" | Context windows are finite. Written plans survive session boundaries and compaction. |
+
+## Red Flags
+
+- Forcing a written task list onto clear ordinary implementation
+- Tasks that say "implement the feature" without acceptance criteria
+- No claim-matched evidence target where a task's acceptance needs one
+- Independent outcomes hidden in one package without an ownership or dependency reason
+- No savepoint where a long/resumable plan needs one
+- Dependency order isn't considered
+- Parallel dispatch before overlap, ownership, and verification are explicit
+- Blocked or oversized tasks passed to implementation without a fallback decision
+
+## Verification
+
+Before starting implementation, confirm:
+
+- [ ] Every task has acceptance criteria
+- [ ] Each task names only the evidence required by its affected claim, or explicitly needs no package-local check
+- [ ] Task dependencies are identified and ordered correctly
+- [ ] Task boundaries follow dependencies and coherent behavior rather than an arbitrary file limit
+- [ ] Evidence points exist only where the affected claim needs them
+- [ ] Material decisions are resolved and formal final `test-plan.md` acceptance remains owned by the lifecycle