@rosetears/aili-pi 0.1.0

package/skills/deprecation-and-migration/SKILL.md

@@ -0,0 +1,222 @@
+---
+name: deprecation-and-migration
+description: Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when deciding whether to maintain or sunset existing code.
+---
+
+# Deprecation and Migration
+
+## Overview
+
+Code is a liability, not an asset. Every line of code has ongoing maintenance cost — bugs to fix, dependencies to update, security patches to apply, and new engineers to onboard. Deprecation is the discipline of removing code that no longer earns its keep, and migration is the process of moving users safely from the old to the new.
+
+Most engineering organizations are good at building things. Few are good at removing them. This skill addresses that gap.
+
+## When to Use
+
+- Replacing an old system, API, or library with a new one
+- Sunsetting a feature that's no longer needed
+- Consolidating duplicate implementations
+- Removing dead code that nobody owns but everybody depends on
+- Planning the lifecycle of a new system (deprecation planning starts at design time)
+- Deciding whether to maintain a legacy system or invest in migration
+
+## Core Principles
+
+### Code Is a Liability
+
+Every line of code has ongoing cost: it needs tests, documentation, security patches, dependency updates, and mental overhead for anyone working nearby. The value of code is the functionality it provides, not the code itself. When the same functionality can be provided with less code, less complexity, or better abstractions — the old code should go.
+
+### Hyrum's Law Makes Removal Hard
+
+With enough users, every observable behavior becomes depended on — including bugs, timing quirks, and undocumented side effects. This is why deprecation requires active migration, not just announcement. Users can't "just switch" when they depend on behaviors the replacement doesn't replicate.
+
+### Deprecation Planning Starts at Design Time
+
+When building something new, ask: "How would we remove this in 3 years?" Systems designed with clean interfaces, feature flags, and minimal surface area are easier to deprecate than systems that leak implementation details everywhere.
+
+## The Deprecation Decision
+
+Before deprecating anything, answer these questions:
+
+```
+1. Does this system still provide unique value?
+   → If yes, maintain it. If no, proceed.
+
+2. How many users/consumers depend on it?
+   → Quantify the migration scope.
+
+3. Does a replacement exist?
+   → If no, build the replacement first. Don't deprecate without an alternative.
+
+4. What's the migration cost for each consumer?
+   → If trivially automated, do it. If manual and high-effort, weigh against maintenance cost.
+
+5. What's the ongoing maintenance cost of NOT deprecating?
+   → Security risk, engineer time, opportunity cost of complexity.
+```
+
+## Compulsory vs Advisory Deprecation
+
+| Type | When to Use | Mechanism |
+|------|-------------|-----------|
+| **Advisory** | Migration is optional, old system is stable | Warnings, documentation, nudges. Users migrate on their own timeline. |
+| **Compulsory** | Old system has security issues, blocks progress, or maintenance cost is unsustainable | Hard deadline. Old system will be removed by date X. Provide migration tooling. |
+
+**Default to advisory.** Use compulsory only when the maintenance cost or risk justifies forcing migration. Compulsory deprecation requires providing migration tooling, documentation, and support — you can't just announce a deadline.
+
+🔴 **CHECKPOINT · Compulsory Deprecation:** Stop before converting advisory deprecation into a forced migration. Continue only when the accountable owner approves the reason, affected consumers, migration support plan, removal date, and rollback/extension criteria.
+
+🔴 **CHECKPOINT · Removal Date:** Stop before publishing a hard removal date. The date must include evidence of replacement readiness, consumer impact, support channel, and who can approve an extension.
+
+## The Migration Process
+
+### Step 1: Build the Replacement
+
+Don't deprecate without a working alternative. The replacement must:
+
+- Cover all critical use cases of the old system
+- Have documentation and migration guides
+- Be proven in production (not just "theoretically better")
+
+### Step 2: Announce and Document
+
+```markdown
+## Deprecation Notice: OldService
+
+**Status:** Deprecated as of 2025-03-01
+**Replacement:** NewService (see migration guide below)
+**Removal date:** Advisory — no hard deadline yet
+**Reason:** OldService requires manual scaling and lacks observability.
+            NewService handles both automatically.
+
+### Migration Guide
+1. Replace `import { client } from 'old-service'` with `import { client } from 'new-service'`
+2. Update configuration (see examples below)
+3. Run the migration verification script: `npx migrate-check`
+```
+
+### Step 3: Migrate Incrementally
+
+Migrate consumers one at a time, not all at once. For each consumer:
+
+```
+1. Identify all touchpoints with the deprecated system
+2. Update to use the replacement
+3. Verify behavior matches (tests, integration checks)
+4. Remove references to the old system
+5. Confirm no regressions
+```
+
+**The Churn Rule:** If you own the infrastructure being deprecated, you are responsible for migrating your users — or providing backward-compatible updates that require no migration. Don't announce deprecation and leave users to figure it out.
+
+### Step 4: Remove the Old System
+
+Only after all consumers have migrated:
+
+```
+1. Verify zero active usage (metrics, logs, dependency analysis)
+2. 🔴 CHECKPOINT · Code Deletion: get explicit approval to delete code, tests, docs, and config
+3. Remove associated tests, documentation, and configuration
+4. Remove the deprecation notices
+5. Celebrate — removing code is an achievement
+```
+
+**Removal failure fallback:**
+
+| Trigger | First action | If still unresolved |
+|---|---|---|
+| Active usage remains | Keep the old system running and contact the consuming owner | Extend the removal date through the Removal Date checkpoint |
+| Replacement does not cover a critical use case | Pause compulsory migration and close the gap in the replacement | Downgrade to advisory until replacement readiness is proven |
+| Owner approval is missing | Do not delete code | Escalate with usage evidence, migration status, and proposed new date |
+| Deletion breaks tests or dependent builds | Restore the deleted path in the same change and identify the dependency | Re-plan consumer migration before attempting deletion again |
+
+## Migration Patterns
+
+### Strangler Pattern
+
+Run old and new systems in parallel. Route traffic incrementally from old to new. When the old system handles 0% of traffic, remove it.
+
+```
+Phase 1: New system handles 0%, old handles 100%
+Phase 2: New system handles 10% (canary)
+Phase 3: New system handles 50%
+Phase 4: New system handles 100%, old system idle
+Phase 5: Remove old system
+```
+
+### Adapter Pattern
+
+Create an adapter that translates calls from the old interface to the new implementation. Consumers keep using the old interface while you migrate the backend.
+
+```typescript
+// Adapter: old interface, new implementation
+class LegacyTaskService implements OldTaskAPI {
+  constructor(private newService: NewTaskService) {}
+
+  // Old method signature, delegates to new implementation
+  getTask(id: number): OldTask {
+    const task = this.newService.findById(String(id));
+    return this.toOldFormat(task);
+  }
+}
+```
+
+### Feature Flag Migration
+
+Use feature flags to switch consumers from old to new system one at a time:
+
+```typescript
+function getTaskService(userId: string): TaskService {
+  if (featureFlags.isEnabled('new-task-service', { userId })) {
+    return new NewTaskService();
+  }
+  return new LegacyTaskService();
+}
+```
+
+## Zombie Code
+
+Zombie code is code that nobody owns but everybody depends on. It's not actively maintained, has no clear owner, and accumulates security vulnerabilities and compatibility issues. Signs:
+
+- No commits in 6+ months but active consumers exist
+- No assigned maintainer or team
+- Failing tests that nobody fixes
+- Dependencies with known vulnerabilities that nobody updates
+- Documentation that references systems that no longer exist
+
+**Response:** Either assign an owner and maintain it properly, or deprecate it with a concrete migration plan. Zombie code cannot stay in limbo — it either gets investment or removal.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "It still works, why remove it?" | Working code that nobody maintains accumulates security debt and complexity. Maintenance cost grows silently. |
+| "Someone might need it later" | If it's needed later, it can be rebuilt. Keeping unused code "just in case" costs more than rebuilding. |
+| "The migration is too expensive" | Compare migration cost to ongoing maintenance cost over 2-3 years. Migration is usually cheaper long-term. |
+| "We'll deprecate it after we finish the new system" | Deprecation planning starts at design time. By the time the new system is done, you'll have new priorities. Plan now. |
+| "Users will migrate on their own" | They won't. Provide tooling, documentation, and incentives — or do the migration yourself (the Churn Rule). |
+| "We can maintain both systems indefinitely" | Two systems doing the same thing is double the maintenance, testing, documentation, and onboarding cost. |
+
+## Red Flags
+
+- Deprecated systems with no replacement available
+- Deprecation announcements with no migration tooling or documentation
+- Compulsory deprecation without explicit owner approval, support plan, and removal date
+- "Soft" deprecation that's been advisory for years with no progress
+- Hard removal date with no extension criteria or consumer impact evidence
+- Zombie code with no owner and active consumers
+- New features added to a deprecated system (invest in the replacement instead)
+- Deprecation without measuring current usage
+- Removing code without verifying zero active consumers
+- Deleting code, tests, docs, or config before the Code Deletion checkpoint
+
+## Verification
+
+After completing a deprecation:
+
+- [ ] Replacement is production-proven and covers all critical use cases
+- [ ] Migration guide exists with concrete steps and examples
+- [ ] All active consumers have been migrated (verified by metrics/logs)
+- [ ] Old code, tests, documentation, and configuration are fully removed
+- [ ] No references to the deprecated system remain in the codebase
+- [ ] Deprecation notices are removed (they served their purpose)

package/skills/documentation-and-adrs/SKILL.md

@@ -0,0 +1,330 @@
+---
+name: documentation-and-adrs
+description: Create or update source-grounded documentation when the user explicitly asks for docs/ADR/onboarding material, a public contract change requires docs, or an accepted hard-to-reverse decision meets the ADR gate; do not trigger for every feature, architecture discussion, implementation, review, or SHIP request.
+---
+
+# Documentation and ADRs
+
+## Overview
+
+Document decisions, not just code. The most valuable documentation captures the *why* — the context, constraints, and trade-offs that led to a decision. Code shows *what* was built; documentation explains *why it was built this way* and *what alternatives were considered*. This context is essential for future humans and agents working in the codebase.
+
+When documenting code or architecture, synthesize the system behavior from source evidence instead of listing files. A good document explains entry points, responsibilities, flows, invariants, and boundaries, with paths or symbols as evidence anchors.
+
+## When to Use
+
+- The user explicitly requests documentation, an ADR, architecture notes, API docs, or onboarding material.
+- An accepted public API/config/workflow change requires its existing documentation to stay accurate.
+- A settled decision is hard to reverse, surprising without context, and has a real trade-off.
+
+**When NOT to use:** Ordinary implementation, an unresolved architecture choice, SHIP alone, obvious code, comments that restate code, or throwaway prototypes.
+
+ROSE/`aili-delivery-flow` owns lifecycle state, material decisions, artifact placement, approvals, and verification. This skill performs one bounded documentation/ADR loop and returns `complete`, `need-user`, `need-evidence`, `material-delta`, `blocked`, or `Unverified`. It does not invoke requirements, planning, source research, review, release, or another process skill. Canonical exact-operation and claim-matched verification rules win.
+
+## Source-Grounded Documentation Reports
+
+Use this pattern for code documentation, architecture notes, or onboarding docs:
+
+1. Define the reader and the decision/action the document should support.
+2. Inspect authoritative sources first: code, tests, schemas, configs, ADRs, release notes, and existing docs.
+3. Summarize responsibilities and flows in your own words; cite paths, symbols, commands, or docs for each non-obvious claim.
+4. Mark stale/conflicting docs explicitly and avoid resolving product or architecture questions by writing around them.
+5. Prefer diagrams/tables only when they clarify ownership, data flow, lifecycle, or constraints.
+6. Include verification or freshness notes: command run, files inspected, date/version, and remaining `Unverified` gaps.
+
+## Architecture Decision Records (ADRs)
+
+ADRs capture the reasoning behind significant technical decisions. They're the highest-value documentation you can write.
+
+### When to Write an ADR
+
+- Choosing a framework, library, or major dependency
+- Designing a data model or database schema
+- Selecting an authentication strategy
+- Deciding on an API architecture (REST vs. GraphQL vs. tRPC)
+- Choosing between build tools, hosting platforms, or infrastructure
+- Any decision that would be expensive to reverse
+
+Offer an ADR only when all are true:
+1. **Hard to reverse** — changing later has meaningful cost.
+2. **Surprising without context** — a future maintainer would ask why.
+3. **Real trade-off** — credible alternatives existed and one was chosen for a reason.
+
+Skip ADRs for obvious choices, temporary decisions, minor implementation details, or choices with no real alternatives.
+
+### 🔴 CHECKPOINT · ADR Decision Gate
+
+🛑 STOP before writing an ADR as accepted when the decision changes architecture, data model, authentication, infrastructure, public API, or a hard-to-reverse dependency. Confirm the decision owner, accepted option, rejected alternatives, and reversal cost first.
+
+If those facts are missing, write a proposed ADR or an interview packet instead of inventing rationale.
+
+### ADR Template
+
+Store ADRs in `docs/decisions/` with sequential numbering:
+
+```markdown
+# ADR-001: Use PostgreSQL for primary database
+
+## Status
+Accepted | Superseded by ADR-XXX | Deprecated
+
+## Date
+2025-01-15
+
+## Context
+We need a primary database for the task management application. Key requirements:
+- Relational data model (users, tasks, teams with relationships)
+- ACID transactions for task state changes
+- Support for full-text search on task content
+- Managed hosting available (for small team, limited ops capacity)
+
+## Decision
+Use PostgreSQL with Prisma ORM.
+
+## Alternatives Considered
+
+### MongoDB
+- Pros: Flexible schema, easy to start with
+- Cons: Our data is inherently relational; would need to manage relationships manually
+- Rejected: Relational data in a document store leads to complex joins or data duplication
+
+### SQLite
+- Pros: Zero configuration, embedded, fast for reads
+- Cons: Limited concurrent write support, no managed hosting for production
+- Rejected: Not suitable for multi-user web application in production
+
+### MySQL
+- Pros: Mature, widely supported
+- Cons: PostgreSQL has better JSON support, full-text search, and ecosystem tooling
+- Rejected: PostgreSQL is the better fit for our feature requirements
+
+## Consequences
+- Prisma provides type-safe database access and migration management
+- We can use PostgreSQL's full-text search instead of adding Elasticsearch
+- Team needs PostgreSQL knowledge (standard skill, low risk)
+- Hosting on managed service (Supabase, Neon, or RDS)
+```
+
+### ADR Lifecycle
+
+```
+PROPOSED → ACCEPTED → (SUPERSEDED or DEPRECATED)
+```
+
+- **Don't delete old ADRs.** They capture historical context.
+- When a decision changes, write a new ADR that references and supersedes the old one.
+
+## Inline Documentation
+
+### When to Comment
+
+Comment the *why*, not the *what*:
+
+```typescript
+// BAD: Restates the code
+// Increment counter by 1
+counter += 1;
+
+// GOOD: Explains non-obvious intent
+// Rate limit uses a sliding window — reset counter at window boundary,
+// not on a fixed schedule, to prevent burst attacks at window edges
+if (now - windowStart > WINDOW_SIZE_MS) {
+  counter = 0;
+  windowStart = now;
+}
+```
+
+### When NOT to Comment
+
+```typescript
+// Don't comment self-explanatory code
+function calculateTotal(items: CartItem[]): number {
+  return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
+}
+
+// Don't leave TODO comments for things you should just do now
+// TODO: add error handling  ← Just add it
+
+// Don't leave commented-out code
+// const oldImplementation = () => { ... }  ← Delete it, git has history
+```
+
+### Document Known Gotchas
+
+```typescript
+/**
+ * IMPORTANT: This function must be called before the first render.
+ * If called after hydration, it causes a flash of unstyled content
+ * because the theme context isn't available during SSR.
+ *
+ * See ADR-003 for the full design rationale.
+ */
+export function initializeTheme(theme: Theme): void {
+  // ...
+}
+```
+
+## API Documentation
+
+For public APIs (REST, GraphQL, library interfaces):
+
+### 🔴 CHECKPOINT · Public API Documentation Gate
+
+🛑 STOP before publishing API docs when the docs would define or imply new public behavior, compatibility promises, auth requirements, error codes, rate limits, or versioning policy that the implementation or owner has not confirmed.
+
+Document the implemented contract exactly. If code, tests, OpenAPI schemas, and existing docs disagree, resolve the conflict before updating user-facing docs.
+
+### Inline with Types (Preferred for TypeScript)
+
+```typescript
+/**
+ * Creates a new task.
+ *
+ * @param input - Task creation data (title required, description optional)
+ * @returns The created task with server-generated ID and timestamps
+ * @throws {ValidationError} If title is empty or exceeds 200 characters
+ * @throws {AuthenticationError} If the user is not authenticated
+ *
+ * @example
+ * const task = await createTask({ title: 'Buy groceries' });
+ * console.log(task.id); // "task_abc123"
+ */
+export async function createTask(input: CreateTaskInput): Promise<Task> {
+  // ...
+}
+```
+
+### OpenAPI / Swagger for REST APIs
+
+```yaml
+paths:
+  /api/tasks:
+    post:
+      summary: Create a task
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/CreateTaskInput'
+      responses:
+        '201':
+          description: Task created
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/Task'
+        '422':
+          description: Validation error
+```
+
+## README Structure
+
+Every project should have a README that covers:
+
+```markdown
+# Project Name
+
+One-paragraph description of what this project does.
+
+## Quick Start
+1. Clone the repo
+2. Install dependencies: `npm install`
+3. Set up environment: `cp .env.example .env`
+4. Run the dev server: `npm run dev`
+
+## Commands
+| Command | Description |
+|---------|-------------|
+| `npm run dev` | Start development server |
+| `npm test` | Run tests |
+| `npm run build` | Production build |
+| `npm run lint` | Run linter |
+
+## Architecture
+Brief overview of the project structure and key design decisions.
+Link to ADRs for details.
+
+## Contributing
+How to contribute, coding standards, PR process.
+```
+
+## Domain Glossary and CONTEXT.md
+
+Use `CONTEXT.md` for shared domain language:
+- canonical terms
+- meanings understood by domain experts
+- boundaries between similar concepts
+- terms that reduce repeated explanation
+
+Do not put implementation details in `CONTEXT.md` unless they are part of the domain language.
+
+When terms conflict between user language, docs, and code, surface the mismatch before writing new docs. Prefer one canonical term and record aliases only when they help readers map old language to current language.
+
+## Documentation Conflict Fallbacks
+
+| Trigger | First response | If still unresolved |
+|---|---|---|
+| Existing docs conflict with code or tests | Treat code/tests as evidence and label docs as stale | Ask the owner which source is authoritative before editing |
+| Two docs make incompatible claims | Identify both paths and the exact conflicting statements | Update only after the canonical source is confirmed |
+| Public API behavior is unclear | Inspect implementation, schemas, tests, and release notes | Stop; do not create compatibility promises from inference |
+| ADR rationale is missing | Record known context and alternatives as `Proposed` or `Draft` | Ask decision makers for the missing rationale |
+| A doc update would require product or architecture decisions | Separate the decision from the documentation task | Do not decide by writing docs |
+| The requested doc would expose secrets or internal-only data | Remove sensitive content and document safe operational guidance | Escalate instead of publishing the unsafe detail |
+
+## Changelog Maintenance
+
+For shipped features:
+
+```markdown
+# Changelog
+
+## [1.2.0] - 2025-01-20
+### Added
+- Task sharing: users can share tasks with team members (#123)
+- Email notifications for task assignments (#124)
+
+### Fixed
+- Duplicate tasks appearing when rapidly clicking create button (#125)
+
+### Changed
+- Task list now loads 50 items per page (was 20) for better UX (#126)
+```
+
+## Documentation for Agents
+
+Special consideration for AI agent context:
+
+- **CLAUDE.md / rules files** — Document project conventions so agents follow them
+- **Spec files** — Keep specs updated so agents build the right thing
+- **ADRs** — Help agents understand why past decisions were made (prevents re-deciding)
+- **Inline gotchas** — Prevent agents from falling into known traps
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "The code is self-documenting" | Code shows what. It doesn't show why, what alternatives were rejected, or what constraints apply. |
+| "We'll write docs when the API stabilizes" | APIs stabilize faster when you document them. The doc is the first test of the design. |
+| "Nobody reads docs" | Agents do. Future engineers do. Your 3-months-later self does. |
+| "ADRs are overhead" | A 10-minute ADR prevents a 2-hour debate about the same decision six months later. |
+| "Comments get outdated" | Comments on *why* are stable. Comments on *what* get outdated — that's why you only write the former. |
+
+## Red Flags
+
+- Architectural decisions with no written rationale
+- Public APIs with no documentation or types
+- README that doesn't explain how to run the project
+- Commented-out code instead of deletion
+- TODO comments that have been there for weeks
+- No ADRs in a project with significant architectural choices
+- Documentation that restates the code instead of explaining intent
+
+## Verification
+
+For the selected documentation artifact:
+
+- [ ] Claims are anchored to current source/contract evidence
+- [ ] The requested audience, decision, and affected behavior are covered
+- [ ] Conflicts and stale or `Unverified` content remain explicit
+- [ ] The canonical owner selects the smallest freshness/structure check for this artifact

package/skills/e2e-artifact-handling/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: e2e-artifact-handling
+description: E2E artifact handling routing. Use when traces, videos, screenshots, reports, or failure bundles need controlled repository-local placement; do not use for simple unit tests or production-mutating E2E flows.
+---
+
+# E2E Artifact Handling
+
+Use this skill to define one bounded E2E evidence-collection/packaging need. ROSE may assign it to one fresh `e2e-artifact-runner` context after the delegation gate; this skill does not dispatch or invoke another process skill.
+
+## Trigger
+
+- E2E command needs trace/video/screenshot/report/failure-bundle evidence.
+- A failing browser flow needs artifacts for ROSE review.
+- User asks to preserve test artifacts from an E2E run.
+
+## Required Safety Gate
+
+- Use localhost, fixtures, or explicitly approved non-production/read-only targets.
+- Require repository-local artifact placement before writing user-visible screenshots, traces, videos, reports, or bundles.
+- Do not create new `tests/e2e/`, report, trace, screenshot, or golden directories without placement approval.
+- Redact or avoid artifacts containing secrets, cookies, tokens, credentials, or private user data.
+
+## Near Misses
+
+- Browser QA without durable artifacts, test design/unit/integration verification, or coverage review are different primary intents; return the exact mismatch to ROSE.
+
+## Required Routing
+
+- Canonical owner: ROSE/`aili-delivery-flow`; direct artifact handling is preferred when no specialist context is needed.
+- Optional agent: one fresh, terminal `e2e-artifact-runner` assignment after a new benefit decision; no resume, automatic retry, or final-verdict ownership.