feat(cleanroom): end to end dual review, isolated authoring and signed evidence pilot

.github/workflows/ci.yml

@@ -50,3 +50,5 @@ jobs:
           echo "RUDEVOLUTION_TEST_IMAGE=$IMAGE" >> "$GITHUB_ENV"
       - name: Run real isolated Room B regression
         run: node --test npm/test/clean-room-docker.test.js
+      - name: Execute two-room signed handoff and authoring pilot
+        run: node --test npm/test/clean-room-e2e-docker.test.js

README.md

@@ -51,6 +51,12 @@ npm run cleanroom -- validate examples/clean-room/calculator.spec.json
 
 **Important boundary:** The CLI does not provision independent OS identities, prevent covert data encoded inside permitted scalars, attest a human reviewer, establish a license exception, or prove functional equivalence. Independent source access isolation, human evidence review, and legal authorization are required before describing a deployment as clean room.
 
+### End to end clean room pilot
+
+The [two-room end to end pilot](docs/clean-room/E2E.md) adds independently signed reviewer key registries, dual reviewer release, revision and revocation checks, known-marker transfer screening, separate synthetic offline authoring, signed Docker evaluation and hash-chained evidence checkpoints. Run `npm run cleanroom:pilot` for the operator commands and `npm run test:cleanroom` for the synthetic fixtures. The [threat model and invariants](docs/adr/ADR-143-cleanroom-end-to-end-pilot.md) distinguish implemented checks from production requirements.
+
+**Do not use this as evidence of lawful independent authorship.** The CI pilot uses simulated reviewers and containers on one runner. Production needs separate Room A and Room B identities, machines, model contexts, memories, keys and audited transfer authority.
+
 ## Reproducible source checkout
 
 ```bash

docs/adr/ADR-143-cleanroom-end-to-end-pilot.md

@@ -0,0 +1,61 @@
+# ADR 143: Two room synthetic interoperability pilot
+
+Status: Implemented as an opt-in developer pilot, not production accreditation
+Date: 2026-10-09
+Depends on: ADR 139, 140, 141, 142
+
+## Decision
+
+Extend the existing signed specification handoff and isolated evaluator with a root-signed reviewer registry, independent second approval, one-way transport, constrained disclosure checks and a hash-chained audit ledger.
+
+1. Room A performs authorized static analysis. A human writes a bounded interface-only proposal. The primary Ed25519 reviewer explicitly approves it using the existing CLI.
+2. A different secondary reviewer signs a domain-separated release commitment. The signers and signer keys must differ. Room A applies restricted-marker disclosure checks, including simple encoded equivalents and high-entropy scalar rejection. Reviewer acknowledgement is a procedural assertion, not cryptographic proof of a human review.
+3. An independently managed root Ed25519 private key signs a versioned trust registry containing public reviewer/worker keys, role scopes, validity, revocation timestamps and expiry. Room B independently provisions the root PUBLIC key and a minimum acceptable registry revision. Registry rollback, expiration, or current revocation fail closed.
+4. Only the approved release is transferred from Room A. Room B verifies the registry and both signatures before creating any scaffold. It receives no reference code, recovered AST, raw traces, private keys, agent memory or source map.
+5. Room B authoring is independent of Room A. In CI, a synthetic fixture author runs inside a restricted Docker container with no network, a contract-only mount and a distinct unprivileged process identity. This tests authoring-stage isolation, NOT separate production hosts.
+6. The existing offline Docker evaluator accepts only an independently authored implementation and validated harness/contract. It requires complete vector accounting, rejects early successful exit, and stages only three files.
+7. A distinct worker Ed25519 key signs the v2 evaluation report. A bounded local JSONL hash chain stores only approval/release/registry/evaluation digests and status. Every append requires an external expected ledger head. An independent checkpoint must be maintained outside the mutable file.
+8. An incremented root-signed registry revocation must block old releases and workers once the independent minimum revision is raised.
+
+## Security invariants
+
+CR-14: The only Room A to Room B payload is the signed, schema validated two-person release.
+
+CR-15: The Room B root public key and minimum registry revision are supplied independently and never accepted from an untrusted release.
+
+CR-16: Reviewer identities, reviewer signing keys and the worker signing key are pairwise distinct and role scoped.
+
+CR-17: The CI authoring container mounts no Room A source, keys, shared agent memory, vector index or repository.
+
+CR-18: Every ledger append verifies an active reviewer release, active worker signing role and a valid signed v2 result against a separately anchored prior head.
+
+CR-19: Restricted plaintext, common base64/hex encodings and obvious opaque scalar values fail the Room A transfer scanner. This is a limited check, not general steganographic prevention.
+
+CR-20: No original source or root/reviewer/worker private signing key enters the evaluation container.
+
+## Trust domains
+
+| Domain | Allowed materials | Forbidden materials |
+| --- | --- | --- |
+| Room A analyst | Authorized original source and local analysis evidence | Room B implementation write identity |
+| Primary and secondary reviewers | Human-reviewed interface and separate private reviewer keys | Room B authoring state or worker signing key |
+| Offline trust officer | Public key roster and root private signing key | Default app runtime and shared AI memory |
+| Room B author | Reviewed public contract and independent workspace | Original source, Room A prompts/logs/repos/retrieval/credentials |
+| Room B evaluator | Signed release, independently pinned root key, restricted policy, own worker key | Original source or arbitrary Room A artifacts |
+| External auditor | Signed outcome, root public trust anchor, independently anchored ledger head | All private keys and original source |
+
+## Validation and residual boundaries
+
+Unit tests cover registry tampering, dual approval, source marker disclosure, revoked reviewer/worker, rollback floor, symlink/overwrites, and evidence hash chain tampering.
+
+An independent GitHub Actions job additionally runs a synthetic full workflow using a real offline Docker authoring process, followed by the hardened isolated Docker compatibility evaluator and verified signed worker evidence. The marker remains only in Room A throughout the test.
+
+These tests do NOT demonstrate that a real coding model has unlearned proprietary source, that human reviewers are independent, that the source license permits reverse engineering, or that all possible covert channels are blocked. Public primitive test vectors can be memorized. Docker shares a host kernel and daemon authority is privileged. CI runs on a single disposable runner and is not equivalent to independently provisioned production VMs.
+
+Production promotion requires distinct RuFlo/Federation/RuVector identities and contexts, independent service principals and GitHub permissions, human rights review, HSM or managed key lifecycle, held-out stateful and asynchronous tests, external write-once anchoring, and adversarial exfiltration exercises.
+
+## Rollback
+
+The new operator CLI is opt-in. Disable it without weakening existing Ed25519 approvals or v2 isolated evaluation. Preserve externally anchored ledger heads and historical signed receipts; publish higher signed registry revisions to revoke compromised keys.
+
+See the operator runbook in docs/clean-room/E2E.md and the outstanding governance gates in ruvnet/core-memory issue 148.

docs/clean-room/E2E.md

@@ -0,0 +1,166 @@
+# Clean Room End to End Pilot
+
+This is a **synthetic, permissioned interoperability pilot**, not an automatic cloning tool or legal certification. The new optional operator CLI verifies both Room A reviewers, enforces an independently signed key registry, creates a minimal Room B project, runs its independently written code in Docker, signs the result and maintains a hash-chained evidence ledger.
+
+The original decompiler is never imported into Room B.
+
+## Architectural boundary
+
+~~~text
+Room A: authorized reference and human-reviewed interface
+    |
+    v
+Primary Ed25519 approval
+    |
+    v
+Second reviewer signature + known-source marker screening
+    |
+    +-----> signed release.json (only approved transfer)
+               |
+               v
+Room B: independent root public key + signed registry + revision floor
+               |
+               v
+Verify BOTH signatures, key roles, expiry and revocation
+               |
+               v
+Generate 4-file independent scaffold
+               |
+               v
+Independent author (no Room A access or shared memory)
+               |
+               v
+Offline, restricted Docker compatibility evaluation
+               |
+               v
+Separate worker Ed25519 signature
+               |
+               v
+Append digests and status to ledger using EXTERNAL expected head
+~~~
+
+**Production warning:** The test runs on a disposable GitHub runner and uses a deterministic, synthetic author. It does not prove VM or cloud tenant separation for a real coding agent. For protected source, provision separate Room A and Room B hosts, accounts, GitHub access, prompt stores, RuFlo/Federation routing, RuVector memory and audit logs. Never let the independent author read the analyzer's data or state.
+
+## Required operators and prerequisites
+
+Use Node 22 or 24. Room B evaluation requires local Docker with a separately reviewed Node runtime pinned by immutable digest. Maintain three different Ed25519 roles: offline registry root, primary/secondary Room A reviewers, and a distinct Room B worker signing identity. Signing keys require owner-only filesystem permissions, and should be held in separate operator vaults.
+
+### 1. Sign a fresh registry in the offline trust domain
+
+The root officer prepares registry.json as shown below. Public keys are actual Ed25519 PEM text, not placeholders, and must correspond to independently established identities.
+
+~~~json
+{
+  "format": "rudevolution.cleanroom.registry/v1",
+  "revision": 14,
+  "issuedAt": "2026-10-09T12:00:00.000Z",
+  "expiresAt": "2026-10-10T12:00:00.000Z",
+  "keys": [
+    {
+      "id": "primary.one", "role": "primary",
+      "publicKey": "<approved Ed25519 PEM>",
+      "validFrom": "2026-10-09T00:00:00.000Z",
+      "validUntil": "2026-10-10T12:00:00.000Z", "revokedAt": null
+    },
+    {
+      "id": "secondary.two", "role": "secondary",
+      "publicKey": "<different Ed25519 PEM>",
+      "validFrom": "2026-10-09T00:00:00.000Z",
+      "validUntil": "2026-10-10T12:00:00.000Z", "revokedAt": null
+    },
+    {
+      "id": "worker-one", "role": "worker",
+      "publicKey": "<different worker Ed25519 PEM>",
+      "validFrom": "2026-10-09T00:00:00.000Z",
+      "validUntil": "2026-10-10T12:00:00.000Z", "revokedAt": null
+    }
+  ]
+}
+~~~
+
+~~~bash
+node npm/src/clean-room/pilot-cli.js registry-sign \
+  registry.json registry-root-private.pem registry.signed.json
+~~~
+
+Revocation is a new root-signed revision with a revokedAt timestamp. Room B must obtain the updated registry through its independently controlled trust channel and raise its minimum accepted revision. An older signed registry cannot detect its own revocation.
+
+### 2. Room A two-person review and disclosure controls
+
+An authorized analyst writes the narrow interface specification. A primary reviewer approves it using the existing CLI. A **different human** reviews the proposal, signatures, purpose, rights and disclosure constraints and executes the secondary release step.
+
+The optional restricted-markers.json remains in Room A and is **not** transferred. It contains known protected strings used as denylist sentinels. This scanner also rejects simple hex/base64 encodings and suspicious opaque scalars; it cannot guarantee absence of steganography in valid numbers or strings.
+
+~~~bash
+node npm/src/clean-room/cli.js approve \
+  proposal.json primary-private.pem primary.one \
+  approved.json room-a-receipt.json --ack-reviewed
+
+node npm/src/clean-room/pilot-cli.js release \
+  approved.json primary-public.pem secondary-private.pem \
+  secondary.two release.json --ack-independent restricted-markers.json
+~~~
+
+Only the new release.json file crosses into Room B. The acknowledgement flags are auditable procedural assertions, not proof of human presence. Do not automatically turn ruDevolution decompiled output into a release.
+
+### 3. Room B intake with separate trust anchor
+
+Provision signed-registry.json, a trusted root public key, and the minimum revision through a controlled channel distinct from the release. This operator-controlled revision is a rollback defense; do not select it from untrusted metadata.
+
+~~~bash
+node npm/src/clean-room/pilot-cli.js verify-release \
+  release.json registry.signed.json pinned-root-public.pem 14
+
+node npm/src/clean-room/pilot-cli.js intake \
+  release.json registry.signed.json pinned-root-public.pem 14 \
+  independent-project
+~~~
+
+Intake creates exactly four scaffold files. Only implementation.mjs is edited. Implementers must work on a separate Room B machine with no Room A credentials, shared model context, prompt cache or retrieval index.
+
+### 4. Evaluate and checkpoint
+
+Keep policy.json outside the implementation directory. It independently pins the approved primary reviewer key fingerprint, immutable Docker image digest, target and expiry, as described in the [base handoff guide](README.md).
+
+~~~bash
+node npm/src/clean-room/pilot-cli.js evaluate \
+  release.json registry.signed.json pinned-root-public.pem 14 \
+  policy.json independent-project \
+  'node@sha256:<pinned-runtime-digest>' \
+  worker-private.pem worker-one evidence.jsonl \
+  '<prior-external-64-hex-ledger-head>' \
+  evaluation-report.json signed-evaluation.json
+
+node npm/src/clean-room/pilot-cli.js verify-evidence \
+  signed-evaluation.json trusted-worker-public.pem worker-one \
+  '<approved-artifact-sha256>' evidence.jsonl \
+  '<new-external-64-hex-ledger-head>'
+~~~
+
+For an empty ledger the prior head is exactly 64 zero characters. After evaluation, record the NEW head in an independent, access controlled checkpoint such as an immutable object or audit service. Every later append must supply the previously recorded head; reverting the ledger then fails.
+
+The evidence ledger is a local exclusive-lock, fsync-backed, hash-chained JSONL file storing digests, status and sequence only. It is not write-once media, a trusted timestamp or proof of a safe host. A signature authenticates the Room B worker key, not software authorship or complete semantic equivalence.
+
+### 5. Negative acceptance and key revocation
+
+Set revokedAt on a reviewer or worker, increment the registry revision, sign it with the same independent root key and update Room B's trusted registry and revision floor. Reusing the old release must fail before creation of any implementation worktree or new Docker evaluation.
+
+~~~bash
+npm run test:cleanroom
+npm test
+~~~
+
+The full synthetic end to end Docker test runs automatically in CI. Locally it is enabled with an already-pulled immutable image:
+
+~~~bash
+RUDEVOLUTION_TEST_IMAGE='node@sha256:<locally-available-image-digest>' \
+  node --test npm/test/clean-room-e2e-docker.test.js
+~~~
+
+The Docker test checks unique Room A source markers never enter Room B, B authoring has no network or Room A mount, public compatibility vectors all execute, signed results verify, tampered ledgers fail and a revoked reviewer blocks further intake.
+
+## Production acceptance is still separate
+
+The pilot does not provision separate cloud service principals, block a malicious provider with shared model memory, attest the authoring host, enforce key revocation against stale independently pinned registries, provide general DLP or test held-out asynchronous/stateful protocols. Two person review and legal authorization must be independently established.
+
+For the architectural threat model see [ADR 143](../adr/ADR-143-cleanroom-end-to-end-pilot.md) and the production gates in [core-memory issue 148](https://github.com/ruvnet/core-memory/issues/148).

docs/clean-room/README.md

@@ -1,5 +1,7 @@
 # ruDevolution Clean Room: reviewed interface handoff
 
+**New:** [End to end dual reviewer pilot and registry/ledger operator guide](E2E.md). This extends the developer preview without replacing its explicit review and independent host requirements.
+
 This is a **bounded developer preview** of an audited specification handoff. The workflow supports authorized behavioral analysis and independent implementation. It is *not* an automatic software cloning engine or a legal assurance of clean room independence.
 
 > **Critical separation:** Room A may contain third-party original code and reviewer signing keys. Room B must never mount Room A data, repositories, private keys, execution logs, model context, retrieval indexes, or secrets. The new optional Docker runner restricts **evaluation of independently written Room B code**. It does **not** isolate the upstream coding agent, provision Room B hosts, or certify legal independence.
@@ -180,6 +182,7 @@ The regression and Docker fixtures place a synthetic proprietary marker in a Roo
 * [ADR 139: Isolation and specification firewall](../adr/ADR-139-clean-room-isolation-and-specification-firewall.md)
 * [ADR 140: Signed approvals and compatibility evidence](../adr/ADR-140-clean-room-attestation-and-compatibility-evidence.md)
 * [ADR 141: Isolated Room B evaluation and pinned trust](../adr/ADR-141-room-b-isolated-evaluation.md)
+* [ADR 143: Two room end to end pilot](../adr/ADR-143-cleanroom-end-to-end-pilot.md)
 * [Prior security review](../reviews/2026-09-security-performance.md)
 
 Before using third-party software, document authorization and obtain legal review. This command's sandbox does not guarantee the authoring agent is uncontaminated. Before claiming a **production** clean room deployment, validate OS isolation, access controls, audit retention, no shared model context, key custody, a red-team test for covert vector transfer, and independent reviewer procedures. For software compatibility, separate observable behavior from implementation details and report fixture coverage honestly.