diogenes 0.1.2 → 0.1.3

data/docs/dashboard.md

@@ -1,365 +0,0 @@
-# The Diogenes Dashboard
-
-The Diogenes dashboard is a Rails engine that mounts into your existing application and gives you a live view of AI feature health across three dimensions: grounding verification, document drift, and eval regressions.
-
-Think of it as Sidekiq Web for AI accountability — one place to see whether your AI features are doing what you think they're doing.
-
----
-
-## Mounting
-
-```ruby
-# config/routes.rb
-mount Diogenes::Engine => '/diogenes'
-```
-
-Diogenes has no opinions about authentication. Protect the route the same way you protect any sensitive admin surface:
-
-```ruby
-# With Devise + admin constraint
-authenticate :user, ->(u) { u.admin? } do
-  mount Diogenes::Engine => '/diogenes'
-end
-
-# With HTTP basic auth via a constraint
-constraints Diogenes::AdminConstraint.new(ENV['DIOGENES_PASSWORD']) do
-  mount Diogenes::Engine => '/diogenes'
-end
-
-# With a custom Rack middleware
-mount Diogenes::Engine => '/diogenes', constraints: YourAuthConstraint
-```
-
----
-
-## Engine Routes
-
-```ruby
-# lib/diogenes/engine/routes.rb
-
-Diogenes::Engine.routes.draw do
-  root to: 'dashboard#overview'
-
-  namespace :dashboard do
-    # Grounding
-    get  'grounding',                    to: 'grounding#index'
-    get  'grounding/:feature',           to: 'grounding#show'
-    get  'grounding/:feature/:id',       to: 'grounding#verification'
-
-    # Drift
-    get  'drift',                        to: 'drift#index'
-    get  'drift/:index_name',            to: 'drift#show'
-    post 'drift/:index_name/reindex',    to: 'drift#reindex'
-    post 'drift/:document_id/reindex',   to: 'drift#reindex_document'
-
-    # Evals
-    get  'evals',                        to: 'evals#index'
-    get  'evals/:feature',               to: 'evals#show'
-    post 'evals/:feature/run',           to: 'evals#run'
-    get  'evals/:feature/:run_id',       to: 'evals#run_result'
-  end
-end
-```
-
----
-
-## Controller Structure
-
-```
-lib/diogenes/engine/
-  app/
-    controllers/
-      diogenes/
-        dashboard_controller.rb     # Overview tab
-        dashboard/
-          grounding_controller.rb
-          drift_controller.rb
-          evals_controller.rb
-    views/
-      diogenes/
-        dashboard/
-          overview.html.erb
-          grounding/
-            index.html.erb
-            show.html.erb
-            verification.html.erb
-          drift/
-            index.html.erb
-            show.html.erb
-          evals/
-            index.html.erb
-            show.html.erb
-            run_result.html.erb
-```
-
----
-
-## The Overview Tab
-
-`GET /diogenes`
-
-The entry point. One row per gated feature, showing aggregate health across all three dimensions. Red features surface immediately.
-
-```
-┌─────────────────────────────────────────────────────────────────────────────┐
-│ DIOGENES                                              Last updated: 2 min ago│
-├──────────────────────┬────────┬─────────────┬──────────────┬────────────────┤
-│ Feature              │ Gates  │ Grounding   │ Drift        │ Evals          │
-├──────────────────────┼────────┼─────────────┼──────────────┼────────────────┤
-│ SupportAssistant     │ 5/5 ✓  │ 94% clean   │ 2 stale docs │ 47/50 passing  │
-│ CodebaseOracle       │ 5/5 ✓  │ 98% clean   │ All current  │ 30/30 passing  │
-│ ComplianceSearcher   │ 5/5 ✓  │ 87% clean ⚠ │ 11 stale docs│ 18/25 passing ✗│
-└──────────────────────┴────────┴─────────────┴──────────────┴────────────────┘
-```
-
-`ComplianceSearcher` has a low grounding rate, stale documents, and a failing eval suite. That's the feature that needs attention today — and you can see it before a user does.
-
----
-
-## The Grounding Tab
-
-`GET /diogenes/dashboard/grounding`
-
-Per-feature grounding verification history. Shows flag rates over time and a live feed of recent verifications.
-
-```
-SupportAssistant — Grounding History (last 30 days)
-
-Flag rate: 6.2%  ▼ from 8.1% last month
-
-Recent verifications:
-  ✓ Supported    "You can cancel your subscription from the billing page..."
-  ✓ Supported    "The enterprise tier includes unlimited seats..."
-  ⚠ Unsupported  "Refunds are processed within 24 hours..."  → flagged for review
-  ✗ Contradicted "The API rate limit is 100 req/min..."      → blocked, not served
-```
-
-### Verification Detail
-
-`GET /diogenes/dashboard/grounding/:feature/:id`
-
-Drill into any verification to see the full picture:
-
-```
-Verification #8472 — SupportAssistant
-Query:    "How long does a refund take?"
-Status:   ⚠ FLAGGED — unsupported claim detected
-
-Retrieved context:
-  [chunk 1] "Refund requests are reviewed within 2 business days..."  ← source: refund-policy.md
-  [chunk 2] "Enterprise customers receive priority support..."         ← source: enterprise-terms.md
-
-AI response:
-  "Refunds are typically processed within 24 hours."
-
-Verdict:
-  supported:     []
-  unsupported:   ["processed within 24 hours"]   ← no chunk supports this timeframe
-  contradicted:  []
-
-Action taken: flagged_for_review
-Reviewed by:  sarah@company.com (approved with edit)
-Final sent:   "Refunds are reviewed within 2 business days..."
-```
-
-This is the audit trail that makes human-in-the-loop real. Every verification, every flag, every human decision — all linked.
-
----
-
-## The Drift Tab
-
-`GET /diogenes/dashboard/drift`
-
-A staleness leaderboard — every indexed document, ranked by how long since its embedding was updated versus when the source last changed.
-
-```
-Document Drift — All Indexes
-
-  ● 11 documents require attention
-
-  CRITICAL (source changed > 30 days ago, not re-indexed)
-  ┌─────────────────────────────────┬──────────────┬──────────────┬──────────┐
-  │ Document                        │ Source updated│ Last indexed │ Staleness│
-  ├─────────────────────────────────┼──────────────┼──────────────┼──────────┤
-  │ refund-policy.md                │ 47 days ago  │ 89 days ago  │ ████████ │
-  │ enterprise-pricing.md           │ 33 days ago  │ 102 days ago │ ████████ │
-  └─────────────────────────────────┴──────────────┴──────────────┴──────────┘
-
-  WARNING (source changed 7–30 days ago)
-  ┌─────────────────────────────────┬──────────────┬──────────────┬──────────┐
-  │ api-rate-limits.md              │ 12 days ago  │ 45 days ago  │ █████░░░ │
-  │ ...                             │              │              │          │
-  └─────────────────────────────────┴──────────────┴──────────────┴──────────┘
-
-  [Re-index all critical]   [Re-index all warnings]
-```
-
-### Re-indexing
-
-Clicking re-index queues an `ActiveJob`. The job is defined in the host app — Diogenes provides the interface and the tracking, not the embedding logic:
-
-```ruby
-# config/initializers/diogenes.rb
-Diogenes.configure do |config|
-  config.drift.reindex_job = ReindexDocumentJob
-  config.drift.staleness_thresholds = {
-    warning:  7.days,
-    critical: 30.days
-  }
-  config.drift.alert_webhook = ENV['DIOGENES_ALERT_WEBHOOK']
-end
-```
-
-### How Drift Is Detected
-
-Diogenes tracks two timestamps per indexed document:
-
-- `source_updated_at` — populated by the host app when indexing, updated by a webhook or scheduled check
-- `indexed_at` — set by Diogenes when an embedding is stored
-
-The staleness score is a function of the gap between them, weighted by how much the source changed (line diff if available, timestamp delta otherwise).
-
-```ruby
-# Inform Diogenes that a source document has changed
-Diogenes::Drift.source_updated(
-  document_id: 'refund-policy-v2',
-  updated_at: Time.current,
-  diff_size: :major   # :minor, :moderate, :major — affects staleness weight
-)
-```
-
----
-
-## The Evals Tab
-
-`GET /diogenes/dashboard/evals`
-
-The hardest unsolved problem in production AI is knowing whether your feature is getting better or worse over time. The evals tab is Diogenes's answer: define golden question/answer pairs, run them on a schedule, track pass rates over time, and alert on regression.
-
-```
-Evals — All Features
-
-  SupportAssistant    47/50 passing   94%  ▲ from 91% last week   [Run now]
-  CodebaseOracle      30/30 passing  100%  → unchanged             [Run now]
-  ComplianceSearcher  18/25 passing   72%  ▼ from 88% last week ✗ [Run now]
-```
-
-### Defining Golden Pairs
-
-Golden pairs live in your codebase as Ruby, not in a database. They're version-controlled, reviewed in PRs, and treated as first-class tests:
-
-```ruby
-# test/diogenes/evals/support_assistant_evals.rb
-
-Diogenes::Evals.define(SupportAssistant) do
-  eval "basic refund question" do
-    query    "How do I request a refund?"
-    expects  all_of(
-      grounded_in("refund-policy"),
-      contains("billing page"),
-      does_not_contain("24 hours")   # known wrong answer to guard against
-    )
-  end
-
-  eval "enterprise tier question" do
-    query    "Does the enterprise plan include SSO?"
-    expects  all_of(
-      grounded_in("enterprise-terms"),
-      semantically_similar_to("Yes, SSO is included in all enterprise plans")
-    )
-  end
-
-  eval "question with no good answer" do
-    query    "What is the API rate limit for the legacy v1 endpoints?"
-    expects  one_of(
-      low_confidence_response,
-      routes_to_human_review
-    )
-  end
-end
-```
-
-### Matchers
-
-| Matcher | What it checks |
-|---|---|
-| `grounded_in(source)` | Retrieved context includes chunks from the named source |
-| `contains(text)` | Response includes the specified text or close semantic equivalent |
-| `does_not_contain(text)` | Response does not include the specified text |
-| `semantically_similar_to(text)` | Response embedding is within threshold cosine distance |
-| `low_confidence_response` | Feature returned a flagged or low-confidence result |
-| `routes_to_human_review` | Feature queued the output for human review |
-| `all_of(*matchers)` | All matchers must pass |
-| `one_of(*matchers)` | At least one matcher must pass |
-
-### Running Evals
-
-Evals can be run on demand from the dashboard, via a Rake task, or on a schedule:
-
-```bash
-# On demand
-bundle exec rake diogenes:evals:run[SupportAssistant]
-bundle exec rake diogenes:evals:run   # all features
-```
-
-```ruby
-# Scheduled via your existing job infrastructure
-class RunDiogenesEvalsJob < ApplicationJob
-  def perform
-    Diogenes::Evals.run_all
-  end
-end
-```
-
-### Regression Detection
-
-When a passing eval starts failing, Diogenes records the regression point — exactly which run it broke on — and stores a diff between the last passing response and the first failing one. The evals detail view surfaces this:
-
-```
-ComplianceSearcher — Eval Regression Detected
-
-  "What is our data retention policy?"
-
-  Status: ✗ FAILING since run #142 (3 days ago)
-
-  Last passing response (run #141):
-    "Data is retained for 7 years per our compliance obligations..."
-
-  Current failing response (run #144):
-    "Data retention policies vary by region..."
-
-  Likely cause: 'data-retention-policy.md' updated 4 days ago, not re-indexed
-                → See drift tab
-```
-
-That last line is the integration that makes the dashboard coherent: a failing eval points to a stale document in the drift tab, which explains the low grounding score on the grounding tab. Three separate signals, one root cause.
-
----
-
-## Configuration Reference
-
-```ruby
-# config/initializers/diogenes.rb
-
-Diogenes.configure do |config|
-  # Grounding
-  config.grounding.default_threshold      = 0.8
-  config.grounding.verifier_llm           = -> (prompt) { YourLLMClient.complete(prompt) }
-
-  # Drift
-  config.drift.reindex_job                = ReindexDocumentJob
-  config.drift.staleness_thresholds       = { warning: 7.days, critical: 30.days }
-  config.drift.alert_webhook              = ENV['DIOGENES_ALERT_WEBHOOK']
-  config.drift.check_interval             = 1.hour
-
-  # Evals
-  config.evals.schedule                   = '0 9 * * *'   # daily at 9am, if using sidekiq-cron
-  config.evals.alert_on_regression        = true
-  config.evals.alert_webhook              = ENV['DIOGENES_ALERT_WEBHOOK']
-  config.evals.passing_threshold          = 0.9           # alert if pass rate drops below 90%
-
-  # Audit log
-  config.audit.retention_days             = 90
-  config.audit.pii_scrubber               = Diogenes::PII::DefaultScrubber
-end
-```

data/docs/examples.md

@@ -1,162 +0,0 @@
-# Examples
-
-These two examples use the same codebase, the same RAG pipeline, and the same underlying LLM. They reach different verdicts. That's the point.
-
----
-
-## Example A: Support Agent Assistant ✅ Passes
-
-**The feature:** A text interface inside your Rails admin that lets support agents paste a customer's problem and receive relevant documentation, similar past tickets, and a suggested first response — all sourced and citable.
-
-**The user:** A trained support agent. Not the customer.
-
-### Gate Evaluation
-
-```ruby
-class SupportAssistant
-  include Diogenes::Feature
-  include Diogenes::Grounding
-
-  gate :failure_mode,
-    severity: :recoverable
-    # A wrong suggested response gets caught by the agent before
-    # it reaches the customer. Failure is visible and correctable.
-
-  gate :user_calibration,
-    audience: :trained_agent
-    # Agents know the product. They will notice a wrong answer.
-    # They have the context to evaluate AI output critically.
-
-  gate :human_in_loop,
-    verified: true,
-    max_daily_reviews: 80,
-    review_sla_minutes: 5
-    # The agent reads the suggestion before sending anything.
-    # The customer never sees unreviewed AI output.
-
-  gate :observability,
-    logging: :full,
-    alerting: :enabled,
-    drift_detection: true
-    # We track suggestion acceptance rate, edit rate, and
-    # escalation rate as proxy signals for output quality.
-
-  gate :necessity,
-    alternatives_considered: [
-      "Static knowledge base with keyword search",
-      "Pre-written response templates by category"
-    ],
-    reasoning: "Agents handle 400+ tickets/day across 12 product areas and
-                6 pricing tiers. Template coverage is <40% of actual ticket
-                variance. Search requires agents to know what to search for."
-
-  verify_grounding threshold: 0.8, on_failure: :flag_for_review
-
-  def answer(query, agent:)
-    context = retriever.retrieve(query)
-    response = llm.complete(query, context: context)
-
-    verify_and_return(
-      response,
-      context: context,
-      reviewed_by: agent
-    )
-  end
-end
-```
-
-### Why It Passes
-
-The human is genuinely in the loop — the agent reads the suggestion and decides what to send. The audience is calibrated — agents know when an answer feels wrong. The failure mode is recoverable — a bad suggestion gets edited or ignored before it causes harm. Observability is real — acceptance and edit rates tell you when quality degrades before users notice.
-
-The RAG pipeline underneath is the same one described in the implementation guide. The grounding verifier ensures the suggested response is actually supported by retrieved context, not confabulated. Chunks that surface PII from past tickets are scrubbed before storage — the anonymization pipeline is what makes it legal to index support history at all.
-
----
-
-## Example B: Invoice Explainer ❌ Fails
-
-**The feature:** A "What does this mean?" button on invoice line items that uses AI to explain charges to customers in plain language.
-
-**The user:** Any customer. General consumer audience.
-
-### Gate Evaluation
-
-```ruby
-class InvoiceExplainer
-  include Diogenes::Feature
-
-  gate :failure_mode,
-    severity: :financial_dispute
-    # A wrong explanation of a charge — "that fee doesn't apply to
-    # your account" when it does — creates a customer expectation that
-    # is difficult and expensive to walk back. It may constitute a
-    # misrepresentation of contract terms.
-
-  gate :user_calibration,
-    audience: :general_consumer
-    # Customers don't have access to the billing logic. They cannot
-    # evaluate whether the explanation is correct. A confident wrong
-    # answer is worse than no answer.
-
-  gate :human_in_loop,
-    verified: false
-    # There is no human between the AI output and the customer.
-    # Real-time invoice explanations cannot wait for review.
-
-  # Diogenes::UnsafeFeatureError raised at boot:
-  # InvoiceExplainer fails 3 gates:
-  #   - :failure_mode severity :financial_dispute requires :human_in_loop verified: true
-  #   - :user_calibration audience :general_consumer incompatible with :failure_mode severity :financial_dispute
-  #   - :human_in_loop verified: false blocks all consumer-facing output
-end
-```
-
-### Why It Fails — And What To Do Instead
-
-The feature fails because the failure mode is financial, the audience can't self-verify, and there's no human review. These aren't independent problems — they compound. An incorrect explanation of a financial charge, delivered confidently to someone who has no way to check it, with no human who saw it before it went out, is a product liability problem.
-
-**The right solution isn't a better AI feature. It's better UI.**
-
-```ruby
-# What to build instead:
-#
-# 1. Plain-English line item labels in the invoice model itself
-#    "Platform fee (10% of monthly usage)" not "PLAT_FEE_USG_PCT"
-#
-# 2. A tooltip or expandable section with a static explanation
-#    per charge type — written once by a human, accurate forever
-#
-# 3. A "why was I charged this?" link that opens a pre-filtered
-#    support ticket — staffed by agents using the SupportAssistant above
-#
-# This solves 90% of user confusion, is faster to build,
-# costs nothing to run, and has zero hallucination risk.
-```
-
-### The Honest Conversation
-
-When a client comes to you with the invoice explainer idea, the Diogenes gate output is the conversation:
-
-> "We ran this through the framework. It fails on failure mode severity, user calibration, and human review. Here's what that means in practice, and here's what we'd build instead."
-
-That's not a rejection. That's a better answer to the same problem — delivered with evidence.
-
----
-
-## What the Dashboard Shows
-
-Three weeks after shipping `SupportAssistant`, the Diogenes overview tab looks like this:
-
-```
-┌──────────────────────┬────────┬─────────────┬──────────────┬───────────────┐
-│ Feature              │ Gates  │ Grounding   │ Drift        │ Evals         │
-├──────────────────────┼────────┼─────────────┼──────────────┼───────────────┤
-│ SupportAssistant     │ 5/5 ✓  │ 94% clean   │ 1 stale doc  │ 47/50 passing │
-└──────────────────────┴────────┴─────────────┴──────────────┴───────────────┘
-```
-
-The one stale document is `refund-policy.md`, updated by the product team two weeks ago and not yet re-indexed. The grounding tab shows three recent verifications flagged for containing the old refund timeframe. The drift tab surfaces the document with a re-index button. The eval for "how long does a refund take?" is among the six failing evals.
-
-All three signals point to the same root cause. One click queues the re-index job. The problem is visible before a customer receives a wrong answer.
-
-`InvoiceExplainer` doesn't appear in the dashboard at all. It never got past boot.

data/docs/framework.md

@@ -1,146 +0,0 @@
-# The Diogenes Framework
-
-Diogenes is built around a single question: **can you defend this decision?**
-
-Not defend it philosophically — defend it in a postmortem, in a client meeting, in an audit, or in a conversation with a user who got a wrong answer and wants to know why.
-
-The framework is five gates. Each one represents a question your team must answer before shipping an AI-enhanced feature to users. Some gates are enforced by code. Some are enforced by documentation. All of them are enforced by the fact that they live in your codebase, get reviewed in PRs, and travel with the feature forever.
-
----
-
-## Gate 1: Failure Mode
-
-**The question:** What happens when the AI is wrong — and is that acceptable?
-
-Every AI feature will produce wrong answers. The question is never *if*, it's *what happens when*. The failure mode gate forces you to classify the severity of a wrong answer before you ship.
-
-```ruby
-gate :failure_mode, severity: :recoverable
-# Acceptable severities: :cosmetic, :recoverable, :degraded_experience
-# Unacceptable without additional gates: :financial_dispute, :safety_risk, :legal_exposure
-```
-
-A wrong restaurant recommendation is cosmetic. A wrong answer about a return policy is recoverable. A wrong answer about medication interactions is a safety risk. The gem will warn at boot if you declare a high-severity failure mode without also declaring strong human-in-the-loop configuration.
-
-**What this forces you to think about:**
-- The worst plausible wrong answer, not the average wrong answer
-- Whether wrong answers compound over time or reset per interaction
-- Whether the user will know they received a wrong answer
-
----
-
-## Gate 2: User Calibration
-
-**The question:** Can your target user tell when the output is wrong?
-
-This is the gate that kills the most features — and it should. The danger of a confident, fluent AI answer isn't that it's wrong. It's that it's wrong in a way that sounds exactly like being right.
-
-A developer reading Copilot output has the domain knowledge to spot a hallucinated API method. A consumer reading an AI-generated insurance summary probably does not.
-
-```ruby
-gate :user_calibration, audience: :trained_agent
-# Audiences: :domain_expert, :trained_agent, :power_user, :general_consumer
-```
-
-`:general_consumer` doesn't automatically fail — but it requires strong grounding verification and conservative output thresholds. The gem will not allow `:general_consumer` + `:safety_risk` without raising at boot.
-
-**What this forces you to think about:**
-- Who the actual user is, not the assumed user
-- Whether the UI makes uncertainty visible
-- Whether users have any recourse when they suspect an error
-
----
-
-## Gate 3: Human in the Loop
-
-**The question:** Is a human genuinely reviewing output, or rubber-stamping at volume?
-
-"A human reviews it" is one of the most misused phrases in AI feature development. A human reviewing 400 AI outputs a day for 30 seconds each is not a meaningful review. This gate requires you to specify not just that a human is involved, but the conditions under which that review is real.
-
-```ruby
-gate :human_in_loop,
-  verified: true,
-  max_daily_reviews: 50,
-  review_sla_minutes: 30
-```
-
-Diogenes tracks review volume per reviewer. If a reviewer exceeds `max_daily_reviews`, the queue is flagged and additional reviewers are required before new outputs are released.
-
-**What this forces you to think about:**
-- Whether reviewers have enough context to actually evaluate the output
-- Whether reviewers have the authority to reject or modify, not just approve
-- Whether review load is sustainable as the feature scales
-
----
-
-## Gate 4: Observability
-
-**The question:** Will you know when things are going wrong in production?
-
-Most teams ship AI features with less monitoring than they'd give a sorting algorithm. The outputs are nondeterministic, which means traditional error rate monitoring misses the most important failure modes — outputs that are wrong but don't raise exceptions.
-
-```ruby
-gate :observability,
-  logging: :full,
-  alerting: :enabled,
-  drift_detection: true
-```
-
-Declaring this gate without the corresponding observability infrastructure raises at boot. Diogenes checks for a configured audit log destination and alert webhook before allowing the feature to serve.
-
-**What this forces you to think about:**
-- How you detect when hallucination rates increase
-- How you detect when retrieved context is becoming stale
-- What a "degraded AI feature" looks like in your alerting dashboard
-
----
-
-## Gate 5: Necessity
-
-**The question:** Is AI actually the right solution, or just the exciting one?
-
-This is the hardest gate to encode and the most important one to ask. A well-designed UI, a good search index, a rule-based system, or better documentation will outperform a brittle AI feature in most cases — and will be faster to build, cheaper to run, and easier to debug.
-
-```ruby
-gate :necessity,
-  alternatives_considered: [
-    "Better invoice UI with plain-English line item labels",
-    "Keyword search across the knowledge base",
-    "Contextual help tooltips on common confusion points"
-  ],
-  reasoning: "Support agents handle 400+ tickets/day across 12 product areas.
-              The volume and variance exceeds what static documentation can address."
-```
-
-Diogenes doesn't enforce this gate programmatically. It enforces it by requiring you to write it down, put it in a PR, and have someone else read it.
-
-**What this forces you to think about:**
-- Whether the problem is actually an AI problem or a UX problem
-- Whether you're solving for users or solving for a roadmap item
-- Whether you'll still want this feature in 18 months when the novelty has worn off
-
----
-
-## The Verdict
-
-A feature that passes all five gates is ready to build — with the understanding that the gates are revisited when the feature scales, when the user base changes, or when the failure mode landscape shifts.
-
-A feature that fails a gate isn't necessarily dead. It's a specification of what needs to change before it ships. Sometimes that's a better review workflow. Sometimes that's a UI change that improves user calibration. Sometimes it's the answer that saves you six months of work on the wrong solution.
-
-That's the point.
-
----
-
-## After the Gates
-
-Passing the gates is the beginning, not the end. Once a feature ships, Diogenes continues watching it through three lenses:
-
-**Grounding** — are AI responses actually supported by the context they're drawing from, or are they drifting into confabulation?
-
-**Drift** — are the documents feeding your retrieval pipeline still current, or have they gone stale while the embeddings haven't caught up?
-
-**Evals** — are the things the feature was supposed to do when you shipped it still working, or has something quietly regressed?
-
-All three surface in the mounted dashboard. The gates tell you whether to build it. These tell you whether it's still working.
-
-See [docs/dashboard.md](docs/dashboard.md) for full documentation.