@rosetears/aili-pi 0.1.0

package/skills/shipping-and-launch/SKILL.md

@@ -0,0 +1,334 @@
+---
+name: shipping-and-launch
+description: Prepare an explicit production launch, staged rollout, launch-monitoring, or rollback plan; do not trigger from AILI SHIP, implementation completion, packaging, review, or release wording that lacks a concrete launch/rollout target.
+---
+
+# Shipping and Launch
+
+## Overview
+
+Ship with confidence. The goal is not just to deploy — it's to deploy safely, with monitoring in place, a rollback plan ready, and a clear understanding of what success looks like. Every launch should be reversible, observable, and incremental.
+
+## When to Use
+
+- Deploying a feature to production for the first time
+- Releasing a significant change to users
+- Migrating data or infrastructure
+- Opening a beta or early access program
+- Explicitly planning monitoring, rollout thresholds, launch ownership, or rollback for a named release
+
+Near misses: `/ship` closeout, preparing a package/PR, ordinary deployment discussion, or completing implementation does not select this skill without concrete launch/rollout intent.
+
+ROSE/`aili-delivery-flow` owns lifecycle SHIP, material decisions, exact external/Git/release/deployment approvals, and verification. This skill performs one bounded launch-planning loop and returns `complete`, `need-user`, `need-evidence`, `material-delta`, `blocked`, or `Unverified`. It does not invoke review, security, performance, documentation, deployment, or another process skill. Checklists are risk prompts, not automatic suites or second readiness authority; canonical claim-matched verification wins.
+
+## The Pre-Launch Checklist
+
+Apply only rows relevant to the accepted launch claim and current project. Do not automatically run every test/review/security/performance/accessibility lane.
+
+### Code Quality
+
+- [ ] Claim-matched tests selected by the canonical owner pass
+- [ ] Build succeeds with no warnings
+- [ ] Lint and type checking pass
+- [ ] Code reviewed and approved
+- [ ] No TODO comments that should be resolved before launch
+- [ ] No `console.log` debugging statements in production code
+- [ ] Error handling covers expected failure modes
+
+### Security
+
+- [ ] No secrets in code or version control
+- [ ] `npm audit` shows no critical or high vulnerabilities
+- [ ] Input validation on all user-facing endpoints
+- [ ] Authentication and authorization checks in place
+- [ ] Security headers configured (CSP, HSTS, etc.)
+- [ ] Rate limiting on authentication endpoints
+- [ ] CORS configured to specific origins (not wildcard)
+
+### Performance
+
+- [ ] Core Web Vitals within "Good" thresholds
+- [ ] No N+1 queries in critical paths
+- [ ] Images optimized (compression, responsive sizes, lazy loading)
+- [ ] Bundle size within budget
+- [ ] Database queries have appropriate indexes
+- [ ] Caching configured for static assets and repeated queries
+
+### Accessibility
+
+- [ ] Keyboard navigation works for all interactive elements
+- [ ] Screen reader can convey page content and structure
+- [ ] Color contrast meets WCAG 2.1 AA (4.5:1 for text)
+- [ ] Focus management correct for modals and dynamic content
+- [ ] Error messages are descriptive and associated with form fields
+- [ ] No accessibility warnings in axe-core or Lighthouse
+
+### Infrastructure
+
+- [ ] Environment variables set in production
+- [ ] Database migrations applied (or ready to apply)
+- [ ] DNS and SSL configured
+- [ ] CDN configured for static assets
+- [ ] Logging and error reporting configured
+- [ ] Health check endpoint exists and responds
+
+### Documentation
+
+- [ ] README updated with any new setup requirements
+- [ ] API documentation current
+- [ ] ADRs written for any architectural decisions
+- [ ] Changelog updated
+- [ ] User-facing documentation updated (if applicable)
+
+## Feature Flag Strategy
+
+Ship behind feature flags to decouple deployment from release:
+
+```typescript
+// Feature flag check
+const flags = await getFeatureFlags(userId);
+
+if (flags.taskSharing) {
+  // New feature: task sharing
+  return <TaskSharingPanel task={task} />;
+}
+
+// Default: existing behavior
+return null;
+```
+
+**Feature flag lifecycle:**
+
+```
+1. DEPLOY with flag OFF     → Code is in production but inactive
+2. ENABLE for team/beta     → Internal testing in production environment
+3. GRADUAL ROLLOUT          → 5% → 25% → 50% → 100% of users
+4. MONITOR at each stage    → Watch error rates, performance, user feedback
+5. CLEAN UP                 → Remove flag and dead code path after full rollout
+```
+
+**Rules:**
+- Every feature flag has an owner and an expiration date
+- Clean up flags within 2 weeks of full rollout
+- Don't nest feature flags (creates exponential combinations)
+- Test both flag states (on and off) in CI
+
+## Staged Rollout
+
+### The Rollout Sequence
+
+```
+1. DEPLOY to staging
+   └── Run only affected integration/smoke checks required by the launch claim
+   └── Check critical flows when they are in scope
+
+2. DEPLOY to production (feature flag OFF)
+   └── Verify deployment succeeded (health check)
+   └── Check error monitoring (no new errors)
+
+3. ENABLE for team (flag ON for internal users)
+   └── Team uses the feature in production
+   └── 24-hour monitoring window
+
+4. CANARY rollout (flag ON for 5% of users)
+   └── Monitor error rates, latency, user behavior
+   └── Compare metrics: canary vs. baseline
+   └── 24-48 hour monitoring window
+   └── Advance only if all thresholds pass (see table below)
+
+5. GRADUAL increase (25% -> 50% -> 100%)
+   └── Same monitoring at each step
+   └── Ability to roll back to previous percentage at any point
+
+6. FULL rollout (flag ON for all users)
+   └── Monitor for 1 week
+   └── Clean up feature flag
+```
+
+### Rollout Decision Thresholds
+
+Use these thresholds to decide whether to advance, hold, or roll back at each stage:
+
+| Metric | Advance (green) | Hold and investigate (yellow) | Roll back (red) |
+|--------|-----------------|-------------------------------|-----------------|
+| Error rate | Within 10% of baseline | 10-100% above baseline | >2x baseline |
+| P95 latency | Within 20% of baseline | 20-50% above baseline | >50% above baseline |
+| Client JS errors | No new error types | New errors at <0.1% of sessions | New errors at >0.1% of sessions |
+| Business metrics | Neutral or positive | Decline <5% (may be noise) | Decline >5% |
+
+### 🔴 CHECKPOINT / 🛑 STOP: Deploy Gate
+
+Do not execute a deployment without exact operation approval. For a requested readiness plan, resolve only the applicable launch-owner evidence:
+
+- production owner, monitoring owner, and rollback owner are named
+- health check, error-rate dashboard, latency dashboard, and critical-flow smoke test are ready
+- rollback trigger thresholds and exact rollback command/path are documented
+- the user or release owner has approved the launch window
+
+If any item is missing, stop and return `BLOCKED_LAUNCH_READINESS` with the missing evidence instead of continuing.
+
+### When to Roll Back
+
+Roll back immediately if:
+- Error rate increases by more than 2x baseline
+- P95 latency increases by more than 50%
+- User-reported issues spike
+- Data integrity issues detected
+- Security vulnerability discovered
+
+## Monitoring and Observability
+
+### What to Monitor
+
+```
+Application metrics:
+├── Error rate (total and by endpoint)
+├── Response time (p50, p95, p99)
+├── Request volume
+├── Active users
+└── Key business metrics (conversion, engagement)
+
+Infrastructure metrics:
+├── CPU and memory utilization
+├── Database connection pool usage
+├── Disk space
+├── Network latency
+└── Queue depth (if applicable)
+
+Client metrics:
+├── Core Web Vitals (LCP, INP, CLS)
+├── JavaScript errors
+├── API error rates from client perspective
+└── Page load time
+```
+
+### Error Reporting
+
+```typescript
+// Set up error boundary with reporting
+class ErrorBoundary extends React.Component {
+  componentDidCatch(error: Error, info: React.ErrorInfo) {
+    // Report to error tracking service
+    reportError(error, {
+      componentStack: info.componentStack,
+      userId: getCurrentUser()?.id,
+      page: window.location.pathname,
+    });
+  }
+
+  render() {
+    if (this.state.hasError) {
+      return <ErrorFallback onRetry={() => this.setState({ hasError: false })} />;
+    }
+    return this.props.children;
+  }
+}
+
+// Server-side error reporting
+app.use((err: Error, req: Request, res: Response, next: NextFunction) => {
+  reportError(err, {
+    method: req.method,
+    url: req.url,
+    userId: req.user?.id,
+  });
+
+  // Don't expose internals to users
+  res.status(500).json({
+    error: { code: 'INTERNAL_ERROR', message: 'Something went wrong' },
+  });
+});
+```
+
+### Post-Launch Verification
+
+In the first hour after launch:
+
+```
+1. Check health endpoint returns 200
+2. Check error monitoring dashboard (no new error types)
+3. Check latency dashboard (no regression)
+4. Test the critical user flow manually
+5. Verify logs are flowing and readable
+6. Confirm rollback mechanism works (dry run if possible)
+```
+
+## Rollback Strategy
+
+Every deployment needs a rollback plan before it happens:
+
+### 🔴 CHECKPOINT / 🛑 STOP: Rollback Gate
+
+Do not start or claim a rollback is ready until the rollback path is known and evidence-backed. If the rollback command, feature-flag kill switch, database rollback path, or verification owner is unknown, stop and ask for the missing release-specific detail.
+
+```markdown
+## Rollback Plan for [Feature/Release]
+
+### Trigger Conditions
+- Error rate > 2x baseline
+- P95 latency > [X]ms
+- User reports of [specific issue]
+
+### Rollback Steps
+1. Disable feature flag (if applicable)
+   OR
+1. Deploy previous version: `git revert <commit> && git push`
+2. Verify rollback: health check, error monitoring
+3. Communicate: notify team of rollback
+
+### Database Considerations
+- Migration [X] has a rollback: `npx prisma migrate rollback`
+- Data inserted by new feature: [preserved / cleaned up]
+
+### Time to Rollback
+- Feature flag: < 1 minute
+- Redeploy previous version: < 5 minutes
+- Database rollback: < 15 minutes
+```
+## Missing Evidence Fallbacks
+
+| Trigger | First action | If still unresolved |
+|---|---|---|
+| Monitoring dashboard unavailable | Use health check, logs, and error tracker as temporary evidence | Hold rollout; do not increase exposure |
+| Rollback path untested | Run a dry run in staging or confirm the exact production-safe command | Do not deploy until rollback readiness is confirmed |
+| Security, performance, or accessibility evidence missing | Use the relevant checklist sections in this file as the source of truth | Block launch or mark the launch risk explicitly for release-owner approval |
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "It works in staging, it'll work in production" | Production has different data, traffic patterns, and edge cases. Monitor after deploy. |
+| "We don't need feature flags for this" | Every feature benefits from a kill switch. Even "simple" changes can break things. |
+| "Monitoring is overhead" | Not having monitoring means you discover problems from user complaints instead of dashboards. |
+| "We'll add monitoring later" | Add it before launch. You can't debug what you can't see. |
+| "Rolling back is admitting failure" | Rolling back is responsible engineering. Shipping a broken feature is the failure. |
+
+## Red Flags
+
+- Deploying without a rollback plan
+- No monitoring or error reporting in production
+- Big-bang releases (everything at once, no staging)
+- Feature flags with no expiration or owner
+- No one monitoring the deploy for the first hour
+- Production environment configuration done by memory, not code
+- "It's Friday afternoon, let's ship it"
+
+## Verification
+
+The canonical lifecycle/ordinary-task owner selects the smallest fresh deploy, monitoring, health-check, or rollback evidence supporting the exact claim; this skill creates no additional completion gate.
+
+Before deploying:
+
+- [ ] Pre-launch checklist completed (all sections green)
+- [ ] Feature flag configured (if applicable)
+- [ ] Rollback plan documented
+- [ ] Monitoring dashboards set up
+- [ ] Team notified of deployment
+
+After deploying:
+
+- [ ] Health check returns 200
+- [ ] Error rate is normal
+- [ ] Latency is normal
+- [ ] Critical user flow works
+- [ ] Logs are flowing
+- [ ] Rollback tested or verified ready

package/skills/silent-failure-hunting/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: silent-failure-hunting
+description: Silent failure hunting routing. Use when a change might pass while skipping work, swallowing errors, losing evidence, weakening gates, or reporting false success; do not use for broad code review.
+---
+
+# Silent Failure Hunting
+
+Use this skill for one bounded read-only false-success question. ROSE may assign it to one fresh `silent-failure-reviewer` context after the delegation gate; this skill does not dispatch or invoke another process skill.
+
+## Trigger
+
+- Installer, packaging, verification, review, memory, artifact, CLI, or workflow gate changed.
+- Logs/reports may hide skipped checks, stale evidence, partial writes, or ignored exit codes.
+- Acceptance depends on distinguishing PASS, partial, skipped, blocked, and `Unverified`.
+
+## Near Misses
+
+- Security exploitability, coverage adequacy, or executing a failing command are different primary intents; return the exact mismatch to ROSE.
+
+## Required Routing
+
+- Canonical owner: ROSE/`aili-delivery-flow`; direct read-only inspection is the default.
+- Optional agent: one fresh, terminal `silent-failure-reviewer` assignment after a new benefit decision.
+- Read-only; return fix/negative-test needs to ROSE and stop without retrying or owning the final verdict.

package/skills/source-driven-development/SKILL.md

@@ -0,0 +1,223 @@
+---
+name: source-driven-development
+description: Resolve one exact official/current documentation gap when the user requests source verification or a version-sensitive API/SDK/provider/framework question can materially change the current decision; do not trigger for every implementation decision, ordinary framework code, local business logic, or broad research.
+---
+
+# Source-Driven Development
+
+## Overview
+
+Use a narrow official source to resolve the named version-sensitive question. This is evidence for the current primary loop, not a second implementation or acceptance workflow.
+
+## When to Use
+
+- The user explicitly asks to verify or cite current official/API behavior.
+- One unresolved version-sensitive API, SDK, provider, framework, packaging, runtime, platform, or changelog question can materially change the current design or implementation.
+- Existing official docs and installed types/source conflict on the exact behavior being used.
+
+**When NOT to use:**
+
+- Correctness does not depend on a specific version (renaming variables, fixing typos, moving files)
+- Pure logic that works the same across all versions (loops, conditionals, data structures)
+- The user explicitly wants speed over verification ("just do it quickly") and the task does not involve version-sensitive framework/API/library behavior
+- The task merely uses a library/framework and local evidence already establishes the needed API.
+- The user asks for mature-project prior art, local repository facts, implementation, or review rather than one official-source answer.
+
+## Planning Evidence Gate Ownership
+
+ROSE/`aili-delivery-flow` owns lifecycle timing, local evidence, material questions, approvals, implementation, and verification. This skill performs one bounded lookup, cites the exact source, and returns `complete`, `need-user`, `need-evidence`, `material-delta`, `blocked`, or `Unverified`. It must not invoke local/prior-art/requirements/test-plan/review skills or turn a source summary into scheme acceptance. Use external web or Context7 only when current policy allows the exact lookup; never send secrets or sensitive context. Lifecycle approval and verification rules win conflicts.
+
+## The Process
+
+```
+DETECT ──→ FETCH ──→ RETURN ──→ CITE
+  │          │           │            │
+  ▼          ▼           ▼            ▼
+ What       Get the    Return the   Show the
+ gap?       relevant   bounded      exact source
+            docs       answer
+```
+
+### Step 1: Detect Stack and Versions
+
+Read the project's dependency file to identify exact versions:
+
+```
+package.json    → Node/React/Vue/Angular/Svelte
+composer.json   → PHP/Symfony/Laravel
+requirements.txt / pyproject.toml → Python/Django/Flask
+go.mod          → Go
+Cargo.toml      → Rust
+Gemfile         → Ruby/Rails
+```
+
+State what you found explicitly:
+
+```
+STACK DETECTED:
+- React 19.1.0 (from package.json)
+- Vite 6.2.0
+- Tailwind CSS 4.0.3
+→ Fetching official docs for the relevant patterns.
+```
+
+If the version is missing or materially ambiguous, return that exact decision/evidence gap to ROSE. Do not guess or ask a second workflow-owned question here.
+
+### Step 2: Fetch Official Documentation
+
+Fetch the specific documentation page for the feature you're implementing. Not the homepage, not the full docs — the relevant page.
+
+For library/API documentation, setup commands, framework examples, provider behavior such as DeepSeek APIs, SDK references, packaging/runtime/platform constraints, changelog-sensitive behavior, or version-sensitive code, prefer Context7 when it is installed in the current OpenCode environment. Do not require the user to manually say "use context7" each time. Do not assume Context7 is installed; if it is unavailable, fall back to official docs, package documentation, and source references. Do not add or rely on a repository-local Context7 skill.
+
+Speed requests may reduce citation verbosity, but they do not remove the required source/evidence check for version-sensitive framework, API, or library behavior. If correctness depends on the detected version, verify the source first and then summarize citations briefly.
+
+**Source-fetch fallback ladder:**
+
+| Trigger | Next source | If still unavailable |
+|---|---|---|
+| Context7 is unavailable or has no matching library/version | Fetch the official documentation URL directly | Use the package's official README/changelog/release notes from the upstream repository |
+| Official docs page is unavailable, moved, or lacks the needed pattern | Check official blog, migration guide, API reference, or versioned docs | Mark the pattern `UNVERIFIED` and return the dependent implementation decision to ROSE |
+| Package docs and source disagree | Prefer versioned docs, then inspect installed package types/source for the detected version | Surface the discrepancy as a conflict; do not silently choose |
+| Network/tooling prevents source access | Use only already-present local docs/types/package files | Report `BLOCKED_VERIFICATION` or `NEEDS_REVIEW` for framework-specific code that cannot be sourced |
+
+🔴 CHECKPOINT / 🛑 STOP: If no authoritative source can confirm a version-sensitive API, return `need-user` or `need-evidence` to ROSE before dependent coding. Only ROSE records explicit acceptance of an `UNVERIFIED` implementation.
+
+**Source hierarchy (in order of authority):**
+
+| Priority | Source | Example |
+|----------|--------|---------|
+| 1 | Official documentation | react.dev, docs.djangoproject.com, symfony.com/doc |
+| 2 | Official blog / changelog | react.dev/blog, nextjs.org/blog |
+| 3 | Web standards references | MDN, web.dev, html.spec.whatwg.org |
+| 4 | Browser/runtime compatibility | caniuse.com, node.green |
+
+**Not authoritative — never cite as primary sources:**
+
+- Stack Overflow answers
+- Blog posts or tutorials (even popular ones)
+- AI-generated documentation or summaries
+- Your own training data (that is the whole point — verify it)
+
+**Be precise with what you fetch:**
+
+```
+BAD:  Fetch the React homepage
+GOOD: Fetch react.dev/reference/react/useActionState
+
+BAD:  Search "django authentication best practices"
+GOOD: Fetch docs.djangoproject.com/en/6.0/topics/auth/
+```
+
+After fetching, extract the key patterns and note any deprecation warnings or migration guidance.
+
+When official sources conflict with each other (e.g. a migration guide contradicts the API reference), surface the discrepancy to the user and verify which pattern actually works against the detected version.
+
+### Step 3: Return the Documented Pattern
+
+Return the exact supported pattern and constraints to the primary owner. If implementation is already in scope, ROSE may apply it directly; this skill does not start another implementation loop.
+
+- Use the API signatures from the docs, not from memory
+- If the docs show a new way to do something, use the new way
+- If the docs deprecate a pattern, don't use the deprecated version
+- If the docs don't cover something, flag it as unverified
+
+**When docs conflict with existing project code:**
+
+```
+CONFLICT DETECTED:
+The existing codebase uses useState for form loading state,
+but React 19 docs recommend useActionState for this pattern.
+(Source: react.dev/reference/react/useActionState)
+
+Options:
+A) Use the modern pattern (useActionState) — consistent with current docs
+B) Match existing code (useState) — consistent with codebase
+→ Which approach do you prefer?
+```
+
+Surface the conflict. Don't silently pick one.
+
+🔴 CHECKPOINT / 🛑 STOP: If documented best practice conflicts with existing project conventions, compatibility constraints, or tests, pause with options before editing. The user must choose whether to follow current docs, preserve local patterns, or defer the change.
+
+### Step 4: Cite Your Sources
+
+Every framework-specific pattern gets a citation. The user must be able to verify every decision.
+
+**In code comments:**
+
+```typescript
+// React 19 form handling with useActionState
+// Source: https://react.dev/reference/react/useActionState#usage
+const [state, formAction, isPending] = useActionState(submitOrder, initialState);
+```
+
+**In conversation:**
+
+```
+I'm using useActionState instead of manual useState for the
+form submission state. React 19 replaced the manual
+isPending/setIsPending pattern with this hook.
+
+Source: https://react.dev/blog/2024/12/05/react-19#actions
+"useTransition now supports async functions [...] to handle
+pending states automatically"
+```
+
+**Citation rules:**
+
+- Full URLs, not shortened
+- Prefer deep links with anchors where possible (e.g. `/useActionState#usage` over `/useActionState`) — anchors survive doc restructuring better than top-level pages
+- Quote the relevant passage when it supports a non-obvious decision
+- Include browser/runtime support data when recommending platform features
+- If you cannot find documentation for a pattern, say so explicitly:
+
+```
+UNVERIFIED: I could not find official documentation for this
+pattern. This is based on training data and may be outdated.
+Verify before using in production.
+```
+
+Honesty about what you couldn't verify is more valuable than false confidence.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "I'm confident about this API" | Confidence is not evidence. Training data contains outdated patterns that look correct but break against current versions. Verify. |
+| "Fetching docs wastes tokens" | Hallucinating an API wastes more. The user debugs for an hour, then discovers the function signature changed. One fetch prevents hours of rework. |
+| "The docs won't have what I need" | If the docs don't cover it, that's valuable information — the pattern may not be officially recommended. |
+| "I'll just mention it might be outdated" | A disclaimer doesn't help. Either verify and cite, or clearly flag it as unverified. Hedging is the worst option. |
+| "This is a simple task, no need to check" | Simple tasks with wrong patterns become templates. The user copies your deprecated form handler into ten components before discovering the modern approach exists. |
+
+## Red Flags
+
+- Answering the selected version-sensitive gap without checking the applicable official source
+- Using "I believe" or "I think" about the selected API instead of citing the source
+- Returning a pattern without knowing which applicable version it describes
+- Citing Stack Overflow or blog posts instead of official documentation
+- Using deprecated APIs because they appear in training data
+- Ignoring the current dependency/version evidence when it controls the selected question
+- Returning a non-trivial framework/API conclusion without its source citation
+- Fetching an entire docs site when only one page is relevant
+
+## Do Not Do
+
+- Do not use Stack Overflow, tutorials, AI summaries, or memory as the primary authority for framework-specific code.
+- Do not hide missing docs behind hedging language like "probably" or "should work"; label it `UNVERIFIED`.
+- Do not keep coding through a docs/code conflict without a visible checkpoint and user decision.
+- Do not add a repository-local docs tool or Context7 skill as a workaround for unavailable documentation tooling.
+- Do not cite a source you did not actually read for the detected version or feature.
+
+## Verification
+
+Before returning the bounded source result:
+
+- [ ] The applicable version was identified when the question is version-sensitive
+- [ ] The smallest relevant official/API source was read for the selected gap
+- [ ] Primary authority is official documentation rather than a blog post, tutorial, or training-memory claim
+- [ ] The exact decision/source gap is answered or marked `UNVERIFIED`
+- [ ] Any implementation need is returned to ROSE without an extra scheme approval
+- [ ] Non-trivial decisions include source citations with full URLs
+- [ ] Deprecation/migration guidance was checked when the selected gap involves an API transition
+- [ ] Conflicts between docs and existing code were surfaced to the user
+- [ ] Anything that could not be verified is explicitly flagged as unverified