diogenes 0.1.2 → 0.1.3

data/sig/generated/diogenes/cli.rbs

@@ -0,0 +1,34 @@
+# Generated from lib/diogenes/cli.rb with RBS::Inline
+
+module Diogenes
+  class Cli
+    COMMANDS: Hash[String, Class]
+
+    # : (?Array[String] argv, ?out: IO, ?err: IO) -> Integer
+    def self.run: (?Array[String] argv, ?out: IO, ?err: IO) -> Integer
+
+    # : (argv: Array[String], out: IO, err: IO) -> void
+    def initialize: (argv: Array[String], out: IO, err: IO) -> void
+
+    # : () -> Integer
+    def run: () -> Integer
+
+    private
+
+    # Run a command
+    # --
+    # : (Class, Array[String]) -> Integer
+    def run_command: (Class, Array[String]) -> Integer
+
+    # : () -> Integer
+    def print_help: () -> Integer
+
+    # : () -> Integer
+    def print_version: () -> Integer
+
+    # Print the unknown command message
+    # --
+    # : (String) -> String
+    def unknown_command_message: (String) -> String
+  end
+end

data/sig/generated/diogenes/version.rbs

@@ -0,0 +1,5 @@
+# Generated from lib/diogenes/version.rb with RBS::Inline
+
+module Diogenes
+  VERSION: String
+end

data/sig/generated/diogenes.rbs

@@ -0,0 +1,26 @@
+# Generated from lib/diogenes.rb with RBS::Inline
+
+module Diogenes
+  # Base error class for Diogenes.
+  class Error < StandardError
+  end
+
+  # Raised when invalid arguments are passed to a method.
+  class ArgumentError < ::ArgumentError
+  end
+
+  # Raised when the configuration is invalid.
+  class ValidationError < Error
+  end
+
+  # Raised when the user provides invalid arguments to the CLI.
+  class UserError < Error
+  end
+
+  # Returns the version of the Diogenes gem.
+  #
+  # This is managed by the release-please workflow.
+  # --
+  # : () -> String
+  def self.version: () -> String
+end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: diogenes
 version: !ruby/object:Gem::Version
-  version: 0.1.2
+  version: 0.1.3
 platform: ruby
 authors:
 - Meagan Waller
@@ -30,29 +30,43 @@ dependencies:
       - !ruby/object:Gem::Version
         version: 2.6.0
 description: A Ruby gem that holds your AI features to the light
-executables: []
+executables:
+- diogenes
 extensions: []
 extra_rdoc_files: []
 files:
+- ".mise/config.toml"
+- ".mise/mise.lock"
+- ".mise/tasks/update-hk-import"
 - ".release-please-config.json"
 - ".release-please-manifest.json"
 - ".standard.yml"
 - CHANGELOG.md
 - CLAUDE.md
 - CODE_OF_CONDUCT.md
+- CONTRIBUTING.md
 - LICENSE.txt
 - README.md
 - Rakefile
-- docs/context.md
-- docs/contributing.md
-- docs/dashboard.md
-- docs/examples.md
-- docs/framework.md
+- Steepfile
+- docs/gates.md
+- docs/targets.md
+- exe/diogenes
+- hk.pkl
 - lib/diogenes.rb
+- lib/diogenes/cli.rb
+- lib/diogenes/cli/init.rb
+- lib/diogenes/templates/init/artifacts/decision_record.md.erb
+- lib/diogenes/templates/init/diogenes.rb
+- lib/diogenes/templates/init/hooks/README.md
+- lib/diogenes/templates/init/rules/five_gates.rb
+- lib/diogenes/templates/init/skills/example_skill.rb
 - lib/diogenes/version.rb
-- mise.lock
-- mise.toml
 - sig/diogenes.rbs
+- sig/generated/diogenes.rbs
+- sig/generated/diogenes/cli.rbs
+- sig/generated/diogenes/cli/init.rbs
+- sig/generated/diogenes/version.rbs
 homepage: https://github.com/meaganewaller/diogenes/tree/main/diogenes
 licenses:
 - MIT

data/docs/context.md

@@ -1,60 +0,0 @@
-# Supplementary Context for Contributors
-
-This file extends CLAUDE.md with additional context for common contribution scenarios. Read CLAUDE.md first.
-
----
-
-## Adding a New Gate
-
-Gates are the core of Diogenes. Adding one requires:
-
-1. A class in `lib/diogenes/gates/` inheriting `Diogenes::Gates::Base`
-2. Implementation of `#valid?` and `#failure_message`
-3. Registration in `Diogenes::Feature`
-4. Documentation in `docs/framework.md`
-5. An entry in the gate compatibility matrix (see below)
-
-Gates should be conservative by default. If configuration is ambiguous, fail loudly rather than pass silently.
-
-### Gate Compatibility Matrix
-
-Some gate configurations are incompatible with each other. The matrix lives in `lib/diogenes/gates/compatibility.rb` and is checked after all individual gates are validated.
-
-Current incompatibilities:
-- `:failure_mode severity: :financial_dispute` + `:human_in_loop verified: false` → always raises
-- `:failure_mode severity: :safety_risk` + `:user_calibration audience: :general_consumer` → always raises
-- `:user_calibration audience: :general_consumer` + `:human_in_loop verified: false` → raises unless `:failure_mode severity: :cosmetic`
-
-When adding a new gate, consider whether it creates new incompatibilities and add them to the matrix.
-
----
-
-## Working on the Audit Log
-
-The audit log has two layers:
-
-**Core layer** (`lib/diogenes/audit/`) — plain Ruby, no ActiveRecord. Produces `Diogenes::Audit::Record` structs. This must remain framework-agnostic.
-
-**Rails layer** (`lib/diogenes/engine.rb`) — ActiveRecord-backed persistence, only loaded when Rails is detected. Writes records from the core layer to the database.
-
-If you're adding fields to audit records, add them to the struct first, then to the Rails migration. Never add Rails-specific code to the core layer.
-
----
-
-## Working on the Review Engine
-
-The review engine is a Rails engine mounted at a configurable path. It has no opinions about authentication — that's the host app's job. Document this clearly in any UI-related PRs.
-
-The queue logic in `lib/diogenes/review/queue.rb` is tested without Rails. The engine views and controllers are tested with a minimal Rails app in `spec/dummy/`.
-
----
-
-## Common Mistakes
-
-**Making gates runtime checks.** Gates are boot-time. If you find yourself writing code that evaluates a gate during a request, reconsider the design.
-
-**Adding LLM-specific code.** Diogenes doesn't know what LLM you're using. If a PR requires a specific client gem, it belongs in the user's codebase.
-
-**Soft failures.** Diogenes raises when gates fail. It does not return nil, log a warning, or degrade gracefully. A feature that fails a gate should not serve AI output under any circumstances.
-
-**Storing content in audit records.** Audit records store metadata and hashes, not raw content. Raw content may contain PII. The host app is responsible for its own content storage and retention.

data/docs/contributing.md

@@ -1,228 +0,0 @@
-# Contributing to Diogenes
-
-Diogenes is opinionated by design. Before contributing, read the philosophy section of the README and the architecture notes in CLAUDE.md. A PR that conflicts with the core philosophy — even if the code is excellent — will not be merged.
-
----
-
-## What We're Looking For
-
-**Good contributions:**
-- New gates that encode a real, defensible constraint
-- Improvements to grounding verification accuracy or the verifier prompt
-- New eval matchers that cover failure modes existing matchers don't
-- Drift detection improvements — staleness scoring, webhook integrations
-- Better failure messages — they should be actionable, not cryptic
-- Dashboard improvements that surface existing data more clearly
-- Bug fixes with accompanying regression tests
-- Documentation that makes the framework clearer
-
-**Not a good fit:**
-- LLM client integrations (Diogenes is provider-agnostic by design)
-- RAG pipeline or embedding implementations
-- Gates that can be bypassed with configuration
-- Anything that makes a gate failure a warning instead of an error
-- Database-backed eval golden pairs
-- Authentication for the dashboard
-
-If you're unsure whether your idea fits, open a discussion issue before writing code.
-
----
-
-## Getting Started
-
-```bash
-git clone https://github.com/your-org/diogenes
-cd diogenes
-bundle install
-bundle exec rspec
-```
-
-The test suite should pass with no configuration. If it doesn't, open an issue.
-
-To run the full suite including Rails integration tests:
-
-```bash
-bundle exec rspec
-bundle exec rspec spec/rails
-```
-
----
-
-## Contributing to Gates
-
-Gates are the core primitive. Adding one is a significant decision — each gate adds cognitive load to every team that adopts the gem. New gates should address a failure mode that existing gates don't cover.
-
-### Steps
-
-1. Create `lib/diogenes/gates/your_gate.rb` inheriting from `Diogenes::Gates::Base`
-2. Implement `#valid?` and `#failure_message`
-3. Add any cross-gate incompatibilities to `lib/diogenes/gates/compatibility.rb`
-4. Register in `Diogenes::Feature`
-5. Write unit specs in `spec/diogenes/gates/your_gate_spec.rb`
-6. Document in `docs/framework.md` following the existing format
-7. Add to `docs/examples.md` if the gate meaningfully changes a verdict
-
-### Gate Design Rules
-
-- Gates fail loudly or pass. No warnings, no degraded modes.
-- `#failure_message` must include the feature class name, the gate name, and a plain-English instruction for what to change.
-- Gates are validated at boot. If your gate requires runtime information to validate, reconsider the design.
-- Default configuration should be the most conservative option.
-
-### Versioning
-
-Adding a new gate incompatibility to the compatibility matrix is a **minor** bump if it catches configurations that were silently wrong. It is a **major** bump if it invalidates configurations that were intentionally valid.
-
----
-
-## Contributing to Grounding Verification
-
-The grounding verifier has two separate concerns: the prompt and the logic. Keep them separate.
-
-### The Prompt (`lib/diogenes/grounding/prompt.rb`)
-
-The prompt is versioned independently. When you change it:
-
-- Increment `Diogenes::Grounding::Prompt::VERSION`
-- Audit records store the prompt version — old records remain interpretable
-- Add a spec that the new prompt correctly classifies a fixture set of (context, response) pairs as supported/unsupported/contradicted
-
-Don't change the prompt to improve performance on one case without running the full fixture set. A prompt that is better on average but worse on contradictions is not an improvement.
-
-### The Verifier Logic (`lib/diogenes/grounding/verifier.rb`)
-
-The verifier accepts any LLM callable. Tests use a stub:
-
-```ruby
-Diogenes::Grounding::Verifier.stub(result: :pass)
-Diogenes::Grounding::Verifier.stub(result: :flag, unsupported: ["claim text"])
-```
-
-Never make live LLM calls in specs.
-
-### The Result (`lib/diogenes/grounding/result.rb`)
-
-`Diogenes::Grounding::Result` is a value object. Adding fields is a minor bump. Removing or renaming fields is a major bump — audit records store serialized results.
-
----
-
-## Contributing to Drift Detection
-
-### Staleness Scoring (`lib/diogenes/drift/staleness_score.rb`)
-
-The staleness score is a pure function of timestamps and diff size. Keep it that way — no database access, no I/O. Specs use fixed timestamps.
-
-```ruby
-score = Diogenes::Drift::StalenessScore.calculate(
-  source_updated_at: 47.days.ago,
-  indexed_at: 89.days.ago,
-  diff_size: :major
-)
-```
-
-### Re-index Jobs
-
-Diogenes ships a base job class. The host app subclasses it with embedding logic. Never add embedding implementation to the base class.
-
-```ruby
-# What we ship
-class Diogenes::Drift::ReindexJob < ApplicationJob
-  def perform(document_id)
-    raise NotImplementedError, "Subclass with your embedding logic"
-  end
-end
-
-# What the host app writes
-class ReindexDocumentJob < Diogenes::Drift::ReindexJob
-  def perform(document_id)
-    # fetch, embed, store
-  end
-end
-```
-
-### Webhooks
-
-Drift alert webhooks send a standard payload. If you're adding webhook support for a new event type, use the existing payload shape and add a `type` field. Don't introduce a new shape.
-
----
-
-## Contributing to the Eval Runner
-
-### Adding Matchers (`lib/diogenes/evals/matchers.rb`)
-
-Matchers are composable predicates. A new matcher should:
-
-- Accept a response struct and return true/false
-- Have a clear, descriptive failure message when it returns false
-- Be usable inside `all_of` and `one_of`
-- Be tested against fixture responses, never live LLM calls
-
-```ruby
-module Diogenes
-  module Evals
-    module Matchers
-      def your_matcher(arg)
-        ->(result) {
-          # evaluate result, return true/false
-        }
-      end
-    end
-  end
-end
-```
-
-### Golden Pairs Live in Code
-
-Don't add database storage for golden pairs. They are version-controlled files. If a contributor wants to propose database-backed pairs, the answer is no — visibility in code review is a feature, not a limitation.
-
-### Regression Detection
-
-The regression detector (`lib/diogenes/evals/regression.rb`) stores the last passing response and diffs it against the first failing one. If you're improving diff quality, use the fixture set in `spec/fixtures/evals/regressions/`. Don't introduce a dependency on a diff library — the current implementation is intentionally minimal.
-
----
-
-## Contributing to the Dashboard
-
-The dashboard engine has no authentication and no CSS framework dependency. Keep it that way.
-
-### Adding a New View
-
-Views use ERB. No ViewComponent, no Stimulus, no Turbo (unless it's already a dependency by the time you're reading this — check the gemspec). Interactivity should be achievable with standard Rails UJS or vanilla JS.
-
-### Adding a New Route
-
-Add to `lib/diogenes/engine/config/routes.rb`. Follow the existing namespace pattern. Every new route needs a corresponding controller action and view, even if the view is a stub.
-
-### What the Dashboard Must Never Do
-
-- Make LLM calls
-- Trigger re-indexing without an explicit user action
-- Display raw query or response content (hashes only — PII protection)
-- Require specific authentication middleware
-
----
-
-## Pull Request Guidelines
-
-- One logical change per PR
-- Tests for all new behaviour
-- Updated documentation if you're changing or adding functionality
-- A clear description of *why*, not just *what*
-
-PRs that add code without updating relevant docs will be sent back.
-
----
-
-## Versioning
-
-Diogenes follows semantic versioning strictly.
-
-- **Patch:** bug fixes, documentation, internal refactors
-- **Minor:** new gates, new matchers, new dashboard views, non-breaking additions
-- **Major:** changes to gate semantics, changes to audit record shape, removal of features, breaking DSL changes
-
----
-
-## Code of Conduct
-
-Be direct. Be specific. Assume good intent. If you're reviewing a PR, explain your reasoning — "this conflicts with the philosophy" is not sufficient without explaining which part and why.