memory-journal-mcp 7.0.1 → 7.2.0

package/skills/vitest-standard/references/async-and-errors.md

@@ -0,0 +1,58 @@
+# Async & Error Handling in Vitest
+
+Handling promises and rejections correctly is essential for preventing flakiness and false positives.
+
+## Async Testing
+
+### Promises
+
+Always use `await` inside your tests to ensure Vitest waits for fulfillment.
+
+```typescript
+it('should fetch data', async () => {
+  const data = await fetchData()
+  expect(data).toEqual({ id: 1 })
+})
+```
+
+### Async Error Handling
+
+Use `rejects.toThrow()` to assert a promise is rejected with a specific message.
+
+```typescript
+it('should handle API errors', async () => {
+  await expect(api.fetchUser('invalid')).rejects.toThrow('User not found')
+})
+```
+
+## Error Handling Patterns
+
+### Synchronous Errors
+
+Assert that calling a function throws an error directly.
+
+```typescript
+it('should throw for negative numbers', () => {
+  expect(() => sqrt(-1)).toThrow('Cannot compute square root of negative')
+})
+```
+
+### Specialized Error Types
+
+Validate against specific error classes.
+
+```typescript
+it('should throw TypeError', () => {
+  expect(() => doSomething()).toThrow(TypeError)
+})
+
+it('should throw CustomValidationError', () => {
+  expect(() => validate()).toThrow(ValidationError)
+})
+```
+
+## Common Failures
+
+- **Missing `await`**: Tests frequently pass silently because the promise was never resolved.
+- **`try/catch` in tests**: Don't use `try/catch` in your test bodies. Use the `toThrow()` or `rejects.toThrow()` assertions directly.
+- **Unbounded Timeouts**: Ensure your async tests can time out (default is 5s) instead of hanging your CI pipeline.

package/skills/vitest-standard/references/coverage-and-config.md

@@ -0,0 +1,53 @@
+# Coverage & Configuration
+
+Mastering Vitest configuration ensures your tests run quickly and provide the metrics needed for production delivery.
+
+## Configuration (vitest.config.ts)
+
+A sample configuration for Node.js environments.
+
+```typescript
+import { defineConfig } from 'vitest/config'
+
+export default defineConfig({
+  test: {
+    globals: true, // Enables describe, it, expect globally
+    environment: 'node',
+    include: ['**/*.test.ts'],
+    coverage: {
+      provider: 'v8',
+      reporter: ['text', 'html', 'lcov'],
+      lines: 80, // Enforce min 80% coverage
+      functions: 80,
+      branches: 80,
+      statements: 80,
+    },
+  },
+})
+```
+
+## Coverage Best Practices
+
+### ✅ DO:
+
+- Aim for **80-90% coverage** as a baseline for healthy projects.
+- Focus on **business logic** and critical paths.
+- Test **edge cases** and error paths thoroughly.
+
+### ❌ DON'T:
+
+- **Chase 100% coverage** including boilerplate code (getters/setters).
+- Test **framework code** or third-party libraries.
+- Write fragile tests just to increase lines covered.
+
+## CLI Workflow
+
+- **`vitest`**: Run in watch mode during TDD sessions.
+- **`vitest run`**: Single execution for CI/CD or pre-commit hooks.
+- **`vitest run --coverage`**: Generate coverage reports.
+- **`vitest u`**: Update outdated snapshots after intentional changes.
+
+### CI Integration
+
+- Enable `reporters: ['default', 'junit']` for better integration with GitHub Actions or GitLab CI.
+- Set `outputFile: 'junit.xml'` to capture results in CI artifacts.

package/skills/vitest-standard/references/mocking.md

@@ -0,0 +1,61 @@
+# Mocking & Test Doubles
+
+Vitest provides a rich API for isolating your code from its dependencies.
+
+## Test Doubles
+
+| Type     | Purpose                           | Use Case                      |
+| :------- | :-------------------------------- | :---------------------------- |
+| **Mock** | Verifies behavior (calls, args)   | `vi.fn()`                     |
+| **Stub** | Returns predefined values         | `vi.fn().mockReturnValue(42)` |
+| **Spy**  | Observes a real function          | `vi.spyOn(obj, 'method')`     |
+| **Fake** | Working simplified implementation | A `FakeDatabase` using `Map`  |
+
+## Mocking Strategies
+
+### 1. Mocking Modules
+
+Must be called at the top of your test file to intercept internal imports.
+
+```typescript
+vi.mock('./api', () => ({
+  fetchUser: vi.fn().mockResolvedValue({ id: 1, name: 'John' }),
+}))
+```
+
+### 2. Dependency Injection
+
+Prefer passing dependencies via constructor to facilitate easy mocking.
+
+```typescript
+class UserService {
+  constructor(private db: Database) {}
+  async getUser(id: string) {
+    return this.db.query('SELECT * FROM users WHERE id = ?', [id])
+  }
+}
+
+// Test with mock instance
+const mockDb = { query: vi.fn().mockResolvedValue({ id: '123' }) }
+const service = new UserService(mockDb as any)
+```
+
+### 3. Cleanup & Restoration
+
+Crucial for preventing call history leaks between tests.
+
+```typescript
+beforeEach(() => {
+  vi.clearAllMocks() // Resets call history
+})
+
+afterEach(() => {
+  vi.restoreAllMocks() // Restores original methods if spying
+})
+```
+
+## Anti-Patterns
+
+- **Testing implementation**: Mocking internal methods of the class under test.
+- **Over-mocking**: Mocking so much that the test loses its connection to reality.
+- **Mocking your own code**: Mocking other internal helpers instead of the external boundaries.

package/skills/vitest-standard/references/tdd-patterns.md

@@ -0,0 +1,60 @@
+# TDD & Test Patterns
+
+Test-Driven Development (TDD) facilitates better API design and ensures your code is testable from its inception.
+
+## Red-Green-Refactor Cycle
+
+1.  **Red**: Write a failing test for a specific feature.
+2.  **Green**: Write the minimal amount of code to make the test pass.
+3.  **Refactor**: Clean up the code without changing its behavior.
+
+### Parametric Testing
+
+Drive the same test logic with multiple data inputs.
+
+```typescript
+describe.each([
+  [2, 3, 5],
+  [10, 5, 15],
+  [-1, 1, 0],
+])('Calculator.add(%i, %i)', (a, b, expected) => {
+  it(`should return ${expected}`, () => {
+    const calc = new Calculator()
+    expect(calc.add(a, b)).toBe(expected)
+  })
+})
+```
+
+### Given-When-Then (BDD Style)
+
+Structure tests according to behavioral scenarios.
+
+```typescript
+describe('Shopping Cart', () => {
+  it('should apply discount when total exceeds $100', () => {
+    // Given: A cart with items totaling $120
+    const cart = new ShoppingCart()
+    cart.addItem({ price: 120, quantity: 1 })
+
+    // When: Getting the total
+    const total = cart.getTotal()
+
+    // Then: 10% discount applied
+    expect(total).toBe(108) // $120 - $12 (10%)
+  })
+})
+```
+
+## Naming & File Structure
+
+### File Structure
+
+- **Co-located tests**: `UserService.ts` and `UserService.test.ts` in the same directory.
+- **Integration tests**: Place in a separate `tests/integration/` directory.
+
+### Naming Conventions
+
+- ✅ `it('should return error on missing email')`
+- ✅ `it('returns error on missing email')`
+- ❌ `it('test1')`
+- ❌ `it('it should work')`

package/dist/github-integration-PDRLXKGM.js

@@ -1 +0,0 @@
-export { GitHubIntegration } from './chunk-ARLH46WS.js';

package/skills/github-commander/workflows/full-audit.md

@@ -1,134 +0,0 @@
-# Full Audit
-
-Run a unified code quality + performance + security audit in a single pass with
-cross-reference analysis. Use for codebases that are already in good shape.
-
-> **When to use**: For established codebases that have likely passed individual
-> audits before. This prevents the "fix cascade" where a security fix introduces
-> a quality regression, or a performance optimization weakens validation.
-
-> **Do not use for**: First-time audits on codebases with many known issues.
-> Run the individual workflows (`code-quality-audit.md`, `perf-audit.md`,
-> `security-audit.md`) separately and fix iteratively instead.
-
-## Phase 1 — Collect Findings (Read-Only)
-
-Run all three audits as **read-only analysis** — no fixes yet. Tag each finding
-by its source domain.
-
-### 1a. Code Quality Scan
-
-Follow `code-quality-audit.md` categories 1–14. Tag every finding with `[CQ]`.
-
-### 1b. Performance Scan
-
-Follow `perf-audit.md` sections 1–6. Tag every finding with `[PERF]`.
-
-### 1c. Security Scan
-
-Follow `security-audit.md` phases 2–7. Tag every finding with `[SEC]`.
-
-### 1d. Raw Findings Ledger
-
-Produce **one** consolidated table sorted by severity:
-
-| #   | Tag | Severity | File | Lines | Finding | Suggested Fix |
-| --- | --- | -------- | ---- | ----- | ------- | ------------- |
-
-**Do not apply any fixes yet.**
-
-## Phase 2 — Cross-Reference Analysis
-
-Review the raw ledger and identify findings that interact across domains.
-
-### Conflict Types
-
-| Type                       | Example                                                                         |
-| -------------------------- | ------------------------------------------------------------------------------- |
-| **Security ↔ Quality**     | A `[SEC]` fix (adding validation) could introduce duplication flagged by `[CQ]` |
-| **Security ↔ Performance** | A `[SEC]` fix (parameterized queries, hashing) could degrade `[PERF]`           |
-| **Performance ↔ Quality**  | A `[PERF]` fix (inlining, caching) could increase complexity flagged by `[CQ]`  |
-| **Performance ↔ Security** | A `[PERF]` fix (caching, skipping validation) could weaken a `[SEC]` boundary   |
-| **Shared Root Cause**      | Multiple findings trace to the same underlying issue                            |
-| **Fix Dependency**         | One finding must be fixed before another                                        |
-
-### Cross-Reference Table
-
-| Linked Findings | Conflict Type | Resolution Strategy |
-| --------------- | ------------- | ------------------- |
-
-If no cross-references are found, state that explicitly.
-
-## Phase 3 — Prioritized Fix Plan
-
-Produce an **ordered fix plan** that avoids cascading regressions:
-
-### Ordering Rules
-
-1. **Shared root causes first** — a single fix resolves multiple findings
-2. **Fix dependencies next** — structural changes that unblock later fixes
-3. **Security-critical** — critical/high `[SEC]` findings
-4. **Cross-referenced fixes** — unified resolution strategies from Phase 2
-5. **Remaining findings** — in severity order
-
-### Fix Plan Table
-
-| Order | Finding(s) | Fix Description | Domains Resolved |
-| ----- | ---------- | --------------- | ---------------- |
-
-## HITL Gate — User Approval
-
-**Stop here.** Present the Phase 2 cross-reference analysis and Phase 3 fix
-plan to the human for review. Do not proceed until explicitly approved.
-
-Journal the audit state:
-
-```
-create_entry({
-  content: "Full audit complete. Findings: <N total> (<CQ count> CQ, <PERF count> PERF, <SEC count> SEC). Cross-references: <N>. Awaiting approval for fix plan.",
-  entry_type: "audit_finding",
-  tags: ["commander", "full-audit", "summary"],
-})
-```
-
-## Phase 4 — Apply Fixes & Verify
-
-Apply fixes in the approved order. After **all** fixes:
-
-Run validation gates:
-
-- Gate 1: Lint + Typecheck
-- Gate 2: Build
-- Gate 3: Tests
-
-If any validation fails, identify which fix group caused it and revise.
-
-## Phase 5 — Final Report
-
-### Summary Table
-
-| Domain       | Score (A–F) | Findings | Critical | Cross-Referenced |
-| ------------ | ----------- | -------- | -------- | ---------------- |
-| Code Quality |             |          |          |                  |
-| Performance  |             |          |          |                  |
-| Security     |             |          |          |                  |
-
-### Metrics
-
-- **Total findings**: _N_
-- **Cross-referenced findings**: _N_
-- **Cascading fixes avoided**: _N_
-
-### Overall Score
-
-Assign an **overall health score (A–F)** considering all three domains.
-
-## Post-Audit
-
-1. Update changelog with fixes
-2. Commit:
-   ```bash
-   git add <fixed files> <changelog>
-   git diff --cached --stat
-   git commit -m "chore: unified audit fixes"
-   ```