@monoes/monomindcli 2.15.3 → 2.15.5

package/org-skills/test-master/references/testing-anti-patterns.md

@@ -0,0 +1,231 @@
+# Testing Anti-Patterns
+
+---
+
+## Core Principle
+
+> **"Test what the code does, not what the mocks do."**
+
+When tests verify mock behavior instead of actual functionality, they provide false confidence while catching zero real bugs.
+
+---
+
+## The Five Anti-Patterns
+
+### Anti-Pattern 1: Testing Mock Behavior
+
+**The Problem:** Verifying that mocks exist and were called, rather than testing actual component output.
+
+```typescript
+// ❌ BAD: Testing the mock, not the behavior
+it('should call the API', () => {
+  const mockApi = jest.fn().mockResolvedValue({ data: 'test' });
+  const service = new UserService(mockApi);
+
+  service.getUser(1);
+
+  expect(mockApi).toHaveBeenCalledWith(1); // Testing mock, not result
+});
+```
+
+```typescript
+// ✅ GOOD: Testing actual behavior
+it('should return user data from API', async () => {
+  const mockApi = jest.fn().mockResolvedValue({ id: 1, name: 'Alice' });
+  const service = new UserService(mockApi);
+
+  const user = await service.getUser(1);
+
+  expect(user.name).toBe('Alice'); // Testing actual output
+});
+```
+
+**Solution:** Test the genuine component output. If you can only verify mock calls, reconsider whether the test adds value.
+
+---
+
+### Anti-Pattern 2: Test-Only Methods in Production
+
+**The Problem:** Adding methods to production classes solely for test setup or cleanup.
+
+```typescript
+// ❌ BAD: Production code polluted with test concerns
+class UserCache {
+  private cache: Map<number, User> = new Map();
+
+  getUser(id: number): User | undefined {
+    return this.cache.get(id);
+  }
+
+  // This method exists ONLY for tests
+  _resetForTesting(): void {
+    this.cache.clear();
+  }
+}
+```
+
+```typescript
+// ✅ GOOD: Test utilities separate from production
+// production/UserCache.ts
+class UserCache {
+  private cache: Map<number, User> = new Map();
+
+  getUser(id: number): User | undefined {
+    return this.cache.get(id);
+  }
+}
+
+// test/helpers.ts
+function createFreshCache(): UserCache {
+  return new UserCache(); // Fresh instance per test
+}
+```
+
+**Solution:** Relocate cleanup logic to test utility functions. Use fresh instances per test instead of reset methods.
+
+---
+
+### Anti-Pattern 3: Mocking Without Understanding
+
+**The Problem:** Over-mocking without grasping side effects, leading to tests that pass but hide real issues.
+
+```typescript
+// ❌ BAD: Mocking everything without understanding
+it('should process order', async () => {
+  jest.mock('./inventory');
+  jest.mock('./payment');
+  jest.mock('./shipping');
+  jest.mock('./notifications');
+
+  const result = await processOrder(order);
+
+  expect(result.success).toBe(true); // What did we actually test?
+});
+```
+
+```typescript
+// ✅ GOOD: Strategic mocking with real components where possible
+it('should process order with real inventory check', async () => {
+  // Real inventory service against test database
+  const inventory = new InventoryService(testDb);
+
+  // Mock only external services
+  const payment = mockPaymentGateway();
+
+  const processor = new OrderProcessor(inventory, payment);
+  const result = await processor.process(order);
+
+  expect(result.success).toBe(true);
+  expect(await inventory.getStock(order.itemId)).toBe(originalStock - 1);
+});
+```
+
+**Solution:** Run tests with real implementations first to understand behavior. Then mock at the appropriate level - external services, not internal logic.
+
+---
+
+### Anti-Pattern 4: Incomplete Mocks
+
+**The Problem:** Partial mock responses missing downstream fields that production code expects.
+
+```typescript
+// ❌ BAD: Incomplete mock response
+const mockUserApi = jest.fn().mockResolvedValue({
+  id: 1,
+  name: 'Test User'
+  // Missing: email, createdAt, permissions, settings...
+});
+
+// Test passes, but production crashes when accessing user.email
+```
+
+```typescript
+// ✅ GOOD: Complete mock matching real API response
+const mockUserApi = jest.fn().mockResolvedValue({
+  id: 1,
+  name: 'Test User',
+  email: 'test@example.com',
+  createdAt: '2024-01-01T00:00:00Z',
+  permissions: ['read', 'write'],
+  settings: {
+    theme: 'light',
+    notifications: true
+  }
+});
+
+// Or use a factory
+const mockUserApi = jest.fn().mockResolvedValue(
+  createMockUser({ name: 'Test User' }) // Factory fills defaults
+);
+```
+
+**Solution:** Mirror complete real API response structure. Use factories to generate complete mock objects with sensible defaults.
+
+---
+
+### Anti-Pattern 5: Integration Tests as Afterthought
+
+**The Problem:** Treating testing as optional follow-up work rather than integral to development.
+
+```typescript
+// ❌ BAD: "We'll add tests later"
+// Day 1: Write 500 lines of code
+// Day 2: Write 500 more lines
+// Day 3: "We need to ship, tests can wait"
+// Day 30: Catastrophic bug in production
+// Day 31: "Why didn't we have tests?"
+```
+
+```typescript
+// ✅ GOOD: Tests are part of implementation
+// Write failing test
+it('should reject duplicate usernames', async () => {
+  await createUser({ username: 'alice' });
+
+  await expect(createUser({ username: 'alice' }))
+    .rejects.toThrow('Username already exists');
+});
+
+// Make it pass
+async function createUser(data: UserInput): Promise<User> {
+  const existing = await db.users.findByUsername(data.username);
+  if (existing) {
+    throw new Error('Username already exists');
+  }
+  return db.users.create(data);
+}
+
+// Feature AND test ship together
+```
+
+**Solution:** Follow TDD - testing is implementation, not documentation. No feature is "done" without tests.
+
+---
+
+## Detection Checklist
+
+Review your tests for these warning signs:
+
+| Warning Sign | Anti-Pattern |
+|-------------|--------------|
+| `expect(mock).toHaveBeenCalled()` without testing output | Testing mock behavior |
+| Methods starting with `_` or `ForTesting` in production | Test-only methods |
+| Every dependency is mocked | Mocking without understanding |
+| Mocks return `{ success: true }` only | Incomplete mocks |
+| Test files added weeks after feature ships | Tests as afterthought |
+
+---
+
+## Quick Reference
+
+| Anti-Pattern | Symptom | Fix |
+|-------------|---------|-----|
+| Testing mocks | Only mock assertions, no behavior tests | Assert on actual output |
+| Test-only methods | `_reset()`, `_setForTest()` in prod | Use fresh instances |
+| Over-mocking | 10+ mocks per test | Test with real deps first |
+| Incomplete mocks | Minimal stub responses | Use factories, match reality |
+| Tests as afterthought | Features ship untested | TDD from the start |
+
+---
+
+*Content adapted from [obra/superpowers](https://github.com/obra/superpowers) by Jesse Vincent (@obra), MIT License.*

package/org-skills/test-master/references/unit-testing.md

@@ -0,0 +1,113 @@
+# Unit Testing
+
+## Jest/Vitest Pattern
+
+```typescript
+describe('UserService', () => {
+  let service: UserService;
+  let mockRepo: jest.Mocked<UserRepository>;
+
+  beforeEach(() => {
+    mockRepo = { findById: jest.fn(), save: jest.fn() } as any;
+    service = new UserService(mockRepo);
+  });
+
+  afterEach(() => jest.clearAllMocks());
+
+  describe('getUser', () => {
+    it('returns user when found', async () => {
+      const user = { id: '1', name: 'Test' };
+      mockRepo.findById.mockResolvedValue(user);
+
+      const result = await service.getUser('1');
+
+      expect(result).toEqual(user);
+      expect(mockRepo.findById).toHaveBeenCalledWith('1');
+    });
+
+    it('throws NotFoundError when user not found', async () => {
+      mockRepo.findById.mockResolvedValue(null);
+
+      await expect(service.getUser('1')).rejects.toThrow(NotFoundError);
+    });
+  });
+});
+```
+
+## pytest Pattern
+
+```python
+import pytest
+from unittest.mock import Mock, AsyncMock
+
+class TestUserService:
+    @pytest.fixture
+    def mock_repo(self):
+        return Mock()
+
+    @pytest.fixture
+    def service(self, mock_repo):
+        return UserService(mock_repo)
+
+    async def test_get_user_returns_user(self, service, mock_repo):
+        mock_repo.find_by_id = AsyncMock(return_value={"id": "1", "name": "Test"})
+
+        result = await service.get_user("1")
+
+        assert result == {"id": "1", "name": "Test"}
+        mock_repo.find_by_id.assert_called_once_with("1")
+
+    async def test_get_user_raises_not_found(self, service, mock_repo):
+        mock_repo.find_by_id = AsyncMock(return_value=None)
+
+        with pytest.raises(NotFoundError):
+            await service.get_user("1")
+```
+
+## Mocking Patterns
+
+```typescript
+// Mock functions
+const mockFn = jest.fn();
+mockFn.mockReturnValue('value');
+mockFn.mockResolvedValue('async value');
+mockFn.mockRejectedValue(new Error('error'));
+
+// Mock modules
+jest.mock('./database', () => ({
+  query: jest.fn(),
+}));
+
+// Spy on existing methods
+jest.spyOn(console, 'log').mockImplementation(() => {});
+```
+
+## Test Organization
+
+```typescript
+describe('Feature', () => {
+  describe('happy path', () => {
+    it('does expected behavior', () => {});
+  });
+
+  describe('edge cases', () => {
+    it('handles empty input', () => {});
+    it('handles max values', () => {});
+  });
+
+  describe('error cases', () => {
+    it('throws on invalid input', () => {});
+  });
+});
+```
+
+## Quick Reference
+
+| Pattern | Use Case |
+|---------|----------|
+| `describe()` | Group related tests |
+| `it()` / `test()` | Single test case |
+| `beforeEach()` | Setup before each test |
+| `jest.fn()` | Create mock function |
+| `mockResolvedValue()` | Mock async return |
+| `expect().toThrow()` | Assert exception |

package/{dist/src/orgrt/role-skills/tester.md → org-skills/tester/SKILL.md}

@@ -1,3 +1,11 @@
+---
+name: tester
+description: "Tester role best practices. Builds confidence that code works — through the right mix of unit, integration, and end-to-end tests targeting real risk, not just coverage numbers."
+tags: ["engineering"]
+tools: ["monograph_query","monograph_context","monograph_impact"]
+license: Apache-2.0
+source: https://github.com/monoes/monomind
+---
 # Tester — Best Practices
 
 ## Focus

package/org-skills/the-fool/LICENSE.txt

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/org-skills/the-fool/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: the-fool
+description: "Use when challenging ideas, plans, decisions, or proposals using structured critical reasoning. Invoke to play devil's advocate, run a pre-mortem, red team, or audit evidence and assumptions."
+tags: ["leadership","research"]
+tools: []
+license: MIT
+source: https://github.com/Jeffallan/claude-skills
+source_path: "skills/the-fool"
+source_commit: 882ef55e377dbf9a4dbe496bb41ac6ccd0e555cf
+---
+# The Fool
+
+The court jester who alone could speak truth to the king. Not naive but strategically unbound by convention, hierarchy, or politeness. Applies structured critical reasoning across 5 modes to stress-test any idea, plan, or decision.
+
+## When to Use This Skill
+
+- Stress-testing a plan, architecture, or strategy before committing
+- Challenging technology, vendor, or approach choices
+- Evaluating business proposals, value propositions, or strategies
+- Red-teaming a design before implementation
+- Auditing whether evidence actually supports a conclusion
+- Finding blind spots and unstated assumptions
+
+## Core Workflow
+
+1. **Identify** — Extract the user's position from conversation context. Restate it as a steelmanned thesis for confirmation.
+2. **Select** — Use `AskUserQuestion` with two-step mode selection (see below).
+3. **Challenge** — Apply the selected mode's method. Load the corresponding reference file for deep guidance.
+4. **Engage** — Present the 3-5 strongest challenges. Ask the user to respond before proceeding.
+5. **Synthesize** — Integrate insights into a strengthened position. Offer a second pass with a different mode.
+
+## Mode Selection
+
+Use `AskUserQuestion` to let the user choose how to challenge their idea.
+
+**Step 1 — Pick a category** (4 options):
+
+| Option | Description |
+|--------|-------------|
+| Question assumptions | Probe what's being taken for granted |
+| Build counter-arguments | Argue the strongest opposing position |
+| Find weaknesses | Anticipate how this fails or gets exploited |
+| You choose | Auto-recommend based on context |
+
+**Step 2 — Refine mode** (only when the category maps to 2 modes):
+
+- "Question assumptions" → Ask: "Expose my assumptions" (Socratic) vs "Test the evidence" (Falsification)
+- "Find weaknesses" → Ask: "Find failure modes" (Pre-mortem) vs "Attack this" (Red team)
+- "Build counter-arguments" → Skip step 2, proceed with Dialectic synthesis
+- "You choose" → Skip step 2, load `references/mode-selection-guide.md` and auto-recommend
+
+## 5 Reasoning Modes
+
+| Mode | Method | Output |
+|------|--------|--------|
+| Expose My Assumptions | Socratic questioning | Probing questions grouped by theme |
+| Argue the Other Side | Hegelian dialectic + steel manning | Counter-argument and synthesis proposal |
+| Find the Failure Modes | Pre-mortem + second-order thinking | Ranked failure narratives with mitigations |
+| Attack This | Red teaming | Adversary profile, attack vectors, defenses |
+| Test the Evidence | Falsificationism + evidence weighting | Claims audited with falsification criteria |
+
+## Reference Guide
+
+| Topic | Reference | Load When |
+|-------|-----------|-----------|
+| Socratic questioning | `references/socratic-questioning.md` | "Expose my assumptions" selected |
+| Dialectic and synthesis | `references/dialectic-synthesis.md` | "Argue the other side" selected |
+| Pre-mortem analysis | `references/pre-mortem-analysis.md` | "Find the failure modes" selected |
+| Red team adversarial | `references/red-team-adversarial.md` | "Attack this" selected |
+| Evidence audit | `references/evidence-audit.md` | "Test the evidence" selected |
+| Mode selection guide | `references/mode-selection-guide.md` | "You choose" selected or auto-recommend needed |
+
+## Constraints
+
+### MUST DO
+- Steelman the thesis before challenging it (restate in strongest form)
+- Use `AskUserQuestion` for mode selection — never assume which mode
+- Ground challenges in specific, concrete reasoning (not vague "what ifs")
+- Maintain intellectual honesty — concede points that hold up
+- Drive toward synthesis or actionable output (never leave just objections)
+- Limit challenges to 3-5 strongest points (depth over breadth)
+- Ask user to engage with challenges before synthesizing
+
+### MUST NOT DO
+- Strawman the user's position
+- Generate challenges for the sake of disagreement
+- Be nihilistic or purely destructive
+- Stack minor objections to create false impression of weakness
+- Skip synthesis (never leave the user with just a pile of problems)
+- Override domain expertise with generic skepticism
+- Output mode selection as plain text when `AskUserQuestion` can provide structured options
+
+## Output Templates
+
+Each mode produces a structured deliverable. See the corresponding reference file for the full template.
+
+| Mode | Deliverable |
+|------|------------|
+| Expose My Assumptions | Assumption inventory + probing questions by theme + suggested experiments |
+| Argue the Other Side | Steelmanned thesis + antithesis argued + synthesis proposed + confidence rating |
+| Find the Failure Modes | Ranked failure narratives + early warning signs + mitigations + inversion check |
+| Attack This | Adversary profiles + ranked attack vectors + perverse incentives + defenses |
+| Test the Evidence | Claims extracted + falsification criteria + evidence grades + competing explanations |
+
+After any mode, the final output must include:
+
+1. **Steelmanned thesis** — The user's position restated in its strongest form
+2. **Challenges** — 3-5 strongest points from the selected mode
+3. **User response** — Space for the user to engage before synthesis
+4. **Synthesis** — Strengthened position integrating the challenges
+5. **Next steps** — Offer a second pass with a different mode if warranted
+
+## Knowledge Reference
+
+Socratic method, Hegelian dialectic, steel manning, pre-mortem analysis, red teaming, falsificationism, abductive reasoning, second-order thinking, cognitive biases, inversion technique
+
+[Documentation](https://jeffallan.github.io/claude-skills/skills/workflow/the-fool/)

package/org-skills/the-fool/references/dialectic-synthesis.md

@@ -0,0 +1,151 @@
+# Dialectic Synthesis
+
+Hegelian dialectic with steel manning for constructing the strongest possible counter-argument and driving toward synthesis.
+
+## Core Principle
+
+The dialectic is not about winning. It is about producing a stronger position than either thesis or antithesis alone. The Fool's job is to argue the other side so well that the user is forced to either refine their position or acknowledge a genuine trade-off.
+
+## Process
+
+1. **Restate the thesis** — Steelman the user's position first
+2. **Construct the antithesis** — Build the strongest opposing argument
+3. **Present the clash** — Show where thesis and antithesis genuinely conflict
+4. **Drive toward synthesis** — Propose a position that incorporates the best of both
+
+## Steel Manning Technique
+
+Steel manning is the opposite of straw manning. Restate the user's position in its strongest possible form before arguing against it.
+
+### How to Steelman
+
+| Step | Action | Example |
+|------|--------|---------|
+| 1. Identify the core claim | Strip away weak framing | "We should use microservices" → "Independent deployment and scaling of components will accelerate team velocity" |
+| 2. Add the strongest evidence | Supply what the user implied | "...especially given 4 teams working on different release cycles" |
+| 3. Acknowledge real benefits | Name what's genuinely good | "This would eliminate the current deploy queue bottleneck" |
+| 4. Confirm with user | "Is this a fair restatement?" | Ensures you're attacking the real position |
+
+### Steelman Checklist
+
+- [ ] Have I made the position stronger, not weaker?
+- [ ] Would the user recognize this as their view (or better)?
+- [ ] Have I included the strongest evidence for their side?
+- [ ] Am I attacking this version, not an easier one?
+
+## Antithesis Construction
+
+### Technique: Strongest Counter-Argument
+
+Build the antithesis by asking: "If a smart, informed person disagreed, what would their best argument be?"
+
+| Source of Counter-Arguments | Example |
+|----------------------------|---------|
+| Opposing trade-off | "Speed now vs. maintainability later" |
+| Hidden cost | "The migration cost exceeds the projected savings for 18 months" |
+| Alternative that solves the same problem | "A modular monolith gets 80% of the benefit at 20% of the cost" |
+| Precedent from similar situations | "Company X tried this and reverted after 2 years" |
+| Stakeholder the thesis doesn't serve | "The junior developers will struggle with the added complexity" |
+
+### Reductio ad Absurdum (Supporting Technique)
+
+Take the thesis to its logical extreme to reveal hidden limits.
+
+| Thesis | Reductio | Reveals |
+|--------|----------|---------|
+| "We should optimize for developer experience" | "Then we should never ship to production, since bugs hurt DX" | DX must be balanced against delivery |
+| "More tests are always better" | "Then we should have 100% coverage including getters/setters" | Test value has diminishing returns |
+| "We should move fast" | "Then skip code review and testing" | Speed has a quality floor |
+
+Use sparingly. Reductio highlights the boundary of a principle, not its invalidity.
+
+## Synthesis Patterns
+
+After presenting thesis and antithesis, propose a synthesis using one of these patterns.
+
+### 1. Conditional Synthesis
+
+"X is true **when** condition A holds; Y is true **when** condition B holds."
+
+Example: "Microservices are right for the payment service (independent scaling, compliance boundary) but the admin dashboard should stay in the monolith (low traffic, fast iteration)."
+
+### 2. Scope Partitioning
+
+"Apply X to domain A and Y to domain B."
+
+Example: "Use event sourcing for the audit trail (append-only, queryable history) but standard CRUD for user profiles (simple reads/writes)."
+
+### 3. Temporal Synthesis
+
+"Start with X, migrate to Y when trigger Z occurs."
+
+Example: "Start with a monolith, extract services when team size exceeds 3 squads or deploy frequency hits weekly conflicts."
+
+### 4. Risk Mitigation Synthesis
+
+"Proceed with X but add safeguards from Y."
+
+Example: "Adopt the new framework but keep the abstraction layer so we can swap back within 2 sprints."
+
+### 5. Hybrid Extraction
+
+"Take the strongest element from each side."
+
+Example: "Use the microservices deployment model (independent containers) but keep a shared database with schema ownership (avoiding distributed data complexity)."
+
+## Confidence Assessment
+
+Rate the synthesis outcome.
+
+| Level | Meaning | Action |
+|-------|---------|--------|
+| **HIGH** | Synthesis clearly stronger than either side alone | Proceed with synthesis |
+| **MEDIUM** | Synthesis is plausible but untested | Identify the riskiest assumption and suggest an experiment |
+| **LOW** | Both sides have strong, irreconcilable claims | Name the genuine trade-off; let the user decide based on priorities |
+| **PIVOT** | The antithesis is stronger than the thesis | Recommend the user reconsider their original position |
+
+## Anti-Patterns
+
+| Anti-Pattern | Problem | Fix |
+|-------------|---------|-----|
+| False synthesis | "Just do both!" without resolving the tension | Name the specific trade-off being resolved |
+| Weak antithesis | Counter-argument is a strawman | Apply steel manning to the counter too |
+| Thesis bias | Synthesis suspiciously close to original position | Check if antithesis was genuinely engaged |
+| Complexity creep | Synthesis is more complex than either original | Simpler synthesis is usually better |
+| Fence-sitting | "It depends" without specifying on what | Name the exact conditions for each path |
+
+## Output Template
+
+```markdown
+## Thesis (Steelmanned)
+
+[User's position restated in strongest form]
+
+**Strongest evidence for:** [1-2 supporting points]
+
+## Antithesis
+
+[Strongest counter-argument]
+
+**Strongest evidence for:** [1-2 supporting points]
+
+## Points of Genuine Conflict
+
+| Dimension | Thesis Says | Antithesis Says |
+|-----------|------------|-----------------|
+| [e.g., Speed] | [Position] | [Counter-position] |
+| [e.g., Cost] | [Position] | [Counter-position] |
+
+## Proposed Synthesis
+
+**Pattern:** [Conditional / Scope / Temporal / Risk Mitigation / Hybrid]
+
+[Concrete synthesis proposal]
+
+**What this preserves from the thesis:** [specific elements]
+**What this incorporates from the antithesis:** [specific elements]
+**What this gives up:** [explicit trade-offs]
+
+**Confidence:** HIGH / MEDIUM / LOW / PIVOT
+**If MEDIUM:** Test [riskiest assumption] by [experiment]
+```