# Change Management (Security Discipline)

ThreeGate treats *capability changes* as security boundary changes.

This document defines what requires review, version bumps, and explicit documentation.

---

## Categories of Changes

### A) Security Boundary Changes (Require explicit review)
- Adding or widening FETCH allowlists (domains, content types, size caps)
- Enabling redirects by default
- Adding Monty external functions
- Allowing Monty any I/O (filesystem/env/network)
- Allowing ERA networking
- Introducing new execution backends
- Changing validator strictness to accept previously rejected patterns
- Modifying policy files in ways that broaden capability

**Process**
1. Open PR with “Security Boundary Change” label
2. Update `CHANGELOG.md`
3. Update relevant schema or policy docs
4. Add/modify adversarial tests where applicable
5. Require reviewer sign-off before merge

### B) Schema Changes (Require versioning)
- Any change to required keys/sections
- Any meaning change to existing fields

**Process**
1. Copy schema doc to a new version (v2, v3, …)
2. Update validators to accept old + new versions or provide migration
3. Update `CHANGELOG.md`

### C) Non-security Changes (Normal review)
- Documentation clarifications
- Refactoring that preserves behavior
- Test additions that don’t change enforcement

---

## “No Silent Drift” Rule

If the effective capability of the system changes, the documentation must change in the same PR.

---

## Release Cadence

- Use semantic versioning for tagged releases when you reach that point.
- Until then, keep `CHANGELOG.md` updated and treat main as “rolling.”

---

## Quick Checklist for PR Authors

- [ ] Does this widen what FETCH can reach?
- [ ] Does this enable new I/O or new syscalls?
- [ ] Does this allow new code execution paths?
- [ ] Does this reduce validator strictness?
- [ ] Does this modify policy invariants?

If any are “yes”, treat as a security boundary change.