refactor(sites): rename "provision" terminology to "add"

[loadinglucian]

Rename validateSiteProvisioned() to validateSiteAdded() and update all user-facing messages, comments, and docblocks to use "add" instead of "provision" terminology for consistency with the site:add command.

Summary by CodeRabbit

• Chores
  • Updated terminology across site management commands from "provisioning" to "adding" for consistent language in user-facing messages and validation steps.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

This pull request updates terminology across site management commands and traits, renaming "provisioned" to "added" throughout validation method names, comments, error messages, and user-facing output to reflect updated domain language consistency.

Changes

Cohort / File(s)	Summary
Site Console Commands app/Console/Site/SiteAddCommand.php, app/Console/Site/SiteDeployCommand.php, app/Console/Site/SiteHttpsCommand.php, app/Console/Site/SiteSharedPullCommand.php, app/Console/Site/SiteSharedPushCommand.php	Terminology updates: "provisioned" → "added" in validation method calls, step labels, comments, and user-facing messages; method rename from validateSiteProvisioned() to validateSiteAdded() across call-sites
Traits app/Traits/SitesTrait.php	Method definition renamed from validateSiteProvisioned() to validateSiteAdded(); error messaging and failure-path text updated to reflect "added" terminology
Playbooks playbooks/site-add.sh, playbooks/site-https.sh	Comment text updated from "provisioned" to "added" in workflow documentation

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify method rename consistency across all 5 command classes and trait definition
• Confirm all user-facing messages and error text have been updated uniformly
• Check playbook comments align with command-level terminology changes

Possibly related PRs

• feat: site shared paths #93: Directly renames and replaces usages of validateSiteProvisioned() with validateSiteAdded() across multiple commands and traits.
• feat: site management add delete #90: Modifies the same site add flow and SitesTrait, introducing related validation and deployment logic.
• feat: add site:shared push pull commands for shared files #92: Touches the same SiteSharedPush and SiteSharedPull commands with overlapping validation method updates.

Poem

🐰 From "provisioned" to "added" we go,
The language now clearer, more aglow,
Validation renamed with semantic care,
Commands and traits, all declarations fair,
Consistency blooming, the codebase shines so!

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely summarizes the main change: renaming terminology from 'provision' to 'add' across the sites codebase.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch refactor/rename-site-provision-to-add

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 479d686 and c992dd6.

📒 Files selected for processing (8)

• app/Console/Site/SiteAddCommand.php (4 hunks)
• app/Console/Site/SiteDeployCommand.php (1 hunks)
• app/Console/Site/SiteHttpsCommand.php (1 hunks)
• app/Console/Site/SiteSharedPullCommand.php (1 hunks)
• app/Console/Site/SiteSharedPushCommand.php (1 hunks)
• app/Traits/SitesTrait.php (2 hunks)
• playbooks/site-add.sh (1 hunks)
• playbooks/site-https.sh (1 hunks)

🧰 Additional context used

📓 Path-based instructions (5)

**/*.sh

📄 CodeRabbit inference engine (.cursor/rules/05-bash.mdc)

**/*.sh: Use [[ ... ]] for conditionals instead of [ ... ] or test
Use $(...) for command substitution instead of backticks
Use ((...)) and $((...)) for math operations, never use let
Define functions without the function keyword and always use local for function variables
Place then on the same line as if and do on the same line as while in block statements
Prefer parameter expansion over external commands (e.g., use ${0##*/} instead of $(basename "$0"))
Use double quotes for variable expansions and single quotes for literals
Use Bash arrays instead of space-separated strings, and quote array expansions with "${array[@]}"
Check commands that can fail by using || or && operators (e.g., cd /path || exit)
Use set -o pipefail in playbooks to catch pipeline errors
Do not use set -e (errexit); prefer explicit error checking instead
Never use eval due to security risks and inability to perform static analysis
Use redirection or built-in read for reading files instead of piping cat to other commands
Use globs for listing files instead of parsing ls output
Use tabs for indentation in Bash scripts
Maintain a maximum line length of 80 columns in Bash scripts
Use semicolons only in control statements (e.g., if true; then), not elsewhere
Maintain a maximum of 1 blank line between sections in Bash scripts
Use shebang #!/usr/bin/env bash at the start of Bash scripts
Run composer bash to format all Bash scripts before completing the task and fix all issues
Run composer bash:check to verify Bash script formatting without modifying files

**/*.sh: All playbook files MUST start with shebang #!/usr/bin/env bash and set set -o pipefail (NOT set -e), followed by export DEBIAN_FRONTEND=noninteractive
Validate DEPLOYER_OUTPUT_FILE environment variable before any work; provisioning playbooks must also validate DEPLOYER_DISTRO and DEPLOYER_PERMS, then export DEPLOYER_PERMS
Use main() function as entry point with...

Files:

• playbooks/site-https.sh
• playbooks/site-add.sh

**/*.php

📄 CodeRabbit inference engine (.cursor/rules/00-main.mdc)

**/*.php: Eliminate single-use methods: inline if called once
Cache computed values: initialize expensive calculations in constructor
Avoid method call overhead: direct property access when appropriate
Group related functions into comment-separated sections
Order code alphabetically after grouping logically

**/*.php: Follow PSR-12 standard, use strict types, and use PHP 8.x features (unions, match, attributes, readonly)
Provide explicit return types with generics (e.g., Collection<int, User>) for all functions and methods
Use Dependency Injection via Symfony patterns instead of manual instantiation
Use Symfony classes (Filesystem, Process, etc.) over native PHP functions for testability
Always place constants on the left side of comparisons (Yoda conditions) to prevent accidental assignment
Use @var annotations to help PHPStan understand types it cannot infer, not assert() in production code
Always add use statements for vendor packages and project classes; root namespace FQDNs acceptable for exceptions (e.g., \InvalidArgumentException)
Use $container->build(ClassName::class) for all object creation except DTOs, value objects, and pure data structures
Use Constructor Injection in production code for Container access; direct instantiation permitted in tests
Use minimalist DocBlock descriptions with parameter and return type annotations for classes and functions
Remove comments when removing code and maintain visual separation between comment sections with specific formatting (headers, paragraphs)
Run Rector for code improvements, Pint for style fixes, and PHPStan for static analysis on all changed PHP files before completing tasks

**/*.php: Return null or false only for optional operations; required operations must throw complete exceptions rather than silently failing
Exception messages must be complete (include context like paths, names, IDs, hosts), user-facing (avoid technical jargon), and actionable without being fragments that require concat...

Files:

• app/Console/Site/SiteSharedPushCommand.php
• app/Console/Site/SiteHttpsCommand.php
• app/Console/Site/SiteDeployCommand.php
• app/Console/Site/SiteAddCommand.php
• app/Console/Site/SiteSharedPullCommand.php
• app/Traits/SitesTrait.php

**/*Command.php

📄 CodeRabbit inference engine (.cursor/rules/03-commands.mdc)

**/*Command.php: NEVER use Symfony IO methods directly - use BaseCommand methods exclusively. All console output flows through custom methods in BaseCommand for consistent TUI styling.
Use BaseCommand custom IO methods exclusively: out(), hr(), h1(), info(), yay(), nay(), warn(), ul(), ol(), displayDeets(), commandReplay(), getOptionOrPrompt(), getValidatedOptionOrPrompt(), promptText(), promptPassword(), promptConfirm(), promptSelect(), promptMultiselect(), promptSuggest(), promptSearch(), promptPause(), promptSpin().
Use laravel/prompts for ALL user interactions with functions: text, password, confirm, select, multiselect, suggest, search, and spin.
Support both interactive prompts AND CLI options using getOptionOrPrompt() pattern in Symfony Console commands.
For boolean flags, use InputOption::VALUE_NONE for simple flags (--yes, -y) and InputOption::VALUE_NEGATABLE for tri-state flags (--flag, --no-flag).
For multiselect prompts, handle both array (from prompt) and comma-separated string (from CLI option) inputs.
For multi-path prompts offering different execution paths, create separate options for each path instead of a single option with conditional branching.
When using getOptionOrPrompt() (not validated version), validate CLI values explicitly against allowed options/resources.
Always call commandReplay() before returning SUCCESS to display the non-interactive CLI syntax for the command with the options used.
Command option naming convention: Use --server / --domain for SELECTING existing resources, --name for DEFINING new resources, --host / --port for server config, --yes / -y for confirmations, --force / -f for destructive operations.
Use OPTIONS only (never ARGUMENTS) in Symfony Console commands to enable getOptionOrPrompt() dual-mode support.
Only --yes (-y) and --force (-f) should have short flags in Symfony Console commands.
Add type annotations on opt...

Files:

• app/Console/Site/SiteSharedPushCommand.php
• app/Console/Site/SiteHttpsCommand.php
• app/Console/Site/SiteDeployCommand.php
• app/Console/Site/SiteAddCommand.php
• app/Console/Site/SiteSharedPullCommand.php

**/*.{php,js,ts,tsx,jsx,py,java,cs,go,rb,rs}

📄 CodeRabbit inference engine (.cursor/rules/rules.mdc)

**/*.{php,js,ts,tsx,jsx,py,java,cs,go,rb,rs}: Use inline comments over separate explanations in code examples
Prefer inline comments to prose explanations in code examples

Files:

• app/Console/Site/SiteSharedPushCommand.php
• app/Console/Site/SiteHttpsCommand.php
• app/Console/Site/SiteDeployCommand.php
• app/Console/Site/SiteAddCommand.php
• app/Console/Site/SiteSharedPullCommand.php
• app/Traits/SitesTrait.php

**/*{Trait,Validator}*.php

📄 CodeRabbit inference engine (.cursor/rules/04-exceptions.mdc)

**/*{Trait,Validator}*.php: Input validation methods in Validation Traits must return ?string (error message or null) for prompts and CLI options, with method names following the pattern validateNameInput()
Heavy I/O validation methods must throw \RuntimeException with complete error messages, with method names following the pattern validate*() without the 'Input' suffix

Files:

• app/Traits/SitesTrait.php

🧠 Learnings (4)

📚 Learning: 2025-12-02T17:16:03.074Z

Learnt from: CR
Repo: php-deployer/php-deployer PR: 0
File: .cursor/rules/06-playbooks.mdc:0-0
Timestamp: 2025-12-02T17:16:03.074Z
Learning: Applies to **/*.sh : Validate `DEPLOYER_OUTPUT_FILE` environment variable before any work; provisioning playbooks must also validate `DEPLOYER_DISTRO` and `DEPLOYER_PERMS`, then export `DEPLOYER_PERMS`

Applied to files:

• playbooks/site-https.sh

📚 Learning: 2025-12-02T17:16:03.074Z

Learnt from: CR
Repo: php-deployer/php-deployer PR: 0
File: .cursor/rules/06-playbooks.mdc:0-0
Timestamp: 2025-12-02T17:16:03.074Z
Learning: Applies to **/*.sh : Write YAML output to `DEPLOYER_OUTPUT_FILE` and check for write errors; if playbook exits before creating this file, framework treats all output as error message

Applied to files:

• playbooks/site-https.sh

📚 Learning: 2025-12-02T17:16:03.074Z

Learnt from: CR
Repo: php-deployer/php-deployer PR: 0
File: .cursor/rules/06-playbooks.mdc:0-0
Timestamp: 2025-12-02T17:16:03.074Z
Learning: Applies to **/*.sh : All playbook files MUST start with shebang `#!/usr/bin/env bash` and set `set -o pipefail` (NOT `set -e`), followed by `export DEBIAN_FRONTEND=noninteractive`

Applied to files:

• playbooks/site-https.sh
• playbooks/site-add.sh

📚 Learning: 2025-12-02T17:16:03.074Z

Learnt from: CR
Repo: php-deployer/php-deployer PR: 0
File: .cursor/rules/06-playbooks.mdc:0-0
Timestamp: 2025-12-02T17:16:03.074Z
Learning: Applies to **/*.sh : Playbooks must be idempotent: check if resource already exists before acting, validate conditions before making changes, and never fail if resource already exists

Applied to files:

• playbooks/site-https.sh

🧬 Code graph analysis (6)

app/Console/Site/SiteSharedPushCommand.php (1)

app/Traits/SitesTrait.php (1)

• validateSiteAdded (231-259)

app/Console/Site/SiteHttpsCommand.php (1)

app/Contracts/BaseCommand.php (1)

• nay (222-225)

app/Console/Site/SiteDeployCommand.php (1)

app/Traits/SitesTrait.php (1)

• validateSiteAdded (231-259)

app/Console/Site/SiteAddCommand.php (2)

app/Traits/PlaybooksTrait.php (1)

• executePlaybookSilently (37-52)

app/Contracts/BaseCommand.php (1)

• yay (206-209)

app/Console/Site/SiteSharedPullCommand.php (1)

app/Traits/SitesTrait.php (1)

• validateSiteAdded (231-259)

app/Traits/SitesTrait.php (4)

app/DTOs/ServerDTO.php (1)

• ServerDTO (7-40)

app/DTOs/SiteDTO.php (1)

• SiteDTO (7-24)

app/Contracts/BaseCommand.php (2)

• nay (222-225)
• out (264-267)

app/Services/IOService.php (1)

• out (57-74)

🔇 Additional comments (7)

playbooks/site-add.sh (1)

6-6: Comment rename aligns playbook with site:add terminology

The updated header comment now correctly describes the playbook as adding a site, matching the site:add command and SitesTrait messaging, with no behavioral impact. Based on learnings, the rest of the playbook still conforms to the required playbook structure (shebang, set -o pipefail, env validation, YAML output).

playbooks/site-https.sh (1)

10-10: Precondition comment now matches “added” site workflow

The updated note (“Requires site to be already added.”) correctly reflects the new terminology and matches the validation performed via validateSiteAdded() in the PHP commands, without changing script behavior.

app/Console/Site/SiteDeployCommand.php (1)

137-141: Validation step correctly switched to validateSiteAdded

The comment and call now clearly express that deployment requires an already added site, and the call to validateSiteAdded($server, $site) matches the updated trait method signature with no control-flow changes.

app/Console/Site/SiteHttpsCommand.php (1)

93-107: HTTPS command messages now consistently reference added sites

The updated texts (“has not been added yet”, “Run site:add…”, and “re-add the site…”) align HTTPS enablement with the site:add lifecycle and with validateSiteAdded(), improving consistency without touching control flow.

app/Console/Site/SiteSharedPushCommand.php (1)

95-99: Shared push now validates using validateSiteAdded

The step label and call have been updated to validate that the site is already added on the server, keeping behavior in sync with SitesTrait::validateSiteAdded() and other site commands.

app/Console/Site/SiteSharedPullCommand.php (1)

87-91: Shared pull validation aligned with “added” terminology

The shared pull flow now explicitly validates that the site has been added using validateSiteAdded(), which keeps this command consistent with deploy and shared:push.

app/Console/Site/SiteAddCommand.php (1)

74-82: Site add flow text consistently reflects “add” semantics

The updated section headers, spinner message (“Adding site...”), success line (“Site added successfully”), and validateServerReady docblock now all describe adding a site rather than provisioning, matching the command name and downstream validation helpers.

Also applies to: 115-136, 191-201

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}