clawpowers 1.0.0

package/skills/agent-payments/SKILL.md

@@ -0,0 +1,411 @@
+---
+name: agent-payments
+description: Enable agents to transact autonomously across a full multi-chain financial stack — x402 payments, Uniswap V3 swaps, CCTP bridging, ERC-8004 identity, mutual stake escrow, spending policies, and agent-to-agent delegation (AP2). Activate when an agent needs to pay for an API, swap tokens, bridge assets, escrow funds for a task, or establish on-chain identity.
+version: 6.0.0
+requires:
+  tools: [bash, node]
+  runtime: true
+metrics:
+  tracks: [payments_attempted, payments_succeeded, swaps_executed, bridges_initiated, escrows_created, spending_per_session, limit_enforcement_hits]
+  improves: [payment_routing, limit_calibration, retry_strategy, swap_routing, bridge_selection]
+---
+
+# Agent Payments
+
+## When to Use
+
+Apply this skill when:
+
+- An HTTP request returns `402 Payment Required`
+- You need to call a premium API that requires per-request payment
+- You're accessing a paid AI model, compute resource, or data service
+- You need to purchase a resource (storage, credits, bandwidth) autonomously
+- An agent-to-agent payment or task delegation is required (AP2 protocol)
+- You need to swap tokens across Base, Arbitrum, Optimism, or Polygon
+- You need to bridge USDC between EVM chains or to Solana (CCTP V2)
+- You need to establish or verify on-chain agent identity (ERC-8004)
+- You need to escrow funds for a multi-agent task (mutual stake or optimistic)
+- Gas sponsorship is needed for a gasless user experience
+
+**Skip when:**
+- The service requires human authorization for payment (no wallet configured)
+- The payment would exceed the configured spending limit (surface to operator)
+- The service uses subscription billing (not per-request x402)
+- The payment is above threshold for autonomous authorization (see limits)
+
+**Decision tree:**
+```
+Is the response HTTP 402?
+├── No  → Does the task require swap/bridge/escrow/identity?
+│         ├── No  → This skill doesn't apply
+│         └── Yes → Jump to the relevant section below
+└── Yes → Is a wallet configured?
+          ├── No  → Run setup (see Setup section)
+          └── Yes → Does this payment fit within spending limits?
+                    ├── No  → Queue via agentExecute or request human auth
+                    └── Yes → Proceed with autonomous payment
+```
+
+## Background: x402 Protocol
+
+The x402 protocol is a standard for machine-to-machine payments embedded in HTTP. When a server requires payment it returns:
+
+```http
+HTTP/1.1 402 Payment Required
+X-Payment-Required: {"scheme":"exact","network":"base","maxAmountRequired":"1000000","asset":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913","payTo":"0xMERCHANT","resource":"https://api.example.com/premium-endpoint","description":"1 API call"}
+```
+
+The agent then:
+1. Constructs a payment matching the requirement
+2. Submits the payment (on-chain or via payment channel)
+3. Includes payment proof in the retry request
+4. Server validates and processes the original request
+
+Reference implementation: [agentpay-mcp](https://github.com/up2itnow0822/agentpay-mcp) (integrated into NVIDIA NeMo Agent Toolkit)
+
+## Setup
+
+### Install agentwallet-sdk
+
+```bash
+npm install agentwallet-sdk viem
+```
+
+### Supported Chains
+
+Base, Ethereum, Arbitrum, Polygon, Optimism, Avalanche, Unichain, Linea, Sonic, World Chain, Base Sepolia (testnet). Solana is supported for CCTP V2 bridging.
+
+## Core Methodology
+
+### 1. Create Wallet + Set Spending Policy
+
+Non-custodial ERC-6551 token-bound wallets are available on all 11 supported EVM chains. Spending limits are enforced by smart contract — the agent cannot override them.
+
+```typescript
+import { createWallet, setSpendPolicy, agentExecute, NATIVE_TOKEN } from 'agentwallet-sdk';
+
+const wallet = createWallet({
+  accountAddress: '0x...',
+  chain: 'base',
+  walletClient,            // viem WalletClient
+});
+
+// Set per-token, per-period on-chain spending limits
+await setSpendPolicy(wallet, {
+  token: NATIVE_TOKEN,
+  perTxLimit: 25000000000000000n,    // 0.025 ETH per transaction
+  periodLimit: 500000000000000000n,  // 0.5 ETH per period
+  periodLength: 86400,               // 24-hour rolling period
+});
+
+// agentExecute auto-approves within limits, queues if over
+const result = await agentExecute(wallet, {
+  to: '0x...',
+  value: 10000000000000000n,         // 0.01 ETH
+});
+```
+
+**`agentExecute` behavior:**
+- Within limits → executes immediately, returns transaction receipt
+- Over limits → queues the payment, returns queue ID for human review
+- Exceeded daily cap → returns `LIMIT_EXCEEDED` with details
+
+### 2. x402 Payments (Multi-Chain)
+
+```typescript
+import { createX402Client } from 'agentwallet-sdk';
+
+const x402 = createX402Client(wallet, {
+  supportedNetworks: ['base:8453', 'arbitrum:42161'],
+  globalDailyLimit: 10_000_000n,     // 10 USDC daily cap (6 decimals)
+});
+
+// Auto-detects network, handles 402 → pay → retry transparently
+const response = await x402.fetch('https://api.example.com/premium');
+const data = await response.json();
+```
+
+The client automatically:
+- Parses the `X-Payment-Required` header
+- Selects the cheapest supported network
+- Constructs and submits the payment
+- Retries the original request with proof
+
+### 3. Token Swaps (Uniswap V3)
+
+Available on Base, Arbitrum, Optimism, Polygon. Use the chain-specific token registries: `BASE_TOKENS`, `ARBITRUM_TOKENS`, `OPTIMISM_TOKENS`, `POLYGON_TOKENS`.
+
+```typescript
+import { attachSwap } from 'agentwallet-sdk/swap';
+import { BASE_TOKENS } from 'agentwallet-sdk';
+
+const swap = attachSwap(wallet, { chain: 'base' });
+
+await swap.swap(
+  BASE_TOKENS.WETH,
+  BASE_TOKENS.USDC,
+  amount,
+  { slippageBps: 50 },              // 0.5% slippage tolerance
+);
+```
+
+Token registries expose canonical addresses for all major tokens on each chain. Always use registry constants rather than hardcoding addresses.
+
+### 4. CCTP V2 Bridge (EVM ↔ EVM and EVM ↔ Solana)
+
+Bridge USDC across any supported chain pair, including to/from Solana.
+
+```typescript
+import { CCTPBridge } from 'agentwallet-sdk';
+
+const bridge = new CCTPBridge({ sourceChain: 'base', walletClient });
+
+const { transferId } = await bridge.transfer({
+  destinationChain: 'arbitrum',      // or 'solana' for cross-ecosystem
+  amount: 100_000_000n,              // 100 USDC (6 decimals)
+  recipient: '0x...',
+});
+
+// Poll for settlement
+const status = await bridge.getStatus(transferId);
+```
+
+### 5. ERC-8004 On-Chain Agent Identity
+
+Register and manage verifiable on-chain identity for agents. Three registries: Identity, Reputation, Validation.
+
+```typescript
+import { AgentIdentity } from 'agentwallet-sdk';
+
+const identity = new AgentIdentity({ chain: 'base', walletClient });
+
+// Register agent identity
+const { agentId } = await identity.register({
+  name: 'my-agent',
+  capabilities: ['payments', 'swaps', 'data-fetch'],
+  metadataURI: 'ipfs://...',
+});
+
+// Verify another agent's identity before task delegation
+const isValid = await identity.validate('0xAgentAddress');
+```
+
+### 6. Mutual Stake Escrow
+
+Reciprocal collateral for agent-to-agent tasks. Both parties stake before work begins; funds release on verified completion.
+
+```typescript
+import { MutualStakeEscrow } from 'agentwallet-sdk';
+
+const escrow = new MutualStakeEscrow({ chain: 'base', walletClient });
+
+const { escrowId } = await escrow.create({
+  counterparty: '0x...',
+  token: '0xUSDC',
+  stakeAmount: 100_000_000n,         // 100 USDC (6 decimals)
+  taskHash: '0x...',
+  deadline: Math.floor(Date.now() / 1000) + 86400,
+});
+
+// Release on verified completion
+await escrow.release(escrowId, proofOfWork);
+```
+
+### 7. Optimistic Escrow
+
+Time-locked escrow with challenge window. Funds release automatically after the lock period unless disputed.
+
+```typescript
+import { OptimisticEscrow } from 'agentwallet-sdk';
+
+const escrow = new OptimisticEscrow({ chain: 'base', walletClient });
+
+const { escrowId } = await escrow.create({
+  beneficiary: '0x...',
+  token: '0xUSDC',
+  amount: 50_000_000n,
+  lockPeriod: 3600,                  // 1-hour challenge window
+  taskHash: '0x...',
+});
+```
+
+### 8. AP2 Protocol — Agent-to-Agent Task Delegation
+
+Delegate tasks to sub-agents with automatic payment on completion.
+
+```typescript
+import { AP2Client } from 'agentwallet-sdk';
+
+const ap2 = new AP2Client({ chain: 'base', walletClient });
+
+const { taskId } = await ap2.delegate({
+  agent: '0xSubAgentAddress',
+  task: { type: 'data-fetch', params: { url: 'https://...' } },
+  maxPayment: 5_000_000n,            // 5 USDC ceiling
+  escrowType: 'mutual-stake',
+});
+
+const result = await ap2.awaitCompletion(taskId);
+```
+
+### 9. Gas Sponsorship (ERC-4337 Paymaster)
+
+Sponsor gas for agent transactions so end users never hold ETH.
+
+```typescript
+import { createWallet } from 'agentwallet-sdk';
+
+const wallet = createWallet({
+  accountAddress: '0x...',
+  chain: 'base',
+  walletClient,
+  gasSponsorship: {
+    enabled: true,
+    paymasterUrl: 'https://...',     // ERC-4337 paymaster endpoint
+  },
+});
+```
+
+### 10. Fiat Onramp
+
+Opt-in fiat-to-crypto conversion for wallets that need funding without manual crypto transfers.
+
+```typescript
+import { FiatOnramp } from 'agentwallet-sdk';
+
+const onramp = new FiatOnramp({ chain: 'base', walletClient });
+
+const { sessionUrl } = await onramp.createSession({
+  targetToken: 'USDC',
+  targetAmount: 100,                 // USD
+  walletAddress: wallet.address,
+});
+// Redirect agent operator to sessionUrl for KYC/payment
+```
+
+### 11. On-Chain Settlement
+
+Finalize multi-party payment flows with cryptographic settlement proof.
+
+```typescript
+import { Settlement } from 'agentwallet-sdk';
+
+const settlement = new Settlement({ chain: 'base', walletClient });
+
+await settlement.finalize({
+  taskId: '0x...',
+  parties: ['0xAgent1', '0xAgent2'],
+  amounts: [80_000_000n, 20_000_000n],
+  proofHash: '0x...',
+});
+```
+
+## ClawPowers Enhancement
+
+When `~/.clawpowers/` runtime is initialized, agent-payments gains persistent tracking across all transaction types.
+
+**Persistent Payment Ledger:**
+
+```bash
+bash runtime/persistence/store.sh set "ledger:total_spent_today" "$(date +%Y-%m-%d):0.047"
+bash runtime/persistence/store.sh list "payment:*:amount" | awk -F: '{sum += $NF} END {print "Total: $" sum}'
+```
+
+**Multi-Metric Session Tracking:**
+
+```bash
+bash runtime/metrics/collector.sh record \
+  --skill agent-payments \
+  --outcome success \
+  --notes "payments: 3, swaps: 1, bridges: 0, session_spend: $0.047, limit: $5.00"
+```
+
+**Spending Analytics:**
+
+`runtime/feedback/analyze.sh` computes:
+- Total spend per day/week/month across all transaction types
+- Most expensive APIs (payment frequency × amount)
+- Swap slippage vs. configured tolerance
+- Bridge utilization and latency
+- Escrow open/close ratio
+- Limit hit rate (how often limits block payments)
+- Payment success rate (failed on-chain transactions)
+
+## Security
+
+**Private Key Security:**
+- Keys are encrypted at rest via the ERC-6551 NFT-bound wallet
+- Never printed to logs or surfaces
+- Passphrase required to decrypt
+
+**Spending Limit Enforcement:**
+- `setSpendPolicy()` writes limits to the smart contract — the agent cannot override them
+- `agentExecute()` queries the contract before submitting any transaction
+- Over-limit transactions are queued, not silently dropped
+
+**Audit Trail:**
+- Every transaction generates an on-chain hash
+- Payment logs in `~/.clawpowers/state/` are append-only
+- Session spend is tracked against daily/session limits
+
+## Anti-Patterns
+
+| Anti-Pattern | Why It Fails | Correct Approach |
+|-------------|-------------|-----------------|
+| No spending limits configured | Unlimited liability, potential wallet drain | Always call `setSpendPolicy()` before `agentExecute()` |
+| Hardcoding token addresses | Chain upgrades break integrations | Use `BASE_TOKENS`, `ARBITRUM_TOKENS`, etc. from the SDK |
+| Skipping identity validation before AP2 delegation | Funds sent to unverified agent | Call `identity.validate()` before delegating tasks |
+| Using optimistic escrow for high-value tasks | Challenge window may be too short | Use mutual stake escrow for tasks above risk threshold |
+| Retrying failed payments without human review | Double-charge or infinite payment loop | Manual review required for any payment failure |
+| Paying without verifying server response | Payment sent, service not rendered | Always check response status after x402 payment |
+| Not logging swap/bridge transactions | No audit trail for reconciliation | Log every transaction hash via runtime persistence |
+| Swapping with default slippage on volatile pairs | Front-run or excessive slippage | Set explicit `slippageBps` based on pair volatility |
+
+## Protocol Fees (ClawPowers Only)
+
+**These fees apply ONLY when using agent-payments through ClawPowers.** The standalone [agentwallet-sdk](https://www.npmjs.com/package/agentwallet-sdk) on npm is free with zero fees. You always have the choice to use the SDK directly.
+
+ClawPowers agent-payments provides auto-configured wallets, guided payment flows, spending analytics, and runtime tracking. A transparent protocol fee applies:
+
+| Monthly Volume | Fee |
+|---------------|-----|
+| $0 - $1,000 | 0.77% |
+| $1,001 - $10,000 | 0.50% |
+| $10,001 - $100,000 | 0.25% |
+| $100,000+ | Custom |
+
+Fees are:
+- Applied at the protocol level (smart contract), not application level
+- Visible in every transaction before confirmation
+- Competitive with alternatives (MetaMask 0.875%, Stripe 2.9%, Nory 1%)
+- Zero if you don't use agent-payments — the rest of ClawPowers is completely free
+
+Fee collector: `0xff86829393C6C26A4EC122bE0Cc3E466Ef876AdD` (all EVM chains)
+
+## References
+
+- [agentwallet-sdk on npm](https://www.npmjs.com/package/agentwallet-sdk)
+- [agentpay-mcp on GitHub](https://github.com/up2itnow0822/agentpay-mcp)
+- [x402 protocol specification](https://x402.org)
+- [ERC-6551 Token Bound Accounts](https://eips.ethereum.org/EIPS/eip-6551)
+- [ERC-4337 Account Abstraction](https://eips.ethereum.org/EIPS/eip-4337)
+- [CCTP V2 Documentation](https://developers.circle.com/stablecoins/cctp-getting-started)
+- [NVIDIA NeMo Agent Toolkit integration](https://github.com/NVIDIA/NeMo-Agent-Toolkit-Examples/pull/17)
+
+## Underlying Infrastructure
+
+This skill is powered by [agentwallet-sdk v6.0](https://www.npmjs.com/package/agentwallet-sdk) — full multi-chain agent wallet stack:
+
+- **ERC-6551 Non-custodial wallets** — Agent owns its keys via NFT-bound wallet on 11 chains
+- **Smart-contract spending policies** — Per-token, per-period limits enforced at contract level
+- **x402 multi-chain payments** — Auto network detection across Base, Arbitrum, Optimism, and more
+- **Uniswap V3 swaps** — Base, Arbitrum, Optimism, Polygon with chain-specific token registries
+- **CCTP V2 bridge** — EVM↔EVM and EVM↔Solana USDC bridging
+- **ERC-8004 Agent Identity** — Identity, Reputation, and Validation registries
+- **Mutual Stake & Optimistic Escrow** — Reciprocal and time-locked collateral for agent tasks
+- **AP2 Protocol** — Agent-to-agent task delegation and payment
+- **ERC-4337 Gas Sponsorship** — Paymaster integration for gasless transactions
+- **Fiat Onramp** — Opt-in fiat-to-crypto conversion
+- **On-chain Settlement** — Cryptographic finalization of multi-party payment flows
+
+Integrated into [NVIDIA's official NeMo Agent Toolkit](https://github.com/NVIDIA/NeMo-Agent-Toolkit-Examples/pull/17).

package/skills/brainstorming/SKILL.md

@@ -0,0 +1,233 @@
+---
+name: brainstorming
+description: Structured ideation with convergence protocol. Activate when exploring solutions, designing architecture, or choosing between approaches.
+version: 1.0.0
+requires:
+  tools: []
+  runtime: false
+metrics:
+  tracks: [ideas_generated, ideas_pursued, convergence_time, decision_quality]
+  improves: [ideation_breadth, convergence_threshold, idea_linking]
+---
+
+# Brainstorming
+
+## When to Use
+
+Apply this skill when:
+
+- A problem has multiple valid solution approaches and you need to choose
+- You're designing architecture and haven't committed to a direction
+- Someone asks "what should we do?" or "what are our options?"
+- You've been executing in one direction and need to verify it's still the right one
+- A constraint has changed and the previous approach may no longer be optimal
+- Creative solutions are needed (not just standard patterns)
+
+**Skip when:**
+- The solution is already determined and execution is what's needed
+- There's only one viable approach given the constraints
+- You need to converge immediately — brainstorming requires divergence time
+
+**Decision tree:**
+```
+Is the right approach known?
+├── Yes → execute it
+└── No  → Is this a known problem pattern?
+          ├── Yes → Apply known solution, validate fit with constraints
+          └── No  → brainstorming ← YOU ARE HERE
+```
+
+## Core Methodology
+
+Brainstorming has two phases: **diverge** (generate many ideas without judgment) and **converge** (evaluate, select, refine). Never mix them — evaluating during generation kills ideas before they can combine into something better.
+
+### Phase 1: Diverge
+
+**Rule:** No evaluation during divergence. Every idea is noted, even obviously bad ones.
+
+**Seed the space with different lenses:**
+
+1. **First-principles lens** — "If we built this from scratch knowing only the requirements, what would we build?"
+2. **Constraint-removal lens** — "If [constraint] didn't exist, what's the best solution? Now how do we get closer to it?"
+3. **Analogy lens** — "How does [analogous problem domain] solve this?"
+4. **Inversion lens** — "What would make this maximally bad? Now invert each item."
+5. **Extreme lens** — "What's the simplest possible approach? What's the most powerful?"
+6. **Time lens** — "What solution would we regret not choosing in 2 years?"
+
+**Target:** 6-12 distinct ideas before evaluation. If you have fewer than 5, you've stopped too early.
+
+**Divergence output format:**
+
+```markdown
+## Idea 1: [Name]
+[2-3 sentences: what it is, how it works, why it might be good]
+Rough feasibility: [High/Medium/Low]
+
+## Idea 2: [Name]
+...
+```
+
+### Phase 2: Rapid Pre-Filter
+
+After divergence, apply a quick filter before full evaluation:
+
+**Pre-filter criteria:**
+- Feasible within current constraints? (Hard blocker: eliminate)
+- Reversible if wrong? (Irreversible = higher bar to choose)
+- Team can execute? (Skill gap = risk, not elimination)
+
+Eliminate only ideas that fail hard feasibility. Keep everything else — your "bad" ideas might combine with your "good" ones.
+
+### Phase 3: Evaluate Remaining Ideas
+
+For each surviving idea, score on:
+
+| Criterion | Weight | Description |
+|-----------|--------|-------------|
+| Correctness | 30% | Solves the actual problem completely |
+| Maintainability | 20% | Team can reason about and change it |
+| Performance | 15% | Meets performance requirements |
+| Reversibility | 15% | Can be undone if wrong |
+| Time to implement | 10% | Fits within timeline constraint |
+| Risk | 10% | Known unknowns and failure modes |
+
+**Scoring:** 1-5 per criterion. Weighted total = decision score.
+
+This scoring is a forcing function, not a formula. If the scores conflict with your gut, investigate the gut feeling — it may be capturing a criterion you haven't named.
+
+### Phase 4: Convergence Decision
+
+**Select the highest-scoring idea** unless:
+- The second-highest is within 10% and significantly more reversible
+- The highest-scoring idea has an unmitigated risk that could invalidate the entire effort
+- The team has strong capability gaps that make the highest-scoring idea genuinely infeasible
+
+**Convergence output:**
+
+```markdown
+## Decision: [Idea Name]
+
+**Rationale:** [Why this over the alternatives]
+**Key trade-off accepted:** [What we're giving up and why that's okay]
+**Reversibility:** [Can we change this later? At what cost?]
+**Risk mitigations:**
+- [Risk 1]: [Mitigation]
+- [Risk 2]: [Mitigation]
+
+## Discarded Alternatives
+- [Idea N]: Eliminated because [specific reason]
+```
+
+The discarded alternatives section is important — it prevents re-litigating the same options in future discussions.
+
+### Phase 5: Spike Plan (if needed)
+
+If the winning idea has a technical unknown, plan a spike (time-boxed experiment):
+
+```markdown
+## Spike: Validate [unknown assumption]
+
+**Question:** [Specific question this spike answers]
+**Method:** [How to test it]
+**Time box:** [Maximum time, then decide based on results]
+**Pass criteria:** [What result confirms the approach is viable]
+**Fail criteria:** [What result means we choose the fallback]
+**Fallback:** [Idea #2 from the evaluation]
+```
+
+Spikes that don't have a fallback are bets, not spikes.
+
+## ClawPowers Enhancement
+
+When `~/.clawpowers/` runtime is initialized:
+
+**Cross-Session Idea Persistence:**
+
+Ideas don't disappear when the session ends:
+
+```bash
+# Save ideas from session
+bash runtime/persistence/store.sh set "brainstorm:auth-rate-limiting:idea1" "Token bucket with Redis"
+bash runtime/persistence/store.sh set "brainstorm:auth-rate-limiting:idea2" "Fixed window with DB"
+bash runtime/persistence/store.sh set "brainstorm:auth-rate-limiting:decision" "Token bucket with Redis"
+bash runtime/persistence/store.sh set "brainstorm:auth-rate-limiting:discarded" "Fixed window: stale at window boundary"
+
+# Recall in future session
+bash runtime/persistence/store.sh list "brainstorm:auth-rate-limiting:*"
+```
+
+This prevents re-debating decisions already made and provides context when the approach needs revisiting.
+
+**Pattern Linking:**
+
+After 10+ brainstorming sessions, `runtime/feedback/analyze.sh` identifies:
+- Which lenses generate the most pursued ideas (your most productive divergence strategies)
+- Common discarded idea reasons (helps pre-filter faster)
+- Idea-to-outcome correlation (were your decisions good?)
+
+**Idea Quality Tracking:**
+
+```bash
+bash runtime/metrics/collector.sh record \
+  --skill brainstorming \
+  --outcome success \
+  --notes "rate-limiting: 7 ideas, 1 spike, decision in 25 min"
+```
+
+After execution, mark whether the brainstorming decision held up:
+```bash
+bash runtime/persistence/store.sh set "brainstorm:auth-rate-limiting:outcome" "decision_held"
+# or
+bash runtime/persistence/store.sh set "brainstorm:auth-rate-limiting:outcome" "pivoted:reason"
+```
+
+This feeds the RSI loop — which ideas look good in brainstorming but fail in practice?
+
+## Anti-Patterns
+
+| Anti-Pattern | Why It Fails | Correct Approach |
+|-------------|-------------|-----------------|
+| Evaluating during divergence | Kills combination ideas before they form | Strict phase separation |
+| Stopping at 2-3 ideas | First ideas are obvious; breakthroughs are later | Force 6-12 before evaluating |
+| Skipping the spike | Unknown assumption bites you mid-implementation | Spike anything technically uncertain |
+| No fallback on spike | If spike fails, you're stuck | Always name the fallback before spiking |
+| Consensus brainstorming | Group thinks converges to average | Diverge individually, converge together |
+| Re-opening decided questions | Litigating old decisions halts progress | Document discarded alternatives with reasons |
+| Brainstorming without constraints | Unconstrained ideas aren't implementable | State constraints at the start of divergence |
+
+## Examples
+
+### Example 1: Architecture Decision
+
+**Question:** How should we handle cross-service communication?
+
+**Divergence:**
+1. REST HTTP calls (synchronous, direct)
+2. Message queue (async, decoupled) — Kafka, RabbitMQ, Redis Streams
+3. gRPC (typed, fast, binary protocol)
+4. GraphQL federation
+5. Event sourcing + event bus
+6. Shared database (anti-pattern but option)
+7. Service mesh with mTLS (Istio)
+
+**Pre-filter:** Option 6 (shared DB) eliminated — violates service isolation. All others survive.
+
+**Evaluation scores:** REST: 72pts | Message queue: 85pts | gRPC: 78pts | Others < 70pts
+
+**Decision:** Message queue (Kafka) — highest score, fully decoupled, reversible per service.
+
+**Spike:** Can our team operate Kafka? → 2-hour spike → yes, managed Confluent resolves ops burden.
+
+### Example 2: Feature Design
+
+**Question:** How should users specify recurring events?
+
+**Divergence (constraint-removal):**
+1. cron syntax (powerful, opaque to non-technical users)
+2. Natural language parser ("every Monday at 9am")
+3. Visual calendar picker (intuitive, limited power)
+4. RRULE (RFC 5545 standard, complex)
+5. Predefined presets + custom exception
+6. Wizard with structured questions
+
+**Convergence:** Option 5 (presets + exceptions) — covers 90% of cases simply, 10% with power.