booley-heallisted

# Heal a Booley project Turn Doctor findings into a verified clean project. Doctor remains the source of truth; this skill supplies the diagnosis, repair loop, external-action hand-offs, and completion discipline around it. Do not turn this into a second setup workflow. Repair the project as it exists, preserve its decisions, and avoid creating `SETUP-PLAN.md` or rerunning `booley-setup` unless Doctor explicitly proves setup is absent. ## Success contract Call the project **healed** only when every required final invocation reports: - zero `FAIL` findings; - zero active `WARN` findings; - no unexpected `SKIP` on a check used as evidence; and - no unresolved external action. An exit code of zero is insufficient because warnings do not change Doctor's exit code. `WAIVED` is not active, but report it as an accepted risk. `NOTE` is informational. A `SKIP` can be legitimate; inspect it rather than treating all skips as failures or silently counting one as a pass. Use one of these outcomes when the full contract is not met: - **Locally clean — user action required**: the Session Runtime is clean, but a host, credential, license, service, GUI, or other external action remains. - **Booley defect — feedback captured**: source inspection confirms Booley or its documentation is wrong. State whether a workaround restored health. - **Project/design issue**: Doctor exposed an RTL, testbench, or intentional project-design problem outside build-system repair. - **Repair blocked