@codyswann/lisa 2.189.6 → 2.189.8

package/plugins/lisa-copilot/skills/lisa-jsdoc-best-practices/SKILL.md

@@ -0,0 +1,432 @@
+---
+name: lisa-jsdoc-best-practices
+description: Enforces JSDoc documentation standards for this TypeScript project. This skill should be used when writing or reviewing TypeScript code to ensure proper documentation with file preambles, function docs, interface docs, and the critical distinction between documenting "what" vs "why". Use this skill to understand the project's JSDoc ESLint rules and established patterns.
+---
+
+# JSDoc Best Practices
+
+## Overview
+
+This skill defines the JSDoc documentation standards for this project. The core principle is that **documentation should explain "why", not just "what"**. Code already shows what it does—good documentation explains the reasoning, context, and non-obvious details that help developers understand and maintain the code.
+
+## Core Philosophy: Why Over What
+
+### The Problem with "What" Documentation
+
+```typescript
+// Bad: Just restates the code
+/**
+ * Gets the user by ID
+ * @param id - The ID
+ * @returns The user
+ */
+function getUserById(id: string): User { ... }
+```
+
+This documentation adds no value—the function name already tells us it gets a user by ID.
+
+### The Solution: Document "Why"
+
+```typescript
+// Good: Explains context, constraints, and non-obvious behavior
+/**
+ * Retrieves a user by their unique identifier
+ * @param id - The user's UUID (not the legacy numeric ID)
+ * @returns The user if found, null if not found or soft-deleted
+ * @remarks Used by DataLoader for batching - maintains input order
+ */
+function getUserById(id: string): User | null { ... }
+```
+
+This documentation adds value by explaining:
+- What kind of ID (UUID vs legacy)
+- What happens when not found
+- Why this specific implementation exists (DataLoader batching)
+
+## ESLint Enforcement
+
+The project enforces JSDoc through `eslint-plugin-jsdoc` with these rules:
+
+### Required Documentation
+
+| Rule | Setting | What It Enforces |
+|------|---------|------------------|
+| `jsdoc/require-jsdoc` | error | JSDoc on function declarations, interfaces, type aliases, and PascalCase arrow functions |
+| `jsdoc/require-param-description` | error | All `@param` tags must have descriptions |
+| `jsdoc/require-returns-description` | error | All `@returns` tags must have descriptions |
+| `jsdoc/require-property-description` | error | All `@property` tags must have descriptions |
+
+### Allowed Tags
+
+| Rule | Setting | Effect |
+|------|---------|--------|
+| `jsdoc/check-tag-names` | `definedTags: ["remarks"]` | Allows `@remarks` for "why" documentation |
+| `jsdoc/no-types` | off | TypeScript types in JSDoc are optional |
+| `jsdoc/require-param-type` | off | Types come from TypeScript, not JSDoc |
+| `jsdoc/require-returns-type` | off | Types come from TypeScript, not JSDoc |
+
+### What Requires Documentation
+
+Per `jsdoc/require-jsdoc` configuration:
+
+```javascript
+{
+  require: {
+    FunctionDeclaration: true,      // function foo() {}
+    MethodDefinition: false,        // class methods (optional)
+    ClassDeclaration: false,        // classes (optional but recommended)
+    ArrowFunctionExpression: false, // const foo = () => {} (optional)
+    FunctionExpression: false,      // const foo = function() {} (optional)
+  },
+  contexts: [
+    "TSInterfaceDeclaration",       // interface Foo {}
+    "TSTypeAliasDeclaration",       // type Foo = ...
+    // PascalCase arrow functions (React components, factories):
+    "VariableDeclaration[declarations.0.init.type='ArrowFunctionExpression']:has([id.name=/^[A-Z]/])"
+  ]
+}
+```
+
+## Documentation Patterns
+
+### File Preambles
+
+Every file should have a preamble comment at the top:
+
+```typescript
+/**
+ * @file complexity.plugin.ts
+ * @description Apollo Server plugin for query complexity analysis and limiting
+ * @module graphql
+ */
+```
+
+| Tag | Purpose |
+|-----|---------|
+| `@file` | The filename (for navigation and search) |
+| `@description` | What this file provides |
+| `@module` | The feature module this belongs to |
+
+### Service Documentation
+
+```typescript
+/**
+ * Service for managing user accounts
+ * @description Provides CRUD operations for user entities
+ * @remarks
+ * - All methods are idempotent
+ * - Throws NotFoundException for missing resources
+ * - Uses DataLoader batching for bulk operations
+ */
+@Injectable()
+export class UserService { ... }
+```
+
+### Method Documentation
+
+```typescript
+/**
+ * Batch loads entities by IDs (for DataLoader)
+ * @param ids - Array of entity IDs to load
+ * @returns Promise resolving to array of entities in same order as input
+ * @remarks Used by DataLoader for batching - maintains input order
+ */
+async findByIds(ids: readonly string[]): Promise<Entity[]> { ... }
+```
+
+### Interface Documentation
+
+```typescript
+/**
+ * Interface for authentication services
+ * @description Defines the contract for both Cognito and Local auth implementations.
+ * This interface ensures both AuthService (production) and LocalAuthService
+ * (local development) provide the same public API for authentication operations.
+ */
+export interface IAuthService {
+  /**
+   * Initiates the sign-in flow by sending an OTP to the user
+   * @param input - The sign-in input containing the user identifier (phone/email)
+   * @returns A promise resolving to the sign-in result with session and challenge info
+   */
+  signIn(input: SignInInput): Promise<SignInResult>;
+}
+```
+
+### Type/Constant Documentation
+
+```typescript
+/**
+ * Default complexity configuration
+ * @description Tune these values based on your server capacity
+ */
+const COMPLEXITY_CONFIG = {
+  /** Maximum allowed query complexity */
+  maxComplexity: 100,
+  /** Default complexity for fields without explicit complexity */
+  defaultComplexity: 1,
+} as const;
+```
+
+## The @remarks Tag
+
+Use `@remarks` to document the "why" and important context:
+
+### When to Use @remarks
+
+| Use Case | Example |
+|----------|---------|
+| Design decisions | `@remarks Uses closure pattern to cache between Lambda invocations` |
+| Usage constraints | `@remarks Call getLoaders() once per GraphQL request in context factory` |
+| Non-obvious behavior | `@remarks Maintains input order for DataLoader compatibility` |
+| Important caveats | `@remarks All methods are idempotent - safe to retry` |
+| Integration details | `@remarks Connects on module initialization, disconnects on destruction` |
+
+### @remarks Format
+
+Use bullet points for multiple remarks:
+
+```typescript
+/**
+ * Apollo Server plugin that calculates and limits query complexity
+ * @description Prevents expensive queries from overwhelming the server
+ * @remarks
+ * - Uses field extensions estimator for custom complexity values
+ * - Falls back to simple estimator with default complexity of 1
+ * - Rejects queries that exceed the configured maximum complexity
+ */
+```
+
+Use inline for single remarks:
+
+```typescript
+/**
+ * Creates all DataLoader instances for a single request
+ * @returns Object containing all typed DataLoaders
+ * @remarks Called in GraphQL context factory - creates fresh instances per request
+ */
+```
+
+## Parameter Descriptions
+
+### Bad: Restating the Name
+
+```typescript
+/**
+ * @param id - The id
+ * @param name - The name
+ * @param options - The options
+ */
+```
+
+### Good: Adding Value
+
+```typescript
+/**
+ * @param id - The user's UUID (not the legacy numeric ID from v1 API)
+ * @param name - Display name, max 50 characters, sanitized for XSS
+ * @param options - Configuration for the query, see QueryOptions type
+ */
+```
+
+### Parameter Description Guidelines
+
+| Include | Avoid |
+|---------|-------|
+| Valid value ranges | Restating the parameter name |
+| Format requirements | Restating the type |
+| Default behavior | Obvious information |
+| Edge cases | Implementation details |
+| Units (ms, bytes, etc.) | Internal variable names |
+
+## Return Value Descriptions
+
+### Bad: Restating the Type
+
+```typescript
+/**
+ * @returns The user
+ * @returns A promise
+ * @returns The result
+ */
+```
+
+### Good: Explaining Behavior
+
+```typescript
+/**
+ * @returns The user if found, null if not found or soft-deleted
+ * @returns Promise resolving to array of entities in same order as input
+ * @returns Authentication tokens on success, error message on failure
+ */
+```
+
+## Anti-Patterns to Avoid
+
+### Don't Document the Obvious
+
+```typescript
+// Wrong: Adds no value
+/**
+ * Constructor
+ */
+constructor() {}
+
+/**
+ * Gets the name
+ * @returns The name
+ */
+getName(): string { return this.name; }
+```
+
+### Don't Duplicate TypeScript Types
+
+```typescript
+// Wrong: Type is already in signature
+/**
+ * @param id - {string} The user ID
+ * @returns {Promise<User>} The user
+ */
+async getUser(id: string): Promise<User> { ... }
+
+// Correct: Description only, type from TypeScript
+/**
+ * @param id - The user's UUID identifier
+ * @returns The user entity with populated relations
+ */
+async getUser(id: string): Promise<User> { ... }
+```
+
+### Don't Write Implementation Comments
+
+```typescript
+// Wrong: Documents how, not why
+/**
+ * Loops through users and filters by active status
+ */
+const activeUsers = users.filter(u => u.active);
+
+// Correct: Self-documenting code needs no comment
+// If explanation is needed, explain WHY:
+// Active users are filtered first to avoid unnecessary permission checks
+const activeUsers = users.filter(u => u.active);
+```
+
+## Escaping @ Symbols in JSDoc
+
+When documenting code that contains TypeScript/NestJS decorators (like `@Injectable()`, `@Processor('queue-name')`), JSDoc will interpret the `@` as a tag marker. This causes lint errors because JSDoc sees `@Processor('qpr-v2')` as a single unknown tag name (including the parentheses and arguments).
+
+**The problem:** Adding decorator names to `definedTags` doesn't help because JSDoc parses the entire string `@Processor('qpr-v2')` as the tag name, not just `@Processor`.
+
+### Solution 1: Backticks in Prose
+
+When mentioning decorators in description text, wrap them in backticks:
+
+```typescript
+/**
+ * Queue processor for QPR calculations
+ * @description Handles jobs from the `@Processor('qpr-v2')` queue
+ * @remarks Uses `@Injectable()` scope for request isolation
+ */
+```
+
+### Solution 2: Escape in @example Blocks
+
+In `@example` blocks, use fenced code blocks and escape `@` as `\@`:
+
+```typescript
+/**
+ * Creates a queue processor
+ * @example
+ * ```typescript
+ * \@Processor('my-queue')
+ * export class MyProcessor {
+ *   \@Process()
+ *   async handle(job: Job) { ... }
+ * }
+ * ```
+ */
+```
+
+### Quick Reference for Escaping
+
+| Context | Approach | Example |
+|---------|----------|---------|
+| Prose/description | Wrap in backticks | `` `@Injectable()` `` |
+| @example block | Escape with backslash | `\@Processor('name')` |
+| Code comments | No escaping needed | `// Uses @Injectable` |
+
+## Quick Reference
+
+### Required Structure for Services
+
+```typescript
+/**
+ * @file feature.service.ts
+ * @description Service providing feature functionality
+ * @module feature
+ */
+
+/**
+ * Service for feature operations
+ * @description Brief description of what this service handles
+ * @remarks
+ * - Important architectural decisions
+ * - Usage patterns or constraints
+ */
+@Injectable()
+export class FeatureService {
+  /**
+   * Brief description of what this method does
+   * @param paramName - What this parameter represents and any constraints
+   * @returns What is returned and under what conditions
+   * @remarks Any non-obvious behavior or usage notes
+   */
+  methodName(paramName: Type): ReturnType { ... }
+}
+```
+
+### Required Structure for Interfaces
+
+```typescript
+/**
+ * Interface for feature operations
+ * @description Explains the contract this interface defines
+ */
+export interface IFeature {
+  /**
+   * Method description
+   * @param param - Parameter description with constraints
+   * @returns Return description with conditions
+   */
+  method(param: Type): ReturnType;
+}
+```
+
+### Required Structure for Types
+
+```typescript
+/**
+ * Represents a feature configuration
+ * @description Used to configure feature behavior at initialization
+ */
+export type FeatureConfig = {
+  /** Maximum retry attempts before failing */
+  maxRetries: number;
+  /** Timeout in milliseconds */
+  timeoutMs: number;
+};
+```
+
+## Verification Checklist
+
+Before committing code, verify:
+
+1. **File preamble exists**: `@file`, `@description`, `@module`
+2. **Function declarations have JSDoc**: Required by ESLint
+3. **Interfaces have JSDoc**: Required by ESLint
+4. **Type aliases have JSDoc**: Required by ESLint
+5. **Parameters have meaningful descriptions**: Not just restating the name
+6. **Returns have meaningful descriptions**: Explain conditions and edge cases
+7. **@remarks used for "why"**: Design decisions, constraints, non-obvious behavior
+8. **No TypeScript types in JSDoc**: Types come from the signature

package/plugins/lisa-copilot/skills/lisa-linear-access/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: lisa-linear-access
+description: "Vendor-neutral access layer for Linear. Linear skills MUST delegate through this skill rather than calling Linear MCP tools or Linear GraphQL directly. Resolves Linear MCP first when authenticated, then falls back to LINEAR_API_KEY + Linear GraphQL in headless environments."
+allowed-tools: ["Bash", "Read", "Skill"]
+---
+
+# Linear Access: $ARGUMENTS
+
+Single chokepoint for Linear operations. Caller skills (`linear-*`) MUST go
+through this skill. They MUST NOT call `mcp__linear-server__*` tools directly or
+curl `https://api.linear.app/graphql` themselves.
+
+## Invocation Contract
+
+```text
+operation: list-teams [query:<KEY>]
+operation: get-team id:<ID>
+operation: list-projects [team:<KEY>] [label:<NAME>] [state:<arr>]
+operation: get-project id:<ID>
+operation: save-project payload:{...}
+operation: list-issues [team:<ID>] [project:<ID>] [label:<NAME>] [state_type:<arr>]
+operation: get-issue id:<ID>
+operation: save-issue payload:{...}
+operation: list-comments issue_id:<ID>
+operation: save-comment issue_id:<ID> body:"..."
+operation: list-issue-labels [team:<ID>]
+operation: create-issue-label payload:{...}
+operation: list-project-labels
+operation: create-project-label payload:{...}
+operation: list-documents project_id:<ID>
+operation: get-document id:<ID>
+```
+
+Return parsed JSON in a `<result>` block. On failure, prefix the message with
+`Error:` and include the failing operation name.
+
+## Substrate Selection
+
+Read config:
+
+```bash
+WORKSPACE=$(jq -r '.linear.workspace // empty' .lisa.config.json 2>/dev/null)
+TEAM_KEY=$(jq -r '.linear.teamKey // empty' .lisa.config.json 2>/dev/null)
+```
+
+Probe in order:
+
+1. Linear MCP, if `mcp__linear-server__list_teams` is available and can list the
+   configured workspace/team.
+2. `LINEAR_API_KEY` with Linear GraphQL (`https://api.linear.app/graphql`).
+
+The Linear GraphQL docs support personal API keys for scripts and authenticate
+with an `Authorization: <API_KEY>` header. Treat `LINEAR_API_KEY` as the
+headless substrate. If neither tier works, fail with:
+
+```text
+Error: no Linear access substrate available. Authenticate the Linear MCP or set LINEAR_API_KEY.
+```
+
+## GraphQL Adapter
+
+All GraphQL calls use:
+
+```bash
+linear_graphql() {
+  local query="$1"
+  local variables="${2:-{}}"
+  [ -n "$LINEAR_API_KEY" ] || {
+    echo "Error: LINEAR_API_KEY is not set." >&2
+    return 1
+  }
+  jq -n --arg query "$query" --argjson variables "$variables" \
+    '{query:$query, variables:$variables}' |
+    curl -sS -X POST "https://api.linear.app/graphql" \
+      -H "Content-Type: application/json" \
+      -H "Authorization: '"$LINEAR_API_KEY"'" \
+      --data-binary @-
+}
+```
+
+Map operation names to Linear GraphQL queries/mutations in this access skill.
+Consumers pass business-shaped arguments only; they do not embed GraphQL.
+
+## Invariants
+
+- MCP is preferred when it is present and already authenticated.
+- GraphQL fallback runs only when `LINEAR_API_KEY` is present.
+- Missing MCP plus missing token is a hard failure naming `LINEAR_API_KEY`.
+- Mutations send only the fields being changed, matching existing Linear skill
+  guidance that `save_*` style updates should not clobber unrelated fields.

package/plugins/lisa-copilot/skills/lisa-linear-add-journey/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: lisa-linear-add-journey
+description: "Add a Validation Journey section to an existing Linear Issue by analyzing the change type and generating appropriate verification steps with evidence markers. Linear counterpart of lisa-jira-add-journey."
+allowed-tools: ["Bash", "Read", "Glob", "Grep", "Skill"]
+---
+
+# Add Validation Journey to Existing Linear Issue
+
+Read an existing Linear Issue, analyze the change type, and append a Validation Journey section to the description with appropriate verification steps based on the project's verification patterns.
+
+This skill is the destination of the `lisa-tracker-add-journey` shim when `tracker = "linear"`.
+
+## Configuration
+
+Reads `linear.workspace`, `linear.teamKey` from `.lisa.config.json` (with `.local` override).
+
+## Arguments
+
+`$ARGUMENTS`: `<IDENTIFIER>` — Linear Issue identifier (e.g. `ENG-123`).
+
+## Workflow
+
+### Step 1: Read the Issue
+
+Fetch via `lisa-linear-access operation: get-issue` and extract: title, description (markdown), labels, project, parent, attachments.
+
+### Step 2: Check for Existing Journey
+
+If the description already contains a `## Validation Journey` section, report and stop — never overwrite an existing journey without explicit instruction.
+
+### Step 3: Analyze the Change Type
+
+Examine the description, acceptance criteria, and codebase to determine the change type:
+
+1. **API/GraphQL** — New or modified endpoints, request/response schemas
+2. **Database migration** — Schema changes, new tables/columns, indexes
+3. **Background job/queue** — New job processors, queue consumers, event handlers
+4. **Library/utility** — Exported functions, shared modules, npm package changes
+5. **Security fix** — Auth, authorization, input validation, OWASP vulnerabilities
+6. **Authentication/authorization** — Role-based access, session management, tokens
+7. **UI/frontend** — Components, flows, browser-driven verification
+
+Use Explore agents or read the codebase to understand which files are affected and what verification approach is appropriate.
+
+### Step 4: Map Change Type to Verification Pattern
+
+| Change Type | Verification Approach |
+|---|---|
+| API/GraphQL | curl commands verifying endpoints, status codes, response schemas |
+| Database migration | Migration execution + schema verification + rollback check |
+| Background job/queue | Enqueue + process + state change verification |
+| Library/utility | Test execution + build verification + export check |
+| Security fix | Exploit reproduction pre-fix + exploit failure post-fix |
+| Auth/authz | Multi-role verification with explicit status codes |
+| UI/frontend | Playwright browser flow + visual evidence |
+
+### Step 5: Draft the Validation Journey (markdown)
+
+Linear descriptions are markdown. Use `##` and `###` headings — not Jira wiki markup.
+
+```markdown
+## Validation Journey
+
+### Prerequisites
+- List required services, database, env vars
+
+### Steps
+1. Verify current state before changes
+2. Apply the change
+3. Verify expected new state [EVIDENCE: state-name]
+4. Test error/edge cases [EVIDENCE: error-case]
+5. Verify rollback if applicable [EVIDENCE: rollback]
+
+### Assertions
+- Describe what must be true after verification
+```
+
+### Guidelines for Drafting
+
+1. **2–5 evidence markers** — Focus on proving the change works and handles errors.
+2. **Concrete, runnable steps** — `Run \`curl -s localhost:3000/health | jq .status\`` not "Check the endpoint".
+3. **Include environment setup** — Database connection, running services, env vars.
+4. **Evidence names in kebab-case** — `api-response`, `schema-check`, `rate-limit-hit`.
+5. **Assertions are measurable** — "Returns 200 with `{status: ok}`" not "API works correctly".
+6. **Cover happy path and error path** — At minimum, one success and one failure evidence marker.
+7. **On a leaf work unit, the markers are binding** — For a Bug / Task / Sub-task / Improvement, every `[EVIDENCE: name]` here is the item's evidence manifest: validation gate S14 requires at least one, and the item cannot be closed until each named artifact is captured and attached (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Name only evidence you intend to capture — and name all of it.
+
+### Step 6: Present to User for Approval
+
+Display the drafted journey and ask for confirmation before appending.
+
+### Step 7: Append to Issue Description
+
+After approval, fetch the current description, append the new Validation Journey section, and update via `lisa-linear-access operation: save-issue({id, description: <new-description>})`. Preserve all existing description content — never overwrite.
+
+### Step 8: Verify
+
+Re-fetch the issue and confirm the section is present.
+
+## When to Use This Skill
+
+- Issue was created before the Validation Journey convention was established
+- Issue was created manually without following `lisa-linear-create` guidelines
+- Issue needs a journey added or updated based on implementation progress
+- Before starting work on an Issue, to ensure verification steps are documented