P3.35: correct OS-process isolation claims to module/data-level independence

[franciszver]

Summary

The project's headline differentiator was stated as OS-process isolation between the Zone-A (Red Team) and Zone-B (Judge/Orchestrator/Documentation) roles. The shipped code never implemented it. redteam/campaign.py::run_campaign calls all four components as in-process Python objects inside one for loop; grep -rn "multiprocessing|subprocess|Popen|fork(" redteam/ tools/ returns nothing. docs/ARCHITECTURE.md and docs/ATO_EVIDENCE_PACKET.md nonetheless asserted "each Zone-A and Zone-B role runs as its own OS process with its own local model instance," and used that property to differentiate this platform from Garak by name — while the shipped runner does exactly what that comparison criticized Garak for.

Orchestrator ruling: option 2 (correct the docs), not option 1 (implement isolation). This PR does not implement process isolation — that is a design decision for the owner, not a finish-out task, and is called out explicitly below as still open.

What changed

• docs/ARCHITECTURE.md — prose summary (§1), interaction diagram labels (§2), the six required components (§3), the fully-local model strategy (§4), the Garak/framework-choice comparisons (§5), and the P3.4-prototype relationship (§7) all now describe module- and data-level independence (separate modules, no shared imports, typed-only inputs — e.g. the Judge scores from (case, response, attempt_id) alone, judge.py:96-100,:343) as the implemented property, with OS-process isolation stated explicitly as a design goal, not yet implemented.
  • Before (§1, line 41): "each Zone-A and Zone-B role runs as its own OS process with its own local model instance and its own context window"
  • After: "each Zone-A and Zone-B role is a separate Python module ... that imports nothing from the sibling roles it must not see into ... Running each role as its own OS process with its own local model instance is a stated design goal, not yet implemented: redteam/campaign.py::run_campaign currently calls all four components as in-process Python objects inside one for loop..."
  • Before (§5, Garak row): "No concept of Judge/Red-Team process independence (its probes and detectors run in one process)"
  • After: "No enforced module boundary between its probes and detectors ... This platform's Judge/Red-Team separation is likewise not OS-process isolation today (see §1) — the genuine difference from Garak is the enforced module boundary (an AST-scanned import guard) plus the regression DB and Orchestrator-readable observability..."
• docs/ATO_EVIDENCE_PACKET.md — data-flow diagram labels, the trust-zone-boundary paragraph, the runtime-inventory table (line 268), and the network-egress prose corrected the same way. Also corrected: only the Red Team Agent is model-backed — Judge, Orchestrator, and Documentation are deterministic by default (rule-based detect(), rule/threshold logic, fixed template respectively; confirmed no model-client code in orchestrator.py/documentation.py) — every "four AI roles run locally" phrasing that implied all four call a model is corrected.
• docs/DEMO_SCRIPT.md — a second, related stale claim found during the deep-review gate: Beat 2 described the Judge's independence guard as scanning only redteam.agents/redteam.harness and as a process boundary. Fixed to match the widened guard and the module/data framing.
• tests/redteam/test_judge_agent.py — widened the AST import guard's forbidden-prefix set from ("redteam.agents", "redteam.harness") to add "redteam.observability" (its action log carries full Red Team attempt payloads per campaign.py:311-317; confirmed judge.py imports nothing under redteam.observability today, so this doesn't break the Judge). Rewrote the test's docstring to state precisely what the AST scan does not catch: import redteam + attribute access, from redteam import agents, importlib.import_module(...), __import__, dynamic/runtime-built import strings, and transitive imports via a module judge.py itself imports.
• redteam/agents/judge.py — module docstring corrected: "separate module/context by construction," not "separate process."
• tests/test_doc_consistency.py — new red-first guard, test_no_committed_doc_claims_os_process_isolation_is_implemented. Scoped to docs/; planning/KICKOFF_PROMPT.md's verbatim historical kickoff prompt ("Build four agents with architectural (separate process/context) independence") is excluded — it's the original requirement as asked, written before any code existed, not a claim about shipped behaviour, and rewriting it would falsify the historical record.
• Updated the two "N passed[, M skipped]" test-count claims in ATO_EVIDENCE_PACKET.md and DEMO_SCRIPT.md for the one new test (tests/test_doc_test_counts.py enforces these; 233->234 passed CI-shape, 339->340 with-sibling).

Left open for the owner (not decided here)

Correcting the docs does not settle whether the platform should implement OS-process isolation. That decision — implement it, or formally adopt module-level independence as the intended architecture — remains open.

AST guard: widened, not just documented

Chose to widen (redteam.observability added to the forbidden-prefix set) rather than leave the gap only documented, because the actual attack it misses (a Judge quietly reading the action log's full Red-Team attempt payloads) is cheap to close and the Judge doesn't need anything under redteam.observability today — verified via grep -n "^import\|^from" redteam/agents/judge.py before widening (no such import exists). The guard's remaining, undocumented-until-now limits (alias imports, importlib, dynamic strings, transitive imports) are now stated precisely in the test's own docstring rather than implied to be covered.

Red-first proof

The new guard genuinely fails on unmodified main (verified by stashing the doc fixes and running the test alone):

E       AssertionError: the shipped platform has no OS-process isolation (redteam/campaign.py ::run_campaign calls all four components in-process, in one for loop; no multiprocessing/subprocess/Popen/fork under redteam/ or tools/), but the following committed docs assert process isolation as implemented behaviour without qualifying it as a design goal:
E         docs/ARCHITECTURE.md: ...aration is architectural, not cosmetic: each Zone-A and Zone-B role runs as its own OS process with its own local model instance and its own context window, so a compromised ...
E         ...
E         docs/ATO_EVIDENCE_PACKET.md: ... Orchestrator / Documentation Agents | separate local instruct-model instances, separate processes/contexts | stock instruct models ...
1 failed, 1 deselected in 0.14s

The red-first test was committed first (90cba1c), confirmed failing, then the doc fix landed in a second commit (later amended locally to drop an accidental "Closes #73" from the commit body, before push).

Gates

• declutter — swept the diff; no duplication, dead code, or speculative abstraction. Nothing to remove.
• sec-audit — diff is entirely markdown prose plus one test-only subprocess.run(["git", "grep", ...]) call with static list-form args (no shell=True, no untrusted input). No findings.
• deep-review — found and fixed one stale doc reference (DEMO_SCRIPT.md's Beat 2 described the pre-widening two-prefix guard as a process boundary) before landing.

Verification

• sha256sum docs/vuln_reports/*.json unchanged before/after (never touched): VULN-0001 6269b60e..., VULN-0002 2afe57f1..., VULN-0003 bb49602d..., VULN-0004 836cd053....
• pytest tests/ -q -> 340 passed (sibling Phase 2 checkout present, local).
• pytest tests/test_doc_consistency.py tests/test_doc_test_counts.py -q -> 2 passed / 1 passed respectively, confirming the new guard and the doc-count self-check both hold post-fix.
• Did not implement process isolation, did not merge, did not touch docs/RELEASE_NOTES_v3.0.0.md or any docs/vuln_reports/*.json.

Closes #73