Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
58 lines (42 loc) · 2.12 KB

CONTRIBUTING.md

File metadata and controls

58 lines (42 loc) · 2.12 KB
Raw

Contributing to Conclave

Thanks for helping improve Conclave. Keep changes small, testable, and faithful to the decision boundary below.

Core invariant

Models may propose contracts, candidates, hypotheses, critiques, and experiments. They may not certify their own execution, turn agreement into truth, edit a frozen contract silently, or choose the winner after evidence exists. Decisive inputs must be valid executed evidence, applicable primary sources, direct user preferences, or frozen deterministic rules.

Do not add voting, debate, model confidence, or an LLM judge as a decision rule.

Architecture

  • SKILL.md defines the controller workflow and its resource ceilings.
  • assets/templates/ and schemas/ define persisted run state.
  • scripts/validate_state.py seals contracts and experiment plans.
  • scripts/run_evidence.py records process results and artifact hashes.
  • scripts/select_next_experiment.py admits only unresolved, decision-changing work that fits the remaining budget.
  • scripts/reduce_decision.py computes robust margins and statuses.
  • scripts/render_decision.py creates the user-facing decision record.

The scripts use Python 3.9+ and the standard library only. Generated run state belongs outside the installed skill package.

Development loop

Run the full regression suite:

python3 -m unittest discover -s tests -v

Run the packaged example end to end:

run_dir="$(mktemp -d)/conclave-streaming-variance"
python3 examples/streaming-variance/run_example.py --output "$run_dir"
sed -n '1,160p' "$run_dir/decision.md"

When changing a schema, template, digest, or reducer rule, add a regression test covering both the intended result and the relevant invalid or adversarial case. Preserve replay compatibility when possible; document intentional breaks.

Submitting

  1. Create a focused branch.
  2. Make one logical change per pull request.
  3. Run the tests and example.
  4. Explain which decision invariant or failure mode the change addresses.
  5. Include any replay-compatibility impact and migration requirement.

By participating, you agree to keep discussion rigorous and respectful.