mcp experiments

.claude/commands/spears-implement.md

@@ -0,0 +1 @@
+404: Not Found

.claude/commands/spears-reflection.md

@@ -0,0 +1,52 @@
+# Context Window Reflection
+
+**CRITICAL: Do NOT make any tool calls.** Use extended thinking to reflect
+deeply on the current conversation context before responding.
+
+## Your Task
+
+Reflect on this work session and produce a **continuation prompt** that
+captures:
+
+1. **Progress Made**: Where are we relative to any phased plan (phase 1/2/3) or
+   roadmap discussed? If no explicit phases exist, summarize loose progress
+   against requirements.
+
+2. **Current State**: What was actively being worked on when context is ending?
+
+3. **Next Steps**: What should be picked up next? Be specific about which
+   requirements or tasks remain.
+
+4. **Worth Following Up On**: Capture anything you noticed during this session
+   that deserves attention:
+   - Failing tests encountered
+   - Dead code or technical debt spotted
+   - Inconsistencies in the codebase
+   - Unresolved questions or decisions
+   - Potential issues that weren't the focus but were observed
+
+## Guidelines
+
+- **Trust `specs/**/executive.md`** as the temporal link - it reflects current
+  reality and where each spec is in its development journey
+- **Trust `specs/**/*.md`** as the authoritative source of truth over all other
+  documentation
+- Reference **spEARS requirements** (EARS IDs) as the primary unit of work when
+  applicable
+- Keep the continuation prompt **minimal on context** - important info is
+  already written to markdown documents in the repo
+- Focus on **key insights specific to this session**, not general project
+  background
+- The prompt should clearly lay out the development vision and help the next
+  context pick up seamlessly
+
+## Output Format
+
+After your reflection, output the continuation prompt in a fenced code block:
+
+```text
+<your continuation prompt here>
+```
+
+The continuation prompt should be immediately usable to resume work in a fresh
+Claude Code context. The user will copy it manually.

.claude/commands/triage-prs.md

@@ -0,0 +1,47 @@
+# PR Triage - Find Unanswered Human Comments
+
+Find human comments on my open PRs that may need a response, filtering out automated bot noise.
+
+## Command
+
+```bash
+./tools/ci/check-prs.sh
+```
+
+Or for specific PRs:
+```bash
+./tools/ci/check-prs.sh 44174 44088
+```
+
+## What it filters out
+
+### Bot accounts:
+- `agent-platform-auto-pr`
+- `cit-pr-commenter`
+- `datadog-official`
+- `dd-octo-sts`
+- Any account starting with `graphite`
+- Your own comments
+
+### Comment patterns (case-insensitive):
+- "Go Package Import Differences"
+- "Static quality checks"
+- "GitLab CI Configuration Changes"
+- "Regression Detector"
+- "bits_ai_status"
+- "graphite.dev"
+
+## Output format
+
+For each PR, report:
+- PR number, title, and URL
+- Review status: APPROVED, CHANGES_REQUESTED, or REVIEW_REQUIRED
+- Pending reviewers (teams or individuals still needed)
+- Any human comments needing response (author + truncated body)
+- Any reviews with state CHANGES_REQUESTED or APPROVED (author + state + truncated body)
+
+### Priority order:
+1. PRs with CHANGES_REQUESTED - need action from you
+2. PRs with unanswered human comments - need response
+3. PRs with REVIEW_REQUIRED - waiting on others
+4. PRs with APPROVED and no pending reviewers - ready to merge

.gitignore

@@ -5,6 +5,7 @@ Dockerfiles/dogstatsd/alpine/static/
 vendor/
 .vendor-new/
 bin/
+!**/src/bin/
 /dev/
 /site/
 __pycache__
@@ -247,3 +248,13 @@ go.work.sum
 # CLAUDE override file for personal use
 CLAUDE_PERSONAL.md
 
+.claude/settings.local.json
+.playwright-mcp
+.claude/agents
+
+# MCP server config (worktree-specific)
+.mcp.json
+
+# Accidentally committed files
+uv.lock
+agent-version.cache

modules.yml

@@ -355,6 +355,9 @@ modules:
     used_by_otel: true
   pkg/version:
     used_by_otel: true
+  q_branch/fine-grained-monitor/scenarios/sigpipe-crash/uds-server: ignored
+  q_branch/fine-grained-monitor/scenarios/sigpipe-crash/victim-app: ignored
+  q_branch/fine-grained-monitor/scenarios/sigpipe-crash/victim-app-c: ignored
   tasks/unit_tests/testdata/go_mod_formatter/invalid_package: ignored
   tasks/unit_tests/testdata/go_mod_formatter/valid_package: ignored
   test/e2e-framework:

q_branch/.claude/settings.local.json

@@ -0,0 +1,14 @@
+{
+  "permissions": {
+    "allow": [
+      "Bash(find:*)",
+      "Bash(mkdir:*)",
+      "Bash(cargo build:*)",
+      "Bash(limactl list:*)",
+      "Bash(limactl shell:*)"
+    ],
+    "additionalDirectories": [
+      "/Users/scott.opell/dev/lading/"
+    ]
+  }
+}

q_branch/.gitignore

@@ -0,0 +1,3 @@
+# Output directory for collected data
+out/
+fine-grained-monitor/testdata

q_branch/CLAUDE.md

@@ -0,0 +1,150 @@
+# q_branch Development Rules
+
+## Fine-Grained Monitor Development
+
+Use `./dev.py` for all fine-grained-monitor (fgm-*) development workflows:
+
+```bash
+cd q_branch/fine-grained-monitor
+
+# Local development
+./dev.py local build              # Build all release binaries
+./dev.py local test               # Run tests
+./dev.py local clippy             # Run clippy lints
+./dev.py local viewer start       # Start fgm-viewer with default data
+./dev.py local viewer start --data /path/to/file.parquet
+./dev.py local viewer stop        # Stop fgm-viewer
+./dev.py local viewer status      # Check fgm-viewer status
+
+# Cluster deployment (Kind via Lima) - per-worktree isolated
+./dev.py cluster deploy           # Build image, load to Kind, restart pods (creates cluster if needed)
+./dev.py cluster status           # Show cluster pod status
+./dev.py cluster viewer start     # Port-forward to viewer on first pod
+./dev.py cluster viewer start --pod NAME  # Port-forward to specific pod
+./dev.py cluster viewer stop      # Stop viewer port-forward
+./dev.py cluster list             # List all fgm-* clusters
+./dev.py cluster create           # Create Kind cluster for this worktree
+./dev.py cluster destroy          # Destroy Kind cluster for this worktree
+./dev.py cluster mcp setup        # Setup MCP server for this worktree's cluster
+./dev.py cluster mcp start        # Start MCP port-forward
+./dev.py cluster mcp stop         # Stop MCP port-forward
+
+# Benchmarking
+./dev.py bench --filter <name>    # Run specific benchmark in background
+./dev.py bench --full-suite       # Run all benchmarks in background
+./dev.py bench wait <guid>        # Wait for benchmark and show results
+./dev.py bench list               # List recent benchmark runs
+```
+
+**Prefer dev.py over raw commands** - it handles image loading into Lima VM, Kind cluster operations, port management, and per-worktree isolation automatically.
+
+### Per-Worktree Isolation
+
+Each git worktree gets its own isolated Kind cluster:
+- Cluster name: `fgm-{worktree-basename}` (e.g., `fgm-beta-datadog-agent`)
+- API port: Deterministic based on worktree name (6443-6447)
+- Data directory: `/var/lib/fine-grained-monitor/{worktree-basename}/`
+- Image tag: `fine-grained-monitor:{worktree-basename}`
+
+Multiple worktrees can run concurrently without conflicts.
+
+### Benchmarking
+
+**Generate benchmark data first**, then run benchmarks:
+
+```bash
+# Generate data with two scenarios: realistic or stress
+cargo run --release --bin generate-bench-data -- --scenario realistic --duration 1h
+cargo run --release --bin generate-bench-data -- --scenario stress --duration 1h
+
+# Run benchmarks with generated data
+BENCH_DATA=testdata/bench/realistic cargo bench
+BENCH_DATA=testdata/bench/stress cargo bench
+
+# Run specific benchmark
+BENCH_DATA=testdata/bench/realistic cargo bench -- scan_metadata
+```
+
+**Available benchmarks:**
+- `scan_metadata` - Startup path, measures parquet file scanning
+- `get_timeseries_single_container` - Single container timeseries query
+- `get_timeseries_all_containers` - All containers timeseries query
+
+**Available data scenarios:**
+- `realistic` - Stable workload: ~20 containers, 2-3 pod restarts/day, ~150-200 MB/day
+- `stress` - Heavy churn: ~50 containers, 5-7 restarts/day, container turnover, ~500-800 MB/day
+
+**Duration examples:** `1h`, `6h`, `24h`, `2d`, `7d`
+
+## Architecture: aarch64 (ARM64)
+
+All local development and testing runs on Apple Silicon (aarch64/ARM64).
+
+**Do NOT specify `--platform linux/amd64`** in docker build commands during local testing loops. The Lima VM, Kind cluster, and all containers run natively on ARM64.
+
+## Kubernetes Cluster (Per-Worktree)
+
+Each worktree has its own Kind cluster inside the Lima VM (`gadget-k8s-host`) with the API port-forwarded to the host.
+
+### MCP Server Setup
+
+Run `./dev.py cluster mcp setup` to configure the kubernetes-mcp-server for this worktree's cluster. This creates:
+- A dedicated kubeconfig at `~/.kube/mcp-fgm-{worktree}.kubeconfig`
+- A project-scoped `.mcp.json` that points to this worktree's cluster
+
+**Restart Claude Code after running setup-mcp** to pick up the new configuration.
+
+### Prefer MCP Tools Over kubectl
+
+**Use kubernetes-mcp-server tools** for all cluster interactions:
+- `pods_list`, `pods_list_in_namespace` - List pods
+- `pods_log` - Get pod logs
+- `pods_get` - Get pod details
+- `pods_delete` - Delete pods
+- `pods_exec` - Execute commands in pods
+- `pods_run` - Run new pods
+- `resources_list`, `resources_get`, `resources_create_or_update`, `resources_delete` - Generic resource operations
+- `helm_list`, `helm_install`, `helm_uninstall` - Helm operations
+- `events_list` - List cluster events
+
+**Only use kubectl via Bash when:**
+- MCP tools don't support the operation (e.g., `kubectl apply -f`)
+- You need complex label selectors or field selectors
+- Debugging MCP connectivity issues
+
+When using kubectl, use the worktree's context: `--context kind-fgm-{worktree-basename}`
+(e.g., `--context kind-fgm-beta-datadog-agent`). Run `./dev.py cluster status` to see the current context.
+
+### VM Operations
+
+The Kind cluster runs inside a Lima VM. For debugging or inspecting the VM directly:
+
+```bash
+limactl shell gadget-k8s-host -- <command>
+limactl shell gadget-k8s-host -- docker images
+limactl shell gadget-k8s-host -- kind get clusters
+```
+
+### Common Workflows
+
+**Check pod status:**
+```
+Use: pods_list_in_namespace(namespace="fine-grained-monitor")
+```
+
+**View pod logs:**
+```
+Use: pods_log(name="<pod-name>", namespace="<namespace>")
+```
+
+**Restart pods (e.g., after image update):**
+```
+Use: pods_delete(name="<pod-name>", namespace="<namespace>")
+# DaemonSet/Deployment will recreate it
+```
+
+**Apply manifests** (MCP doesn't support file-based apply):
+```bash
+# Use the worktree's context (run ./dev.py cluster status to see it)
+kubectl apply -f <file>.yaml --context kind-fgm-<worktree>
+```

q_branch/CONTINUATION.md

@@ -0,0 +1,36 @@
+⏺ ## Continuation: fine-grained-monitor Implementation
+
+  ### Context
+  We completed spEARS specification for `q_branch/fine-grained-monitor/` - a Rust tool to capture fine-grained container metrics (PSS, CPU, cgroup) to
+  Parquet. Solves "who watches the watcher" for Datadog Agent development.
+
+  **Specs location:** `q_branch/fine-grained-monitor/specs/container-monitoring/`
+  - requirements.md: 4 EARS requirements (REQ-FM-001 through REQ-FM-004)
+  - design.md: Architecture, component design
+  - executive.md: Status tracking (4/4 complete)
+
+  ### Key Decisions Made
+  1. **Dependencies:** `lading_capture` + `lading_signal` from git (CaptureManager API is clean)
+  2. **Vendor:** Observer code from lading (Sampler is `pub(crate)`)
+  3. **Container discovery:** Cgroup filesystem scan (`/sys/fs/cgroup/kubepods*`)
+  4. **Memory focus:** PSS over RSS; smaps gated behind `--verbose-perf-risk` (mm lock)
+  5. **Safety:** 1 GiB parquet file size limit
+
+  ### Implementation Order (Completed)
+  1. **REQ-FM-004** - `lading_capture` integration (CaptureManager, parquet output) ✅
+  2. **REQ-FM-001** - Container discovery via cgroup scan ✅
+  3. **REQ-FM-002/003** - Vendor procfs/cgroup parsers from lading ✅
+
+  ### Items to Verify During Implementation
+  - `smaps_rollup` availability for PSS (design assumes it exists)
+  - Cgroup path patterns on KIND cluster (`cri-containerd-*.scope`)
+  - File size monitoring logic (not built into lading_capture)
+  - Cargo.toml git deps may need pinning
+
+  ### Dev Environment
+  - Lima VM: `limactl shell gadget-k8s-host`
+  - KIND cluster: `gadget-dev`
+  - Test target: DatadogAgent CR in `q_branch/test-cluster.yaml`
+
+  ### Start Point
+  Read `specs/container-monitoring/executive.md` for current status, then begin REQ-FM-004 implementation.