docs: forbidden-category glosses and the supply-chain input set
Regenerated from the registry. `roeForbiddenCategories` now says what each token
covers, because "credential stuffing" rarely became `brute_force` without it, and
`supplyChainInputMode` lists its three values instead of saying free text.
docs: the engagement vocabularies are closed, not free text
Regenerated from the registry. `roeForbiddenTools`, `roeForbiddenCategories`,
`roeSensitiveDataHandling`, `roeEngagementType`, `roeStatusUpdateFrequency` and
`roeComplianceFrameworks` now list their permitted values where the table used
to say `free_text`, and `stealthMode` describes itself as the engagement's
passive switch.
The tools and categories tables matter most: both are matched EXACTLY by the
agent's dispatch gate, so a value outside the list is not a looser rule, it is
no rule at all.
docs: split Rules of Engagement into limits and record
The engagement is two unrelated things, and the wiki described it as one.
Rules-of-Engagement.md is rewritten around the split: the LIMITS are ordinary
settings, reachable from the form and the API alike and enforced at scan start,
and the RECORD is the contract a person writes and no token can touch. The
"set once at creation, read-only afterwards" claim is gone; only the record is
creation-time.
Also updated:
- Recon-Presets: a preset never carries the engagement, at capture or at apply,
and the exclusion is a registry query rather than a name-prefix match
- MCP-Server: update_recon_settings reaches the limits in either direction, and
what keeps that safe is enforcement at scan start, not a write-time rule
- Creating-a-Project: tab 1 is the Engagement Record; the limits live elsewhere
and stay editable
- Origin-Discovery: the mechanism is unchanged, the field classification is not
- AI-Gauntlet: its RoE checkbox is a per-launch confirmation, distinct from the
project's engagement limits
- Project-Settings-Reference: an Engagement Limits section, and two checked
counts instead of one wrong one. "714 configurable parameters" overstated the
surface exactly as the "245+" it replaced understated it
- Project-Settings-Registry and MCP-API-Reference: regenerated
A test fails any page that still names tighten_engagement_roe, the tighten_only
disposition, or a roe* field as MCP-settable.
docs: roeDocumentData is upload-managed, not tighten-only
Regenerated from the registry. The RoE document is a Bytes column written by
the endpoints that receive the file, so the MCP surface records its SHA-256
rather than claiming a settings write could carry it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs: the settings registry says what stealth mode does to each field
docs: regenerate the settings registry after the form-bounds correction
docs: regenerate the settings registry with the tool wiring
docs: generate the settings registry, and fix a count that was off by two thirds
Project-Settings-Reference.md opened by claiming "245+ configurable parameters"
against a model of 714. That is the failure mode of a hand-written exhaustive
reference: right on the day it is written, quietly wrong every day after, and
nobody notices because nobody counts.
The narrative page keeps its screenshots and its tour and now states the real
number, which a test checks against the registry. Beside it,
Project-Settings-Registry.md is generated from recon_settings/registry.yaml with
every parameter, its enforced bound, its default, whether an external agent may
write it, and what it means.
The rows that carry a warning carry it in the row: a rate whose zero means
unlimited, a value the engagement ceiling rewrites at scan start, a field fixed
at creation, and a column withheld from every read.
The MCP API reference picks up five new tools and the rewritten recon:settings
blurb, whose old wording broke in the direction that made the permission sound
safer than it was.