Research
All research in the rig. Each entry shows its type, last-updated date, and summary. Research docs declare user_story: in their frontmatter; open the doc for the full Related panel.
- Three-layer drift-prevention playbook When the operator catches the orchestrator drifting on a discipline (label semantics, PR shape, doc freshness, etc.), ship three layers of prevention — memory rule, rig-side enforcement, durable audit/doc — instead of relying on memory alone. Pattern emerged from two distinct drift classes shipped 2026-05-18 with identical structure.
- Postmortem — Weekly roadmap summary bash syntax error (2026-05-18) scripts/roadmap-summary.sh contained an invalid `[[ ... <= ... ]]` operator that crashed the workflow on every Monday cron since PR #131 merged. main-guard mis-attributed the latest failure to PR #268.
- PR shape — when to split, when `large-pr-ok` applies (A/B-validated 2026-05-18) The rig's PR size gate offers two paths: split into focused PRs, OR add `large-pr-ok` label. Today's evidence shows the label empirically bypasses Review-E's deep-context attention. Documents when each path is appropriate, with the decision tree the orchestrator should follow at the trigger point.
- Postmortem — main-red SLA breach on cron-only failure (2026-05-18) main-guard escalated a Weekly-roadmap-summary cron failure as a 30m SLA breach against PR #268; the doc-only postmortem PR could not have caused a bash syntax error introduced 4 weeks earlier in PR #131.
- Postmortem — main-red false positive on `Build and deploy` against doc-only PR #273 (2026-05-18) main-guard filed rig-docs#274 against PR #273 (a 1-file markdown postmortem) when the `Build and deploy` workflow went red post-merge. The build job passes deterministically against the merge commit; the failure was in the deploy job (operator-owned Cloudflare credentials), which PR #273 could not have caused.
- Postmortem — main-guard false positive on `cancelled` runs (2026-05-15) main-guard escalated rig-docs#264 as a main-red incident, but the cited run was `cancelled` (cancel-in-progress), not `failure`. Main was already green. Captures the misclassification and the fix needed in main-guard.
- Norwegian compliance — high-level gap scan (2026-05-09) High-level scan of dashecorp's public-facing sites, docs, and deployment patterns against Norwegian compliance requirements. Identifies likely gaps, smallest useful next task, and open questions for human review.
- Postmortem — chicken-and-egg dispatch halt (2026-04-30) Three independent bugs combined to prevent the rig from self-healing during the Planner-E rollout, requiring an operator admin-merge. Captures the failure mode and the systemic fixes that resulted.
- Per-pod consumer partitioning: XREADGROUP gotcha and the HOSTNAME fix Why naively scaling Redis XREADGROUP consumers to replicas > 1 causes duplicate message delivery, and how pod-name consumer IDs solve it.
- Governance patterns: branch protection as agent gate, CODEOWNERS How the rig uses GitHub branch protection rules and CODEOWNERS files as configurable governance layers that don't require model changes.
- Event-sourced agent state: Marten + Postgres in rig-conductor How rig-conductor uses Marten event sourcing to track agent state, assign work atomically, and maintain a full audit trail from issue to merge.
- Doc taxonomy audit — do we need whitepaper, research, proposal, and user-story? Audit of rig-docs 4-type taxonomy against industry doc patterns (Diátaxis, ADR, RFC, design docs). Per-document verdict and a concrete recommendation.
- Cost model: token attribution, cache-read economics, and KEDA scale-to-zero How the rig tracks per-issue LLM spend, the economics of Claude's cache-read pricing, and the KEDA scale-to-zero design for cost-idle agents.
- Agent platform comparison: the rig vs. Devin, SWE-agent, Aider, Claude Code Prior-art analysis comparing the Dashecorp rig's design to leading agent platforms. What each does well, where the rig diverges, and why.
- Full Quality Review — All Whitepapers (2026-04-22) Comprehensive per-whitepaper quality review covering frontmatter, freshness, cross-links, implementation-status integrity, Mermaid diagrams, user-story coverage, honest-gap flags, and TL;DR completeness. Grades A–C. Four C-grades with concrete remediation paths.
- LiteLLM passthrough spike #2 — real key, OAuth incompatibility found Follow-up to spike #1 using the rig's actual dev-e Anthropic credential. Confirms passthrough forwards to api.anthropic.com (x-litellm-model-api-base response header makes this explicit) but LiteLLM's passthrough auth path is not compatible with Anthropic OAuth subscription tokens — the format the rig actually uses. A real Anthropic API key (not OAuth) would be required for the LiteLLM path, which has cost-accounting implications.
- LiteLLM passthrough spike for AC 5 redesign — findings Live spike of LiteLLM Anthropic passthrough on the rig k3s cluster. Confirms the /anthropic/{endpoint} route exists and forwards to api.anthropic.com (verified by real Anthropic request_id on fake-key 401), but error responses are wrapped in LiteLLM's envelope. Prompt-cache + streaming fidelity on success responses requires a follow-up test with a real API key. Enough signal to decide next step.
- Envoy SNI egress gateway — verified working for AC 5 Phase 1 Live spike on the rig k3s cluster — single-pod Envoy with sni_dynamic_forward_proxy filter correctly allows api.anthropic.com, api.github.com, ghcr.io while blocking google.com and example.com. Byte-transparent TLS passthrough (no cert issues, real upstream HTTP responses). The short-term AC 5 Phase 1 path this research recommends.
- Pitfall: ipBlock NetworkPolicy cannot allowlist Cloudflare-fronted LLM APIs AC 5 Phase 1 shipped a default-deny egress NetworkPolicy with ipBlock allowing Anthropic's published CIDR (160.79.104.0/21). It was reverted the same day: api.anthropic.com resolves to Cloudflare anycast (162.159.x.x), not to the origin CIDR, so the policy silently blocked all agent-to-Anthropic traffic. Future approach: route Anthropic calls through an in-cluster LiteLLM proxy pod — the only egress target the NetworkPolicy needs to allow.
- Cross-repo Actions access — patterns, tradeoffs, and the OpenTofu-managed answer Comparative study of GitHub options for giving one workflow read access to private repos in other repos/orgs: Apps + org secrets, PATs, deploy keys, artifacts, workflow_run, repository_dispatch, reusable workflows, internal visibility, and GitHub Packages with per-package repo access grants. Recommendation revised 2026-04-22: Packages is the consumer-token-free path; App + org secret remains the fallback.
- OTel observability — startup programs, storage economics, 2026 price-at-scale Second-pass research that the 2026-04-20 options note missed. Startup credit programs (Grafana Cloud $100k / 12 mo is the standout; Invotek AS qualifies), long-term storage pricing, and cost at 1.5M→15M spans/month. Revises the Priority 2 recommendation: Grafana Cloud for Startups becomes the default production backend candidate; Langfuse stays for the LLM-specific UX layer.
- Default-deny egress on GKE Dataplane V2 — seven options, one layered recommendation AC 5 of the safety-foundation user story assumes Cilium L7. GKE Dataplane V2 is Cilium-derived but doesn't expose full Cilium CRDs. This doc evaluates seven options (FQDNNetworkPolicy, self-Cilium, sidecar, egress gateway, ipBlock, Anthropic-CIDR, LiteLLM+gateway), recommends a layered rollout starting with a default-deny + CIDR allowlist NetworkPolicy this week, then FQDNNetworkPolicy next sprint, then an egress gateway when agent count grows.
- Is the brain pattern a good idea? — prior art in 2025-2026 Audit of what the rig's BRAIN.md actually is vs. what AGENTS.md, CLAUDE.md, llms.txt, Anthropic Skills, Cursor rules, and Karpathy's LLM Wiki do. Verdict: defensible and in the mainstream markdown-over-RAG camp, but our 30 KB always-load size is 3-5× the community ceiling and we're not emitting AGENTS.md so non-Claude tools can't find it.
- Agent runtime installs — what's baked in, what's needed, and why Phase 1 egress CIDR-only breaks agents Audit of package-install behavior across rig agent pods: base and per-language Dockerfiles bake ~20 tools; the task prompt instructs agents to install more at runtime with sudo + apt-get (both blocked by pretool-guard — contradiction). Any Phase 1 NetworkPolicy with only CIDR allowlists would break `npm install` / `pip install` for customer project deps (npm + nuget are Cloudflare-fronted, ~1500 rotating prefixes). Revised recommendation: skip Phase 1 CIDR-only, go direct to FQDNNetworkPolicy; fix the stream-consumer.js runtime-install prompt to match pretool-guard reality.
- What to implement next — raising the floor before raising the ceiling Leadership whitepaper. The rig works end-to-end today but 27% of the target architecture is deployed. This paper names the four next investments — safety floor, agent observability, cost ceiling, quality gate — and is explicit about what is deliberately deferred. Synthesized from implementation-status.md (78 capabilities tracked across 11 domains).
- OTel-native LLM observability — free and low-cost options for the rig Comparison of 11 OTel-compatible LLM observability stacks on deploy footprint, LLM-specific UI, free-tier terms, and maturity. Verdict: Phoenix first (on the 8 GB VM), Langfuse later (at scale). Corrects a premise in whatsnext whitepaper that treated them as interchangeable.
- Brain and Memory — architecture for autonomous engineering Visual whitepaper for engineering leadership. The rig is a shared autonomous-engineering platform: brain + memory + agents. Works two ways — building the rig itself, and shipping products on top of it. Multi-org, multi-project from day one.
- Production agent docs patterns — Vercel, Cloudflare, HumanLayer, Anthropic What production coding-agent rigs actually put in their AGENTS.md / CLAUDE.md files, with measured eval data
- LLM Wiki pattern — Karpathy analysis Analysis of Karpathy's LLM Wiki gist and how it applies to an autonomous coding-agent rig
- Research: principles for docs vs memory separation (2026-04-18) Five candidate principles for deciding what belongs in canonical docs versus in operational memory MCP.
- Documentation tools evaluation (2026-04-18) Comparison of 25 documentation tools against 12 weighted criteria for the Dashecorp rig. Verdict: Starlight picked over Notion/Outline after Plane rejected.
- Documentation state audit — dashecorp rig (2026-04-18) Ground-truth snapshot of docs across all 7 active dashecorp repos: frontmatter compliance, CLAUDE.md/AGENTS.md presence, broken patterns
- Research: current docs and memory inventory (2026-04-18) Snapshot of what lives in docs vs memory at the time the docs-memory strategy arc started.
- Research: anti-drift lint rules between docs and memory (2026-04-18) Automated lint rules to prevent docs and memory from drifting apart as the rig operates.