AGENTS.md:41-42 says:
The security guards are defined in docs/DESIGN.md as invariants I1–I13. They are normative: reviewers verify them, and CI failures are never a reason to relax them.
docs/DESIGN.md defines three more:
- I14 (
DESIGN.md:52) — a bug id the policy would deny must not appear inside something the client may read. This is the link/dependency/duplicate-marker scrub.
- I15 (
DESIGN.md:103) — the audit stream is never reachable through any MCP surface.
- I16 (
DESIGN.md:110) — bugzilla_products and bug_fields return Bugzilla instance metadata, gated behind global.allow_discovery.
All three are load-bearing and cited throughout the source: I14 at server.rs link scrubbing and in the update_bug_fields see_also assessment, I15 in the audit-stream design section, I16 across the discovery tool surface.
Why it matters
AGENTS.md is the contract an agent or a new contributor reads first, and it is where the review instruction lives ("reviewers verify them"). A reviewer following it literally verifies thirteen invariants and never looks at the three that cover link scrubbing, audit-stream reachability, and discovery gating. DESIGN.md wins on conflict, so nothing is wrong in the normative sense — but the pointer into it under-counts, which is the kind of drift that gets noticed only when a review misses something.
Acceptance criteria
Noticed during the adversarial review of #68.
AGENTS.md:41-42says:docs/DESIGN.mddefines three more:DESIGN.md:52) — a bug id the policy would deny must not appear inside something the client may read. This is the link/dependency/duplicate-marker scrub.DESIGN.md:103) — the audit stream is never reachable through any MCP surface.DESIGN.md:110) —bugzilla_productsandbug_fieldsreturn Bugzilla instance metadata, gated behindglobal.allow_discovery.All three are load-bearing and cited throughout the source: I14 at
server.rslink scrubbing and in theupdate_bug_fieldssee_also assessment, I15 in the audit-stream design section, I16 across the discovery tool surface.Why it matters
AGENTS.mdis the contract an agent or a new contributor reads first, and it is where the review instruction lives ("reviewers verify them"). A reviewer following it literally verifies thirteen invariants and never looks at the three that cover link scrubbing, audit-stream reachability, and discovery gating.DESIGN.mdwins on conflict, so nothing is wrong in the normative sense — but the pointer into it under-counts, which is the kind of drift that gets noticed only when a review misses something.Acceptance criteria
AGENTS.mdnames the full range, and the range is stated in a way that will not silently rot the next time an invariant is added (e.g. "I1 onward, as defined indocs/DESIGN.md" rather than a hardcoded upper bound — or a hardcoded bound plus a note in DESIGN.md that adding an invariant means updating AGENTS.md).Noticed during the adversarial review of #68.