The Build & Test, Architecture Overview, and Conventions & Patterns sections
were still the init template's "_Add your ... here_" stubs. Filled them in
from the code:
- No build/test tooling exists; documents the php -l quality gate and the
dev-router.php requirement for running the server locally.
- Describes the two-deployable split (WP plugin vs server/) and the
.gitattributes export-ignore rule that keeps them apart in release zips.
- Records the PHP 7.4 (plugin) / 8.1+ (server) version split that already
drifted once in 3c64dd8.
- Notes Gitea (not GitHub) as the remote, the three-file release bump, and
the open security beads to check before touching auth or the installer.
The managed beads integration block is unchanged.
Site Healthcheck
Internal WordPress plugin that walks a technician through a structured healthcheck. Companion to wp-site-recovery, which it expects to be installed as step 0.
Install
ln -s ~/dev/wp-healthcheck /path/to/wp/wp-content/plugins/att-site-healthcheck
Then activate from Plugins. Settings appear under Tools → Site Healthcheck.
Use
- Open Tools → Site Healthcheck.
- Confirm the recovery plugin status panel shows ✓ active.
- Click Start new healthcheck.
- Work through each step card. For each: choose a status (done / skipped / blocked / n/a) and add notes.
- Click Finish & generate report.
- Download the Markdown report or copy it to clipboard.
One in-progress session per site at a time. Reports are not stored in the database (the plugin is meant to be uninstalled at the end of each engagement) — download them.
Adding, removing, reordering steps
Each step is a single file under includes/steps/ named <order>-<slug>.php.
<?php
// includes/steps/45-staging.php
return new class extends ATT_HC_Step {
public function id(): string { return 'staging'; }
public function title(): string { return 'Step 4.5 — Verify Staging Sync'; }
public function sub_items(): array {
return ['Re-deploy from production', 'Run smoke tests'];
}
};
- Add: drop a new file.
- Remove: delete the file.
- Reorder: rename the numeric prefix (steps are loaded in
natsortorder). - Conditionally drop on one install: use the
att_hc_stepsfilter tounsetthe step by id.
Stable string IDs (returned by id()) are what's stored in session data, so renaming a file does not break in-progress sessions as long as the id stays the same.
Phase roadmap
Phase 1 (this) is a checklist + Markdown report. Phase 3 will add per-step automation — backup detection, env auto-collect, plugin update intelligence, PageSpeed Insights, SSL checks, etc. See beads epic hc-5ix for the full plan.
Distribution
Internal/agency tool — not a WP.org plugin (decision hc-5ix.26). Installed sites auto-update from Gitea via Plugin Update Checker (vendored under vendor/plugin-update-checker/). PUC polls updates.json on the repo's main branch twice a day; new versions appear in Dashboard → Updates.
Releasing a new version
- Bump
Version:in theatt-site-healthcheck.phpheader andATT_HC_VERSION. - Bump
versionandlast_updatedinupdates.json. - Commit + push to
main.
Installed sites pick it up on their next update check (or immediately if an admin clicks Check again on the Updates screen). The download_url points at archive/main.zip, so whatever's on main at fetch time is what gets installed.
Updating PUC itself
PUC is a vendored copy, not a submodule (so Gitea's archive/main.zip includes it). To update:
cd /tmp && git clone --depth 1 https://github.com/YahnisElsts/plugin-update-checker.git puc-new
rm -rf vendor/plugin-update-checker
cp -R /tmp/puc-new vendor/plugin-update-checker
rm -rf vendor/plugin-update-checker/{.git,.github,build,vendor,examples,composer.json,phpcs.xml}
Tracking
cd ~/dev/wp-healthcheck
bd list --label phase-1 # MVP work
bd list --label phase-3 # automation backlog