wicked-garden 12.27.0

package/skills/platform/health/refs/sources.md

@@ -0,0 +1,302 @@
+---
+phase_relevance: ["build", "review", "operate"]
+archetype_relevance: ["*"]
+---
+# Observability Capability Discovery Patterns
+
+Detailed patterns for discovering and integrating with observability capabilities.
+
+## Discovery Process
+
+### Step 1: List Available Servers
+
+```bash
+# (check IDE MCP server list for available integrations)
+```
+
+Returns list of available MCP servers with names and descriptions.
+
+### Step 2: Match by Capability Indicators
+
+Scan server descriptions and available resources to identify capabilities. Look for these indicators:
+
+```markdown
+## error-tracking capability
+- Keywords: error, exception, crash, tracking, reporting, monitoring
+- Resource patterns: errors, exceptions, issues, events
+- Common features: stack traces, error grouping, user impact
+
+## apm capability
+- Keywords: apm, performance, monitoring, observability, application
+- Resource patterns: metrics, services, transactions, traces
+- Common features: latency metrics, throughput, service health
+
+## logging capability
+- Keywords: log, logging, search, aggregation, analytics
+- Resource patterns: logs, events, queries, searches
+- Common features: log search, filtering, aggregation
+
+## tracing capability
+- Keywords: trace, tracing, distributed, spans, requests
+- Resource patterns: traces, spans, operations, services
+- Common features: request flow, service dependencies, latency breakdown
+
+## telemetry capability
+- Keywords: metrics, telemetry, instrumentation, time-series, monitoring
+- Resource patterns: metrics, counters, gauges, histograms
+- Common features: custom metrics, instrumentation, alerts
+```
+
+### Step 3: Query Each Source
+
+For each discovered capability, query for relevant health data based on what the capability provides.
+
+## error-tracking Capability Integration
+
+When you discover a server with error-tracking capability, query for these data points:
+
+### Common Query Patterns
+
+```markdown
+1. Get error rate for recent time period
+2. List top errors by frequency
+3. Get errors for specific release/deployment
+4. User/session impact metrics
+5. Error trends over time
+6. New vs recurring error classification
+```
+
+### Health Indicators to Extract
+
+- **Error Rate**: Current vs baseline comparison
+- **Error Distribution**: By severity, type, service
+- **User Impact**: Sessions/users affected
+- **Error Trends**: Increasing, decreasing, or stable
+- **New Errors**: First-time occurrences vs recurring
+- **Resolution Metrics**: Time to detect, time to resolve
+
+### Capability Identification
+
+A server has error-tracking capability if it provides:
+- Error/exception data with timestamps
+- Stack traces or error details
+- Error grouping or classification
+- Impact metrics (users, sessions, requests)
+- Time-series error data
+
+## apm Capability Integration
+
+When you discover a server with apm capability, query for these data points:
+
+### Common Query Patterns
+
+```markdown
+1. Service latency percentiles (p50, p95, p99)
+2. Request throughput and error rates
+3. Resource utilization (CPU, memory, connections)
+4. Service health and availability
+5. Active alerts and monitors
+6. Transaction performance breakdown
+7. External dependency health
+```
+
+### Health Indicators to Extract
+
+- **Latency Metrics**: p50, p95, p99 compared to SLOs
+- **Throughput**: Requests per second, trends
+- **Error Rates**: By service, endpoint, or transaction
+- **Resource Utilization**: CPU, memory, disk, network
+- **Availability**: Uptime percentage, downtime events
+- **Alert Status**: Active alerts, severity levels
+- **Performance Scores**: Apdex, user experience metrics
+
+### Capability Identification
+
+A server has apm capability if it provides:
+- Service-level performance metrics
+- Request/transaction monitoring
+- Latency and throughput data
+- Service health indicators
+- Resource utilization metrics
+- Optional: AI-detected anomalies or problems
+
+## logging Capability Integration
+
+When you discover a server with logging capability, query for these data points:
+
+### Common Query Patterns
+
+```markdown
+1. Search for error/warning patterns in time range
+2. Count of log events by severity level
+3. Log volume trends and anomalies
+4. Correlation queries across services
+5. Full-text search for specific patterns
+6. Aggregation by service, host, or component
+```
+
+### Health Indicators to Extract
+
+- **Error Log Frequency**: Count of ERROR level logs
+- **Warning Trends**: Count and patterns of warnings
+- **Log Volume**: Baseline vs current, detect anomalies
+- **Pattern Detection**: Recurring error messages
+- **Service Correlation**: Related logs across services
+- **Alert Status**: If logging platform has alerting
+
+### Capability Identification
+
+A server has logging capability if it provides:
+- Log search and filtering
+- Severity/level-based queries
+- Time-range queries
+- Log aggregation and counting
+- Full-text search across logs
+- Optional: Log correlation, alerting
+
+## tracing Capability Integration
+
+When you discover a server with tracing capability, query for these data points:
+
+### Common Query Patterns
+
+```markdown
+1. Traces with errors in time range
+2. Service operation latencies
+3. Service dependency graph/map
+4. Slow traces exceeding threshold
+5. Service-to-service call patterns
+6. Trace success/failure rates
+7. Span duration analysis
+```
+
+### Health Indicators to Extract
+
+- **Trace Error Rate**: Percentage of failed traces
+- **Latency Distribution**: p50, p95, p99 from trace data
+- **Service Dependencies**: Call graph, dependency health
+- **Slow Operations**: Operations exceeding SLO
+- **Success Rate**: Successful vs failed requests
+- **Bottlenecks**: Slowest services or operations
+
+### Capability Identification
+
+A server has tracing capability if it provides:
+- Distributed trace data with spans
+- Service dependency information
+- Request timing and latency data
+- Trace filtering (by service, time, status)
+- Span-level detail and attributes
+- Optional: TraceQL or similar query language
+
+## telemetry Capability Integration
+
+When you discover a server with telemetry capability, query for these data points:
+
+### Common Query Patterns
+
+```markdown
+1. Time-series metrics queries (rates, histograms)
+2. Custom metric values and trends
+3. Alert rule status (firing, pending, resolved)
+4. Service health indicators (up/down status)
+5. Resource metrics (CPU, memory, network)
+6. Application-specific instrumentation
+7. Histogram percentile calculations
+```
+
+### Health Indicators to Extract
+
+- **Custom Metrics**: Application-defined metrics vs thresholds
+- **Service Status**: Up/down indicators
+- **Alert Status**: Active alerts from metrics
+- **Resource Metrics**: Infrastructure health indicators
+- **Rate Metrics**: Request rates, error rates, etc.
+- **Histogram Data**: Latency percentiles from histograms
+
+### Capability Identification
+
+A server has telemetry capability if it provides:
+- Time-series metric data
+- Custom instrumentation support
+- Metric queries (PromQL or similar)
+- Metric aggregation and calculations
+- Alert rules based on metrics
+- Optional: Unified observability (traces + metrics + logs)
+
+## Graceful Fallback
+
+When no integrations available, fall back to local analysis:
+
+### Code-Based Health Assessment
+
+```bash
+# Search for error patterns in code
+wicked-garden:search error, exception, throw patterns
+
+# Check for TODO/FIXME comments
+wicked-garden:search TODO, FIXME, HACK
+
+# Review recent commits
+git log --since="24 hours ago"
+
+# Check for common anti-patterns
+wicked-garden:search catch without handling, silent failures
+```
+
+**Provide Guidance**:
+```markdown
+No observability integrations detected.
+
+Health assessment limited to static code analysis.
+
+**Recommendations**:
+1. Install error-tracking capability (e.g., via MCP)
+2. Install apm capability (e.g., via MCP)
+3. Install logging capability (e.g., via MCP)
+
+Benefits:
+- Real-time error tracking
+- Performance monitoring
+- Production incident response
+- Deployment correlation
+```
+
+## Multi-Capability Correlation
+
+When multiple capabilities are available, correlate for richer insights:
+
+```markdown
+### Correlation Example
+
+**From error-tracking capability**: 45 errors/min "Database connection timeout"
+**From apm capability**: user-service latency p95: 2.3s (was 200ms)
+**From logging capability**: Log pattern "ConnectionPool exhausted" started 14:25 UTC
+**From deployment tracking**: Deployment user-service-v2.3.1 at 14:23 UTC
+
+**Correlated Health View**:
+- Issue: Database connection pool exhaustion
+- Started: 2 minutes after deployment
+- Root Cause: Connection pool size reduced in v2.3.1
+- Impact: 45 errors/min, 2500 users affected
+- Recommendation: Rollback to v2.3.0
+```
+
+## Health Scoring Algorithm
+
+Aggregate health from multiple sources:
+
+```markdown
+Health Score = weighted average of:
+- Error Rate Score (40%): (baseline / current) * 100
+- Latency Score (30%): (SLO / actual) * 100
+- SLO Compliance (20%): percentage of SLOs met
+- Alert Status (10%): 100 if no alerts, 50 if warnings, 0 if critical
+
+Overall Status:
+- HEALTHY: Score >= 90
+- DEGRADED: Score 70-89
+- CRITICAL: Score < 70
+```
+
+Adjust weights based on system priorities (e.g., error rate more critical than latency for some systems).

package/skills/platform/incident/refs/incident.md

@@ -0,0 +1,136 @@
+# Incident Response Rubric
+
+Rapid triage → investigate → mitigate → resolve → follow-up for production incidents.
+
+> Scope: rapid active triage — root cause, blast radius, remediation steps.
+> To log an incident against a crew project with traceability, use `/wicked-garden:crew:incident`.
+
+## Phase 1: Triage (First 5 Minutes)
+
+**GOAL**: Understand scope and severity.
+
+- [ ] What is broken? (specific symptoms, error messages)
+- [ ] When did it start? (timestamp)
+- [ ] Who is affected? (users, services, regions)
+- [ ] What is the impact? (revenue, user experience, data)
+- [ ] Is it getting worse? (trend direction)
+
+## Phase 2: Stabilize (Next 15 Minutes)
+
+**GOAL**: Stop the bleeding.
+
+- [ ] Can we roll back the last deploy?
+- [ ] Can we fail over to a secondary?
+- [ ] Can we disable the feature flag?
+- [ ] Can we scale resources horizontally?
+- [ ] Do we need to page more people?
+
+## Phase 3: Investigate (Parallel to Stabilization)
+
+**GOAL**: Find root cause.
+
+Discover available observability sources via `ListMcpResourcesTool`:
+- Priority 1: **error-tracking** (Sentry/Rollbar) — error rates, stack traces, affected users
+- Priority 2: **logging** (Splunk/Elastic) — error messages, request IDs
+- Priority 3: **tracing** (Jaeger/Zipkin) — request flow, latency breakdown
+- Priority 4: **apm** (Datadog/New Relic) — service health metrics
+
+Correlate with recent changes:
+```bash
+git log --oneline --since="2 hours ago"
+git log --oneline -10 -- {affected_path}
+```
+
+## Phase 4: Resolve
+
+- [ ] Implement fix or rollback
+- [ ] Verify issue resolved (error rate back to baseline)
+- [ ] Monitor for 15+ minutes for recurrence
+- [ ] Communicate status to stakeholders
+
+## Phase 5: Follow-Up
+
+- [ ] Document incident timeline
+- [ ] Identify contributing factors
+- [ ] Create action items (missing circuit breaker, missing test, etc.)
+- [ ] Update runbooks
+
+## Severity Classification
+
+| Severity | Impact | Response | Comms |
+|----------|--------|----------|-------|
+| SEV1/P0 | Complete outage or data loss | Immediate page | Every 30min |
+| SEV2/P1 | Major feature degraded, significant impact | Within 15min | Every hour |
+| SEV3/P2 | Minor feature broken, limited impact | Business hours | Daily |
+| SEV4/P3 | Cosmetic, very limited | Next sprint | Weekly |
+
+## Common Incident Patterns
+
+### Deploy-Related
+Signals: error spike immediately after deploy, new error messages.
+Response: identify deploy time → compare pre/post error rates → rollback if >5x baseline.
+
+### Traffic Spike
+Signals: latency up across services, resource exhaustion.
+Response: scale horizontally → enable rate limiting → identify traffic source.
+
+### Cascading Failure
+Signals: one service failure causing fan-out errors.
+Response: trace to root failing service → isolate it → fix root → let dependents recover.
+
+### Data-Related
+Signals: errors related to data format, started after migration.
+Response: identify bad data via errors → quarantine → fix validation at ingestion.
+
+## Output Format
+
+```markdown
+## Incident Triage
+
+**Severity**: [SEV1 | SEV2 | SEV3 | SEV4]
+**Status**: [INVESTIGATING | IDENTIFIED | MITIGATING | RESOLVED]
+**Started**: {timestamp}
+**Duration**: {elapsed}
+
+### Impact
+- **Users affected**: {count/percentage}
+- **Services affected**: {list}
+- **Business impact**: {description}
+
+### Timeline
+| Time | Event |
+|------|-------|
+| {time} | {event} |
+
+### Root Cause
+{identified or suspected cause}
+
+### Correlation
+- **Deployment**: {recent deploy if relevant}
+- **Changes**: {relevant code changes}
+
+### Blast Radius
+{list of affected components}
+
+### Mitigation
+**Immediate**:
+1. {action — e.g., `kubectl rollout undo deployment/{name}`}
+
+**After stabilization**:
+1. {fix}
+2. {preventive measure}
+
+### Rollback Decision
+{recommendation with criteria — RECOMMEND ROLLBACK / RECOMMEND FORWARD FIX}
+```
+
+## Communication Templates
+
+**Initial (first 5 min)**:
+`[INCIDENT] {Service} — {Brief}. Severity: P{N}. Started: {time}. Status: Investigating.`
+
+**Update (every 30min P0, hourly P1)**:
+`[UPDATE] {Service}. Status: {investigating/mitigating/resolved}. Progress: {done}. Next: {trying}. ETA: {unknown/time}.`
+
+**Resolution**:
+`[RESOLVED] {Service}. Duration: {total}. Root cause: {brief}. Prevention: {action items}. Postmortem: {link / "coming in 48h"}.`

package/skills/platform/infra/refs/infra.md

@@ -0,0 +1,104 @@
+# Infrastructure-as-Code Review Rubric
+
+Review IaC and cloud architecture for security, cost, HA, and best-practice posture.
+Covers: Terraform/OpenTofu, CloudFormation, Pulumi, Kubernetes manifests, docker-compose.
+
+## Step 1: Discover IaC Files
+
+Parse `$ARGUMENTS` (path or `scan`). When `scan`, discover:
+```bash
+find . -name "*.tf" -o -name "*.tfvars" 2>/dev/null
+find . -name "cloudformation*.yaml" -o -name "cloudformation*.json" 2>/dev/null
+find . -name "pulumi.yaml" 2>/dev/null
+find . -name "*.k8s.yaml" -o -path "*/kubernetes/*.yaml" 2>/dev/null
+find . -name "docker-compose*.yaml" -o -name "docker-compose*.yml" 2>/dev/null
+```
+
+Detect platform (AWS/GCP/Azure/K8s/Docker) from content.
+
+## Step 2: Security Matrix
+
+- [ ] No hardcoded credentials or secrets (use Secrets Manager / KMS / env vars)
+- [ ] IAM: least-privilege — no `*` actions, no `*` resources without justification
+- [ ] Network: security groups / firewall rules restrict ingress; no `0.0.0.0/0` on sensitive ports
+- [ ] Encryption at rest: storage volumes, DB, S3 buckets encrypted
+- [ ] Encryption in transit: TLS enabled on all endpoints
+- [ ] Public exposure: no inadvertently public buckets, DBs, or APIs
+
+## Step 3: Cost Optimization
+
+- [ ] Instance/resource sizing justified by actual load (not over-provisioned)
+- [ ] Unused or orphaned resources (old snapshots, unattached volumes)
+- [ ] Spot/preemptible instances for non-critical workloads
+- [ ] S3/GCS lifecycle policies for infrequently accessed data
+- [ ] Reserved instances / savings plans for steady-state compute
+
+## Step 4: High Availability & DR
+
+- [ ] Multi-AZ deployment for stateful services
+- [ ] Auto-scaling configured for compute tier
+- [ ] Database: Multi-AZ / read replicas / failover configured
+- [ ] Load balancer with health checks
+- [ ] Backup strategy defined and tested
+- [ ] DR plan: RTO and RPO documented
+
+## Step 5: Platform Best Practices
+
+### Terraform/OpenTofu
+- [ ] Remote state with locking (S3+DynamoDB, GCS, Terraform Cloud)
+- [ ] Version constraints on providers
+- [ ] Variables parameterized (no hardcoded values in `.tf`)
+- [ ] Modules used for reusability
+- [ ] Resource tagging (env, team, cost-center)
+
+### Kubernetes
+- [ ] Resource `requests` and `limits` on all containers
+- [ ] `livenessProbe` and `readinessProbe` configured
+- [ ] RBAC: minimal `ServiceAccount` permissions
+- [ ] Network policies defined
+- [ ] ConfigMaps/Secrets for configuration (no env vars with secrets in manifests)
+
+### Docker Compose
+- [ ] No `privileged: true` unless required
+- [ ] Port bindings limited to necessary ports
+- [ ] Named volumes for persistent data
+- [ ] Health checks on dependent services
+
+## Output Format
+
+```markdown
+## Infrastructure Review: {platform}
+
+**IaC Tool**: {Terraform | CloudFormation | Pulumi | K8s | Docker Compose}
+**Files reviewed**: {list}
+
+### Resource Inventory
+{table: resource type, name, region/zone, sizing}
+
+### Security Matrix
+| Control | Status | Evidence / Issue |
+|---------|--------|-----------------|
+| No hardcoded secrets | ✓/✗ | {location if ✗} |
+| IAM least-privilege | ✓/✗ | {issue if ✗} |
+| Network segmentation | ✓/✗ | {issue if ✗} |
+| Encryption at rest | ✓/✗ | {issue if ✗} |
+| Encryption in transit | ✓/✗ | {issue if ✗} |
+
+### Cost Opportunities
+| Item | Current | Recommendation | Est. Savings |
+|------|---------|---------------|-------------|
+| {resource} | {spec} | {change} | ${amount}/mo |
+
+### HA Gaps
+{list of missing HA components with risk level}
+
+### Prioritized Fixes
+**Critical** (security/data-loss risk):
+1. {issue} — {file:line} — {fix}
+
+**High** (HA/cost):
+2. {issue} — {fix}
+
+**Improvements**:
+3. {suggestion}
+```

package/skills/platform/observability/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: observability
+description: |
+  Use when monitoring or diagnosing the wicked-garden plugin ecosystem — health probes, contract assertions,
+  hook traces, error pattern detection, and APM/logging/metrics toolchain discovery.
+  NOT for distributed tracing across services (use the platform:traces command) or audit evidence (use platform/audit).
+phase_relevance: ["build", "review", "operate"]
+archetype_relevance: ["*"]
+---
+
+# Observability Skill
+
+Monitor and diagnose the wicked-garden plugin ecosystem — health probes, contract assertions, and hook execution traces.
+
+## Quick Start
+
+```bash
+# Check ecosystem health
+/wicked-garden:platform:health
+
+# Query recent hook traces
+/wicked-garden:platform:traces --tail 20
+
+# Validate script output contracts
+/wicked-garden:platform:assert
+```
+
+## Commands
+
+| Command | Purpose |
+|---------|---------|
+| `/wicked-garden:platform:health` | Run health probes against plugins |
+| `/wicked-garden:platform:traces` | Query hook execution traces for the session |
+| `/wicked-garden:platform:assert` | Validate script outputs against declared schemas |
+
+## Three Pillars
+
+### 1. Health Probes
+
+Validate ecosystem integrity by checking plugin structure, hook bindings, and script availability.
+
+```bash
+# All plugins
+/wicked-garden:platform:health
+
+# Single plugin, machine-readable
+/wicked-garden:platform:health --plugin wicked-garden --json
+```
+
+Exit codes: `0` = healthy, `1` = warnings, `2` = failures.
+
+### 2. Hook Traces
+
+Every hook execution is traced with timing, exit codes, and silent failure detection. Query traces to diagnose issues.
+
+```bash
+# Last 10 traces
+/wicked-garden:platform:traces --tail 10
+
+# Only silent failures (exit 0 but unexpected output)
+/wicked-garden:platform:traces --silent-only
+
+# Trace stats
+/wicked-garden:platform:traces --stats
+```
+
+### 3. Contract Assertions
+
+Validate that plugin scripts return data matching their declared JSON schemas.
+
+```bash
+# Run all assertions
+/wicked-garden:platform:assert
+
+# Single plugin
+/wicked-garden:platform:assert --plugin wicked-garden
+```
+
+Schemas live in `schemas/{plugin}/{script}.json`.
+
+## Common Diagnostic Flows
+
+### "Something seems broken"
+1. `/wicked-garden:platform:health` — check structural integrity
+2. `/wicked-garden:platform:traces --silent-only` — find silent failures
+3. `/wicked-garden:platform:assert` — validate output contracts
+
+### "Hook didn't fire"
+1. `/wicked-garden:platform:traces --tail 20` — check if hook was invoked
+2. Look for: missing entries (hook never triggered) or exit code != 0
+
+### "Script returns wrong data"
+1. `/wicked-garden:platform:assert --plugin {name}` — check contract compliance
+2. Review violation details for schema mismatches
+
+## Engineer Toolchain Discovery
+
+Discover and interact with monitoring CLIs available in the current environment.
+
+```bash
+# Discover what monitoring tools are installed
+/wicked-garden:platform:toolchain
+
+# Query logs with detected CLI
+/wicked-garden:platform:toolchain --query "error last 1h"
+
+# Detect by category
+/wicked-garden:platform:toolchain --category apm
+```
+
+### CLI Categories
+
+| Category | Tools Detected |
+|----------|---------------|
+| **APM** | `datadog-agent`, `newrelic-cli`, `dt` (Dynatrace) |
+| **Logging** | `splunk`, `elk` / `elasticsearch`, `kibana` |
+| **Metrics** | `promtool` (Prometheus), `grafana-cli` |
+| **Cloud** | `aws cloudwatch`, `gcloud monitoring`, `az monitor` |
+
+Detection uses `command -v` — no external dependencies.
+
+→ See [refs/toolchain-discovery.md](refs/toolchain-discovery.md) for detection patterns and per-tool usage examples.
+
+## Integration
+
+- **smaht** (domain): Context assembly uses trace data to detect degraded adapters
+- **crew** (domain): Health probes run during execution gates
+- **DomainStore**: Traces stored via DomainStore (local JSON), with SqliteStore for search