HardwareControlFabric skill documents a nonexistent default client certificate path.

Reported (UTC): 2026-07-14 03:17

What was being attempted: While watch-build reported degraded buildtest frontend observability for UrlResolver PR https://github.com/CodexCoder21Organization/UrlResolver/pull/773, I followed the mandatory server-management hierarchy and the hardware-fabric-processes skill to inspect production host 198.199.106.165 without SSH.

What went wrong: The documented base command failed exactly with 'Error: Certificate file not found: /home/leslie/.config/hardware-control-fabric/fabric-client-cert.pem' and 'java.lang.IllegalArgumentException: Certificate file not found: /home/leslie/.config/hardware-control-fabric/fabric-client-cert.pem'. The skill's Default Configuration and Quick Usage consistently reference ~/.config/hardware-control-fabric/fabric-client-cert.pem, fabric-client-key.pem, and fabric-server-cert.pem, while a later daemon-recovery example inconsistently references client_cert.pem, fabric_key.pkcs8, and server_cert.pem. No documented discovery step identifies the installed certificate filenames.

Impact: The preferred non-SSH production ground-truth path was unavailable during a CI observability flap, forcing reliance on the recovered buildtest API and preventing HardwareControlFabric verification of host-side run progress.

Workaround used: The buildtest API recovered and /api/runs reported run 8df2fb29 status BUILDING, so no SSH or destructive action was needed; the tracked build-watchman remained active.

Suggested durable fix: Update hardware-fabric-processes/SKILL.md to document the actual certificate locations on /code, add a preflight command that discovers or validates the three files, and make every example use one canonical set of filenames. If credentials are intentionally not installed, say so and document the authorized fallback rather than presenting nonexistent defaults.

Production verification — 2026-07-17

Status: STILL EXISTS. Live GitHub verification found 1 referenced tracker(s) still open: https://github.com/CodexCoder21Organization/UrlResolver/pull/773.

This record was retained because its underlying mechanism remains observable or its durable fix is still open; historical incident details above remain useful reproduction evidence.