Rename Library and Templates page to Library and Blueprints
Align blueprint terminology with the canvas UI
The shipped canvas calls any cloneable starting point a "blueprint", both the
shipped ones loaded via "Load blueprint" and a user's own topology published to
the Library for others to clone. The wiki split this as "template" (shipped) vs
"blueprint" (published), which contradicted the UI. Migrate the shipped-starting
-point sense of "template" to "blueprint" across the concept and reference pages,
keeping a private working copy as a "topology". Certificate templates, GitHub
issue templates, and the [[Library and Templates]] wikilink targets are left as
is.
Canvas button is Load blueprint, not Load template
The toolbar button was renamed to "Load blueprint" in the shipped canvas; the
wiki still called it "Load template" in three places.
docs: subjective readability and structure pass
Verified subjective improvements across the wiki (clarity, structure, navigation, terminology), no command or fact changes.
docs: prerelease consistency, readability, and reporting callout
Consistency and readability pass across the wiki (terminology, schema versions, cross-links, provider matrix, grammar). Home prerelease callout now tells users to open an issue and attach the scrubbed logs/deploy-*.log for analysis.
Rename ARTIE/HAVEN to Offense/Defense across the wiki
Correct export tfvars path and teardown, add manage.sh lifecycle and enterprise notes
Correct the compile step: the Export tab compiles automatically, no Compile button
Add Library and Templates page: templates, save, publish, clone
New page explaining what each button does: templates load as a shipped starting point
(HAVEN locks with Unlock to edit, ARTIE opens editable, loading never touches the shipped
file), Save stores a private copy, Publish offers a read-only blueprint your org can clone,
and cloning makes a private copy. The Library starts empty by default. Linked from the
sidebar, Home, and Getting Started, and corrected the now-stale Blueprints section in Concepts.
Add Cloud Prerequisites page: permissions and local requirements before deploy
New page covering the two things an operator needs before running deploy.sh: a
cloud identity with permission to create the export's resources (AWS EC2 set with
AmazonEC2FullAccess as the simple path, the auto_stop IAM/Scheduler exception, and
GCP compute.admin plus enabling the Compute Engine API), and the local tools
(terraform, ssh, tar, Python), with AWS CLI and gcloud auth quick-starts and the
CPUS_ALL_REGIONS quota note. Linked from the sidebar, Home, Getting Started,
Deploying a Range, and the FAQ.
docs: multi-user VPN access, deploy logs, and the mode-named briefing
docs: wiki accuracy, onboarding, and clarity pass
- Azure moved to a preview tier (Home, Providers matrix plus a preview section);
Proxmox and ESXi stay roadmap.
- Getting-Started: a Before you begin prerequisites checklist and PowerShell
env-var forms alongside the bash ones.
- Deploying-a-Range: a billing caution up front, the real teardown command
(terraform -chdir=terraform destroy) with the missing-teardown.sh gap flagged,
plain one-line explanations of tfvars, CIDR, the SSH key, region, GCP project,
the DNS A record, and WSL, and a stronger operator_source_ranges caution.
- Concepts: a cloud-terms glossary and a schema-vs-product version note.
- Providers: a GCP quota and setup section, symmetric with the AWS one.
- Labs: per-lab walkthrough links; Home gains a step 6 to open the walkthrough.
- tone: drop the "not a course to learn them" gatekeeping; small grammar fixes.
wiki: add the ssh key step and provider selection to the deploy docs
wiki: update commands for redstackpro compile and validate
getting started: document changing the host port
add the redStackPRO wiki pages