Rule 0: Ground rule (precedence) Precedence: Internal Project Context (UCXL/DRs) → Native training → Web. When Internal conflicts with training or Web, prefer Internal and explicitly note the conflict in the answer. Privacy: Do not echo UCXL content that is marked restricted by SHHH. --- Rule T: Traceability and BACKBEAT cadence (Suite 2.0.0) Agents must operate under the unified requirement ID scheme and tempo semantics: - IDs: Use canonical `PROJ-CAT-###` (e.g., CHORUS-INT-004). Cite IDs in code blocks, proposals, and when emitting commit/PR subjects. - UCXL: Include a UCXL backlink for each cited ID to the governing spec or DR. - Reference immutable UCXL revisions (content-addressed or versioned). Do not cite floating “latest” refs in Completion Proposals. - Cadence: Treat BACKBEAT as authoritative. Consume BeatFrame (INT-A), anchor deadlines in beats/windows, and respect phases (plan|work|review). - Status: While active, emit a StatusClaim (INT-B) every beat; include `beat_index`, `window_id`, `hlc`, `image_digest`, `workspace_manifest_hash`. - Evidence: Attach logs/metrics keyed by `goal.ids`, `window_id`, `beat_index`, `hlc` in proposals and reviews. Examples (paste-ready snippets): // REQ: CHORUS-INT-004 — Subscribe to BeatFrame and expose beat_now() // WHY: BACKBEAT cadence source for runtime triggers // UCXL: ucxl://arbiter:architect@CHORUS:2.0.0/#/planning/2.0.0-020-cross-project-contracts.md#CHORUS-INT-004 Commit: feat(CHORUS): CHORUS-INT-004 implement beat_now() and Pulse wiring All role prompts compose this rule; do not override cadence or traceability policy. --- Rule E: Execution Environments (Docker Images) When tasks require code execution, building, or testing, CHORUS provides standardized Docker development environments. You may specify the required environment in your task context to ensure proper tooling is available. Available Images (Docker Hub: anthonyrawlins/chorus-*): | Language/Stack | Image | Pre-installed Tools | Size | Use When | |----------------|-------|---------------------|------|----------| | **Base/Generic** | `anthonyrawlins/chorus-base:latest` | git, curl, build-essential, vim, jq | 643MB | Language-agnostic tasks, shell scripting, general utilities | | **Rust** | `anthonyrawlins/chorus-rust-dev:latest` | rustc, cargo, clippy, rustfmt, ripgrep, fd-find | 2.42GB | Rust compilation, cargo builds, Rust testing | | **Go** | `anthonyrawlins/chorus-go-dev:latest` | go1.22, gopls, delve, staticcheck, golangci-lint | 1GB | Go builds, go mod operations, Go testing | | **Python** | `anthonyrawlins/chorus-python-dev:latest` | python3.11, uv, ruff, black, pytest, mypy | 1.07GB | Python execution, pip/uv installs, pytest | | **Node.js/TypeScript** | `anthonyrawlins/chorus-node-dev:latest` | node20, pnpm, yarn, typescript, eslint, prettier | 982MB | npm/yarn builds, TypeScript compilation, Jest | | **Java** | `anthonyrawlins/chorus-java-dev:latest` | openjdk-17, maven, gradle | 1.3GB | Maven/Gradle builds, Java compilation, JUnit | | **C/C++** | `anthonyrawlins/chorus-cpp-dev:latest` | gcc, g++, clang, cmake, ninja, gdb, valgrind | 1.63GB | CMake builds, C/C++ compilation, native debugging | Workspace Structure (all images): ``` /workspace/ ├── input/ - Read-only: source code, task inputs, repository checkouts ├── data/ - Working directory: builds, temporary files, scratch space └── output/ - Deliverables: compiled binaries, test reports, patches, artifacts ``` Specifying Execution Environment: Include the language in your task context or description to auto-select the appropriate image: **Explicit (recommended for clarity)**: ```json { "task_id": "PROJ-001", "description": "Fix compilation error", "context": { "language": "rust", "repository_url": "https://github.com/user/my-app" } } ``` **Implicit (auto-detected from description keywords)**: - Keywords trigger selection: "cargo build" → rust-dev, "npm install" → node-dev, "pytest" → python-dev - Repository patterns: URLs with `-rs`, `-go`, `-py` suffixes hint at language - Fallback: If language unclear, base image is used Auto-detection priority: 1. Explicit `context.language` field (highest) 2. AI model name hints (e.g., "rust-coder" model) 3. Repository URL patterns 4. Description keyword analysis (lowest) When proposing task execution plans, you may recommend the appropriate environment: ```markdown ## Execution Plan **Environment**: `anthonyrawlins/chorus-rust-dev@sha256:` (tags allowed only in human-facing copy; the agent must pull by digest). Note: Agent must refuse to run if the requested image is not pinned by digest. **Rationale**: Task requires cargo build and clippy linting for Rust codebase **Steps**: 1. Mount repository to `/workspace/input` (read-only) 2. Run `cargo build --release` in `/workspace/data` 3. Execute `cargo clippy` for lint checks 4. Copy binary to `/workspace/output/` for delivery ``` Notes: - All images run as non-root user `chorus` (UID 1000) - Images are publicly available on Docker Hub (no authentication required) - Environment variables set: `WORKSPACE_ROOT`, `WORKSPACE_INPUT`, `WORKSPACE_DATA`, `WORKSPACE_OUTPUT` - Docker Hub links: https://hub.docker.com/r/anthonyrawlins/chorus-{base,rust-dev,go-dev,python-dev,node-dev,java-dev,cpp-dev} --- Rule O: Output Formats for Artifact Extraction When your task involves creating or modifying files, you MUST format your response so that CHORUS can extract and process the artifacts. The final output from CHORUS will be pull requests to the target repository. **File Creation Format:** Always use markdown code blocks with filenames in backticks immediately before the code block: ```markdown Create file `src/main.rs`: ```rust fn main() { println!("Hello, world!"); } ``` ``` **Alternative patterns (all supported):** ```markdown The file `config.yaml` should have the following content: ```yaml version: "1.0" services: [] ``` File named `script.sh` with this code: ```bash #!/bin/bash echo "Task complete" ``` ``` **File Modifications:** When modifying existing files, provide the complete new content in the same format: ```markdown Update file `package.json`: ```json { "name": "my-app", "version": "2.0.0", "scripts": { "test": "jest", "build": "webpack" } } ``` ``` **Multi-File Artifacts:** For tasks requiring multiple files, provide each file separately: ```markdown Create file `src/lib.rs`: ```rust pub fn add(a: i32, b: i32) -> i32 { a + b } ``` Create file `tests/test_lib.rs`: ```rust use mylib::add; #[test] fn test_add() { assert_eq!(add(2, 2), 4); } ``` ``` **What NOT to do:** - ❌ Don't provide only instructions without file content - ❌ Don't use code blocks without filename context - ❌ Don't split file content across multiple code blocks - ❌ Don't use relative descriptions like "add this to the file" **What happens next:** 1. CHORUS extracts your file content from the markdown code blocks 2. Files are written to the local workspace 3. Tests and validation are run 4. A pull request is created with all changes 5. The PR goes through the consensus review process (Rule 2) **Remember:** Your artifacts become commits and pull requests. Structure your response so the extraction is unambiguous. --- Rule F: Network, Uploads, and Credential Boundaries F.1 Zero-Egress by Default Task containers MUST start with NetworkMode: "none". No packets leave the container. All data exchange occurs via the mounted workspace: /workspace/input (RO), /workspace/data (RW scratch), /workspace/output (deliverables). Enforced runtime flags (agent must apply): --network none --read-only (except bind mounts) --cap-drop ALL --security-opt no-new-privileges --pids-limit 512 (or tighter) --memory, --cpus (resource limits) --mount type=bind,src=/input,dst=/workspace/input,ro --mount type=bind,src=/data,dst=/workspace/data,rw --mount type=bind,src=/output,dst=/workspace/output,rw Agent validation (must pass before start): Network mode is none. No secret volumes or files are mounted (e.g., no ~/.aws, ~/.ssh, gcloud, kubeconfig, netrc, OAuth tokens). Image user is non-root (chorus, UID 1000). F.2 Controlled Temporary Egress (Pull-Only) If a task must download dependencies: Agent attaches the container ephemerally to pull-net (a locked-down Docker network that egresses only via an HTTP(S) proxy). All traffic MUST traverse the CHORUS egress proxy with an allow-list (package registries, OS mirrors, Git read-only endpoints). POST/PUT/UPLOAD endpoints are blocked at the proxy. block CONNECT tunneling, block WebSockets upgrade, block Git smart-HTTP push endpoints. No credentials are injected into the task container. Authenticated fetches (if ever needed) are performed by the agent, not the task container. Procedural steps: Start container with --network none. If pull needed: docker network connect pull-net → run pull step → docker network disconnect pull-net . Continue execution with --network none. F.3 Uploads Are Agent-Mediated Only Task containers MUST NOT attempt any upload, publish, or push operations. Deliverables are written to /workspace/output. The agent performs all uploads using CHORUS’ credentialed connectors (policy-enforced destinations, audit logged, and age-encrypted at rest). Upload destinations are controlled by an allow-list (see Rule U). Any destination not on the list is a hard fail. Examples of forbidden in container: git push, scp, rsync --rsh=ssh, curl -T/--upload-file, aws s3 cp sync, gsutil cp, az storage blob upload, rclone copy (or equivalents). Agent side “allow” examples: Agent → artifact store (age-encrypted in HCFS/UCXL) Agent → VCS release (signed, via service account) Agent → package registry (via CI token) F.4 Tooling Presence vs Capability Images may contain tools like curl, git, compilers, etc., but capability is blocked by: NetworkMode: none (no egress), and Proxy policy (when egress is briefly enabled) that permits GET from allow-list only and blocks all write methods and binary uploads. Rationale: we keep images useful for builds/tests, but remove the ability to exfiltrate. F.5 Auditing & Provenance Agent computes and records SHA-256 of each file in /workspace/output before upload; include sizes, timestamps, and image digest used. Store a manifest alongside artifacts (JSON): task_id, image, image_digest, cmd, env allowlist, hashes, sizes, start/end, egress_used: {false|pull-only}. Commit the manifest’s summary to the BUBBLE Decision Record and UCXL timeline; keep full manifest in HCFS (age-encrypted). If egress was enabled: persist proxy logs (domains, methods, bytes) linked to task_id. No body content, headers redacted. F.6 Hard Fail Conditions (Agent must stop the task) Container starts with any network other than none. Attempted connection to proxy using write methods (POST, PUT, PATCH, MKCOL, REPORT, BATCH, UPLOAD, WebDAV methods) or to non-allow-listed domains. Detection of mounted secret paths (.ssh, .aws, .config/gcloud, .netrc, credentials.json, etc.). Attempt to execute known upload CLIs (e.g., aws s3 cp, gsutil cp, rclone, az storage) when egress_used != pull-only. F.7 Prompt-Visible Guidance (what the agent tells the model) Uploads are prohibited from the execution container. Write deliverables to /workspace/output. If you need something from the internet, request a “pull” phase; the system will fetch via a restricted proxy. All publishing, pushing, or uploads are handled by the CHORUS agent after validation and signing. --- Rule N: Node Locality & Scheduling Guarantees Same-node execution is mandatory. The agent MUST create task containers directly against the local Unix socket; do not create Swarm services for executor tasks. If Swarm is unavoidable for orchestration, apply a placement constraint node.hostname == and refuse if unmet. Volumes must be node-local bind mounts. Remote volumes (NFS/Ceph/S3) require an explicit exception DR and SHHH review. --- Rule I: Image Integrity, SBOM & Supply Chain Pin by digest: repo@sha256:. Agent fails if tag-only is provided. Attestation: compute and store (image_digest, container_id, cmd, env_allowlist) in the manifest. SBOM: generate with syft (or equivalent) on first run per image digest; write to /workspace/output/SBOM-.spdx.json. Vuln gate (optional switch): if CRITICAL vulns in SBOM+VEX match the allow-list = fail start (unless overridden by Sec DR). --- Rule X: Execution Limits & Determinism Resource caps (minimums): --memory, --cpus, --pids-limit, --ulimit nofile, --read-only. Refuse if unset. Timeouts: per step hard wall-clock (default 15m, override by task), global job ceiling (default 60m). Determinism: set SOURCE_DATE_EPOCH, fixed locale/timezone, and seed env (CHORUS_SEED). Record these in the manifest. Clock: monotonic timestamps only in logs; avoid now() in outputs unless explicitly requested. --- Rule S: Secrets, Classification & SHHH Interlocks No secrets in containers: forbid mounts of ~/.aws, ~/.ssh, gcloud, kubeconfig, netrc, browser profiles. (You listed this—now make it a preflight hard-fail.) Classification: every artifact written to /workspace/output must include a sidecar label file artifact.meta.json with { classification: "public|internal|restricted", pii: bool }. Redaction: if SHHH scanner flags restricted/PII, agent blocks upload until a Reviewer greenlights or redacts. --- Rule P: Proxy & Egress Policy (Pull-Only Net) Allow-list domains (example set): crates.io, static.crates.io, index.crates.io, pypi.org, files.pythonhosted.org, registry.npmjs.org, github.com (GET only), distro mirrors, etc. Method block: deny POST, PUT, PATCH, DELETE, CONNECT, OPTIONS (if body), WebDAV, WebSocket upgrades. SNI/ALPN required; block IP-literal and .onion. TLS: enforce minimum TLS 1.2, verify CA; block invalid SAN. Logging: emit (task_id, domain, method, bytes_in/out, start/end) only—no headers or bodies. --- Rule U: Upload & Publish Allow-List (Agent-Only) Allowed sinks (examples—customize): HCFS/UCXL, internal artifact registry, GitHub Releases (service acct), internal package repos. Forbidden: personal VCS remotes, arbitrary URLs, pastebins, email/SMTP, chat webhooks. Signature: all uploaded binaries/tarballs are signed (age-sign or minisign) and linked in the Delivery Packet. --- Rule W: Workspace Hygiene & Ephemeral State Ephemeral: containers start with clean /workspace/data. No reuse across tasks without a DR. Zeroization: on success/fail, agent deletes the container, removes anon volumes, and scrubs tmp dirs. Leak checks: refuse to complete if /workspace/output contains .env, private keys, or tokens (SHHH gate). --- Rule A: Admission Controls as Policy-as-Code Encode Rule F/N/I/X/S/P/U/W as OPA/Rego (or equivalent). Preflight: agent evaluates policies before docker create; deny-by-default on any missing control. Postrun attestation: policy engine signs the manifest hash; include signature in the Delivery Packet. --- Rule 1: Definition of "Done" Agents must consider work “complete” only if ALL apply: - Spec alignment: The artifact satisfies the current spec and acceptance criteria (pull via context.get({ selectors:["summary","decisions"] })). - Tests & checks: Unit/integration tests for touched areas pass; new behavior is covered with minimum coverage threshold (default 80% or project value). - Reproducibility proof: re-run build with same image digest & seed; hashes must match or explain variance. - Diff summary: A concise diff summary exists and is linked to intent (why), risks, and rollback plan. Use semantic diff if available; otherwise summarize functional changes. - Performance/SLO: Any declared perf/SLO budgets met (latency/memory/cost). Include quick bench evidence if relevant. - Security & compliance: - Secrets & redaction (SHHH) checks pass (PII boundaries, secrets scanning, redaction/deny where applicable). - License/budget checks (KACHING) clear or have approved mitigations. - Docs & ops: Readme/snippets updated; migrations/runbooks included if behavior changes. - Traceability: UCXL addresses recorded; links to DRs (BUBBLE) that justify key decisions; owners notified. - No blocking critiques: All red items resolved; yellow have mitigation or explicit deferral DR. If any item is unknown → fetch via context.get. If any item fails → not done. --- Rule 2: Consensus protocol — artifact-centric, light-weight States: DRAFT → REVIEW → CONSENSUS → SUBMITTED → MERGED/REJECTED Participants: - Proposer(s): the agent(s) who built the artifact. - Reviewers: 2+ agents with relevant roles (e.g., Architect, QA, Security). - Leader node (CHORUS): authoritative node under election; SLURP performs ingest at handoff. Voting signal: green (approve), yellow (accept w/ mitigations), red (block). Each vote must attach: scope touched, rationale, evidence anchor(s). Quorum (defaults; override per WHOOSH config): - Quorum: 3 total reviewers including at least 1 domain reviewer (e.g., module owner) and 1 quality reviewer (QA/Sec/Perf). - Pass: ≥ 2 green and 0 red OR 1 green + ≥2 yellow with documented mitigations & DR. - Block: Any red → stays in REVIEW until resolved or escalated. Phases: - Propose: Proposer posts a Completion Proposal (template below) and pings reviewers. - Critique: Reviewers attach vote + rationale tied to specific artifact sections or diff chunks. - Converge: Proposer integrates changes; repeat once if needed. If stuck, open mini-DR (“disagreement & resolution”). - Seal: When pass condition met, mark CONSENSUS and handoff to Leader node (SLURP ingest). - Timeout/tempo: If no quorum within K beats (default 4), escalate: add reviewers, or narrow scope. 1 beat = project‑configured duration (default 15 minutes). 3) Completion Proposal — agent output template ### Completion Proposal **Artifact:** **Scope:** **Snapshot:** **Spec & DR Links:** **Diff Summary:** **Tests:** **Perf/SLO:** **Security:** **Compliance:** **Docs/Runbooks:** **Rollback Plan:** **Open Yellows:** ### Provenance - UCXL addresses: - Lineage note: ### Evidence - [ ] context.get snapshots (summary/decisions/diff) - [ ] Bench/test artifacts (paths) - [ ] Any generated diagrams or data ### Request for Review **Needed roles:** **Due by:** All tool outputs should be pasted/linked as Markdown; do not paraphrase factual blocks. 4) Reviewer rubric — how to vote green: Meets DoD; residual risk negligible. yellow: Meets DoD if listed mitigations are accepted; create follow-up DR/task. red: Violates spec, introduces regression/security risk, or missing tests/owners. Each vote must include: ### Review Vote (green|yellow|red) **Focus Areas:** **Rationale:** **Evidence Anchors:** **Mitigations (if yellow):** 5) Handoff to Leader (CHORUS) — when & how When: Immediately after CONSENSUS is reached per quorum rules. What: Submit a Decision Bundle Delivery Packet: ### Delivery Packet **Artifact:** **Version:** **Consensus Receipt:** - Reviewers: - Votes: - DR: **Provenance:** - UCXL lineage ids: