# rederive — agent setup & first verified re-derivation

You are setting up rederive (verified compute for the code you ship: software is built as verified units, each
carrying a contract — a spec and a held-out oracle — with implementations rebuilt blind and accepted on quorum;
dependencies disappear by consequence, and npm serves as a library of oracles) and running its loop for me.
Follow these steps in order.

0. Install the CLIs (Node ≥ 18): `npm i -g rederive sir-factory`. Verify with `rdv --help`.

1. **Install the frame into the project — this step is not optional:** run `rdv init .` in the project root.
   It writes the rederive section into CLAUDE.md/AGENTS.md, an agent roster, hooks that protect contract
   artifacts and re-verify touched units, and a pre-commit + CI seal. Commit what it writes. From here on,
   the scaffold — not this document — is your working frame; re-read the CLAUDE.md section it added.

2. If you are Claude Code, also install the plugin: `/plugin marketplace add rederive/sir-toolkit`, then
   `/plugin install sir@sir-toolkit` (adds the `sir-verify`, `greenfield-quorum`, and `preflight` skills plus
   the full role-agent roster). Other agents: the CLIs + the scaffold are enough — the methodology docs live
   at https://github.com/rederive/sir-toolkit and the spec at https://github.com/rederive/sir-spec.

3. Ask me which of these I want:
   a. VERIFY — re-prove a verified package against its contract: `rdv check <dir>`. Deterministic, offline,
      no tokens; safe in CI as `rdv check <dir> && deploy`.
   b. RE-DERIVE — get a dependency out of my trust tree: decompose it into a contract + oracle, rebuild it
      blind, and accept it only on quorum (the `sir-verify` skill drives `sir-factory`:
      install → decompose → stamp → re-emit → grade → pack).
   c. DE-DEPENDENCY A PROJECT — the whole-tree version of (b), in this order:
      c1. BASELINE (gate — do not start any decomposition before this): run the project's own test suite
          and report the counts to me (e.g. "182 passing, 1 known failure"). This number is the finish line.
      c2. Enumerate the runtime dependencies (skip devDependencies and types-only packages — say so if you skip one).
      c3. Re-derive each, leaves first; vendor the verified sources with provenance headers.
      c4. Rewire the imports; remove the dependencies from package.json.
      c5. Re-run the project's test suite and report baseline vs. after — the counts must match.
      Keep the verification bundles in the repo so CI can re-prove every vendored unit with `rdv check`.
      Quarantine (and report) anything you cannot soundly verify — an ambient-effect unit, an RNG core, a
      licensing gap — rather than shipping it unverified.
   d. PREFLIGHT — my code has no tests: build a measured-strength characterization oracle first
      (coverage inputs → adversarial review → mutation testing → chaos pass), then use it as the
      source of truth for (b) or for a migration.
   e. BUILD NEW CODE — I'm building a feature or an app "using rederive": decompose it into NAMED leaves
      (behaviors with names worth saying out loud — the kind npm packages, RFCs, or algorithm literature
      already name; glue stays thin), then per leaf: contract + stamped oracle → implement or blind-re-emit
      via 2–3 isolated re-emitter subagents (the roster `rdv init` installed) → accept on quorum →
      `rdv check` green. The `greenfield-quorum` skill drives this end to end.
      Do NOT invent an internal spec format — the SIR spec exists: https://rederive.ai/spec.html.
   If I name a project and say it has too many dependencies, that means (c). If I say "build X using
   rederive", that means (e). If I'm not sure, propose (b) on my smallest pure dependency and estimate
   the time before starting.

4. Two objections you will be tempted by — the answers, in advance:
   - "This is too big to spec." → Decompose further. A leaf too big to contract is two leaves.
   - "This is non-deterministic." → The nondeterminism (clock, network, randomness, model calls) lives at
     the EFFECT BOUNDARY as injected inputs; the core stays deterministic and oracle-testable. A wrapper
     around an LLM is deterministic plumbing around a nondeterministic input.

5. Run the loop. The discipline is non-negotiable: expected values are NEVER hand-authored — they are stamped
   by executing the original (or a chosen reference). Held-out cases stay hidden from whoever implements. If a
   gate fails, report the failure precisely; do not tune inputs or retry your way past it — a miss is a finding.

6. When it is green, give me three things: the `rdv check` output, where the verified bundle lives, and one
   sentence stating exactly what was proven (quorum, held-out count, verified envelope). For mode (c), also
   the before/after test-suite counts — a mode-(c) result without a baseline number is incomplete.

The toolkit is immutable from your seat: never edit `rdv` or `sir-factory` to make a check pass — if you hit a
real tool bug, report it (github.com/rederive/sir-factory/issues) or quarantine the unit. The hooks `rdv init`
installed enforce the same rule for this project's contracts: a red check is a finding, not an obstacle.