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: 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.
docs(mcp): agent onboarding, and kali:exec described as the shell it is
The API reference is regenerated from the live tools/list, so the kali:exec
permission row and the kali_exec tool now describe a shell rather than the
allowlist that no longer exists.
MCP-Server.md gains the Agent Profile table and the onboarding-pack section,
with screenshots for the profile picker, a profile change and the export.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs: the inbound MCP surface at thirty tools, and kali_exec
MCP-API-Reference is generated by `npm run docs:mcp` from the server's own
tools/list; a unit test compares it byte for byte, so it is never edited by
hand.
MCP-Server gains the kali_exec section: the four switches that gate it, the
per-tool flag allowlist and what it refuses, the 300s sandbox cap, and the
rate limits. Plus the Agent Profiles and onboarding screenshots.
docs(mcp): regenerate - build-not-deployment caveat, honest union types
docs(mcp): the verdict tool, the scanner status read, and triage:write
Tool table, permissions row, the write rate-limit row, and the permission count
(now nine). The "not exposed" paragraph now draws the distinction that matters:
an agent can record a VERDICT, which ranks a finding, and can never MUTE or
unmute one, which hides or reveals it.
MCP-API-Reference.md regenerated.
docs(mcp): seven more tools and the recon:queue permission
Tool table and heading, a permissions row, the rate-limit table (queue_recon
takes the per-project start window, not the write budget; run_graph_view and
the analytics views take the query one), and the permission count in the alt
text and in Global-Settings, now eight.
MCP-API-Reference.md regenerated from the live tools/list.
docs(mcp): eight new tools, the triage:read permission, regenerated reference
MCP-API-Reference.md is regenerated from the live tools/list, never hand-edited.
MCP-Server.md: the tool table and its heading, a permissions row, the
rate-limit table (its "Applies to" column enumerates tools per bucket, so every
row was wrong), the concurrency paragraph now that the findings path takes the
same ceiling, and the "not exposed" paragraph - the other scanners' findings
are readable while starting them is not.
Global-Settings.md and the MCP-Server alt text both said "five permissions",
which was already stale at six before this and is now seven.
docs: document the MCP Server surface, incl. kali_exec
Rename MCP-Access-Tokens to MCP-Server and cover the whole inbound
surface rather than just the token screen.
- MCP-Server: thirteen tools, the four switches guarding kali_exec, the
per-tool flag allowlist and what it refuses, rate limits and audit rows.
- MCP-API-Reference: generated by `npm run docs:mcp` from the server's own
tools/list. Never hand-edit; a unit test compares it byte for byte.
- Sidebar, Home and Global-Settings point at the new page name.