Repository navigation
docs: describe role-based placement instead of a fixed VM count (#15194) - #16445
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
) Security docs described access-control and service-auth blast radius as "across 6 VMs" / "6-VM architecture", implying a fixed topology. AutoBot is role-based and count-agnostic: Docker, one VM, or any number of machines an operator scales to. - SECURITY_FRAMEWORK.md, ACCESS_CONTROL_ROLLOUT_RUNBOOK.md, ACCESS_CONTROL_SAFE_ROLLOUT_GUIDE.md: rewrite the architecture/blast-radius claims to be role-based; VM1-VM5 comment labels become role names. - FILE_PERMISSIONS_SECURITY_ARCHITECTURE.md: VM1/VM4 deployment-target labels become role names (frontend / AI-ML). - ACCESS_CONTROL_ROLLOUT_SUMMARY.md, SERVICE_AUTH_DAY3_DEPLOYMENT_COMPLETE.md, SERVICE_AUTH_ENFORCEMENT_ROLLOUT_PLAN.md: these are dated records of one completed/in-flight rollout, so the counts stay but are now labelled as that one install's layout, not the architecture.
AutoBot has no fixed VM count: it runs in Docker, on one VM, or scales
out by role across any number of machines an operator chooses. 54+
documents (and agent/skill configs, infrastructure scripts, and API
docs) described a fixed "6-VM" / "5-VM" topology as the architecture,
or used VM1-VM5 as role identifiers.
- Role-name conversion: VM1/VM2/VM3/VM4/VM5 used as labels become the
role they name (frontend, NPU worker, database, AI/ML, browser)
across .claude/agents, autobot-backend prompts, autobot-infrastructure,
autobot-slm-backend, and docs/{developer,operations,guides,monitoring,
planning,api,user-guide,troubleshooting,project,research}.
- Architecture/capability claims describing a fixed count as *the*
architecture are rewritten to state the actual range: Docker, one VM,
or role-based scaling to any count.
- Internal IPs found while editing (172.16.168.x) are redacted to the
existing placeholder convention.
- Dated rollout/deployment/test-result records keep their historical
counts, now labelled as one install's layout, not the architecture.
- Added an issue cross-link to INTEL_NPU_WINDOWS_DEPLOYMENT_ANALYSIS.md
per the lint-conventions research-doc rule (#13876).
d822b1f to
cfa9c25
Compare
|
Review at Verified the branch's real diff against its true merge-base with main ( Sampled ~250 of the ~1060 changed content lines across the largest files (SECURITY_FRAMEWORK.md, IMPLEMENTATION_COMPLETE.md, the production-validation reports, the SSH-hardening README, the deployment/redis/NPU docs): every hunk I checked is on-topic for #15194 — either (a) role-based language replacing a fixed "6-VM"/"5-VM" architecture claim, or (b) a hardcoded internal IP (172.16.168.2x) replaced with a role placeholder ( Historical/dated reports (ANA_backend-critical-issues-architectural-2025-10-05.md, ARCHITECTURE_COMPLIANCE_IMPLEMENTATION_REPORT.md, IMPLEMENTATION_COMPLETE.md) get a short disclaimer note added at the top rather than an exhaustive rewrite of body prose — a few "6 VM" mentions remain in body text below the disclaimer in a couple of files (IMPLEMENTATION_COMPLETE.md lines 33/251, the 20250911 production-validation reports, BACKEND_ROOT_CAUSE_IMPLEMENTATION_PLAN.md). Consistent with the disclaimer-not-rewrite pattern already used elsewhere in this same PR for historical documents — not a defect, just noting it's a deliberate scope boundary rather than an exhaustive sweep. No blocking issues. |
Refs #15194
Single-issue rationale: this is the documentation half of #15194. The ADR, the architecture documents, the code comments and the placement tests are in a sibling PR on
issue-15194-adr-architecture. The guard against reintroduction lands after both, because on base it would fail against whichever half hasn't merged yet.Thinking Path
AutoBot has no fixed VM count. It runs in Docker, on one VM, or with its roles scaled out across as many machines as the operator chooses (owner-confirmed on #15194). Across
docs/, the agent definitions and the infrastructure docs, a six-VM topology was stated as the architecture. In security documents that turns a machine count into an assumed blast radius ("bypass across 6 VMs", "deploy keys to all 6 VMs"), so they're swept first.What Changed
docs/security/documents and the access-control rollout runbook now state blast radius by role, not by a machine count.docs/areas: operations, planning, developer, guides, monitoring, api, troubleshooting, user-guide, glossary, roadmap and system-state..claude/agents/, two chat prompt resources, and docs underautobot-infrastructure/shared/andautobot-slm-backend/.<role-ip>placeholder.docs/adr/,docs/architecture/,docs/archives/, and links into them. That's the sibling PR's scope, or history.Verification
verify-ssh-security.shchecks for at least 6 known hosts.npu-worker-vm2identifier innpu_workers.yaml.vm1-frontendtovm5-browsernames in the logging scripts.Model Used
Claude Opus 5 (coordinator) with a Claude Sonnet 5 subagent for the sweep.