Remove payments, verify five real break-fix scenarios, state repair scope honestly - #23
Merged
Conversation
added 3 commits
July 25, 2026 06:38
Payments were half-built: /api/checkout created real Lemon Squeezy sessions, but the order_created webhook handler was `// TODO: Mark fix as paid in database`, so a configured store could charge $2 and nothing recorded it or unlocked anything. Rather than leave a path that can take money and forget, the surface is removed — the checkout endpoint, the payment page, the payment webhook, and the now-unused Lemon Squeezy signature verifier. Svix verification stays: the Resend inbound-email webhook still uses it. Site and results copy no longer imply a paid tier is coming — ClawFix is MIT and free, with no payment path in the product. Security regressions now assert the payment routes stay gone instead of asserting they validate their input.
…ly covers Detection is 5/5 against a real OpenClaw 2026.6.11 install: gateway down, port conflict (named with the squatting process and PID), corrupt config, missing loopback auth, and auto-update restart-loop risk. Repair is a narrower story and the notes say so: ClawFix ships one executable repair, gateway-not-running, and it invokes , which needs systemd or launchd — so on a container host it cannot succeed, and the four other problems it detects have no repair at all. The pipeline itself behaved correctly end to end, reporting verify_failed with a rescan that agreed. Also notes two issues visible only in real output: a bare '[critical] timeout' finding from a collector timing out, and raw JSON5 parser text used as a user-facing title.
The site said 'guarded repairs' without saying how much is actually automated. Today that is one reviewed repair — restarting a stopped gateway, and only on a host with systemd or launchd. The four other problems verified against a real install (port conflict, corrupt config, missing loopback auth, auto-update restart-loop risk) are detected but not repaired. Backed by copy assertions, alongside one that keeps the removed payment surface from being advertised again.
prove:remediation read src/routes/payment.js directly, so deleting the payment surface broke a CI step that npm test does not cover — my local gates passed and CI failed. The contract now checks the results route and asserts the payment surface stays gone: no src/routes/payment.js, no paymentRouter in server.js. Verified by running every CI step locally this time: npm test, prove:remediation, validate:repairs, npm audit, the node --check sweep, and the CLI package allowlist check.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Payments removed, and ClawFix run against a real OpenClaw 2026.6.11 install broken five
different ways on a Blaxel sandbox.
Payments removed
/api/checkoutcreated real Lemon Squeezy sessions while theorder_createdhandler was// TODO: Mark fix as paid in database— a configured store could charge $2 and record nothing.Removed the checkout endpoint, the payment page, the payment webhook and the now-unused Lemon
Squeezy verifier. Svix verification stays; the Resend inbound-email webhook uses it.
security-regressionsasserts those routes stay 404, and the site no longer implies a paid tier.Five real break-fix scenarios
Each resets the box to a valid config, breaks one real thing, and scans.
[critical] Gateway is not runningPort conflict detected+Gateway port 18789 is occupied by python3 (PID 726), but OpenClaw cannot reach itopenclaw.jsoncorrupted[high] JSON5 parse failed: SyntaxError…noneon loopback[critical] Gateway auth missing on loopback+Gateway HTTP APIs are reachable without authupdate.auto.enabled = true[medium] Auto-update enabled (risk of restart loops)Detection: 5/5. Scenario 2 names the squatting process and its PID.
What it actually repairs — and why the site now says so
The guarded-repair pipeline ran end to end against the real install: plan built locally,
invalid_tokenrejected, single-use token enforced, apply executed the realopenclaw gateway restart, verify re-checked the port, outcome reported asverify_failed, anda rescan agreed the gateway was still down. That is correct behaviour and it is the B-24 fix
working — before the earlier pass, that same run would have claimed
applied.But it is not a fix, and the reason is worth being plain about: ClawFix ships exactly one
executable repair and it cannot work in a container.
gateway-not-runninginvokesopenclaw gateway restart, which needs systemd or launchd; this Alpine host answered "systemduser services are unavailable". The four other problems above have no repair at all.
So the site now says one reviewed repair runs automatically today — restarting a stopped gateway
on a service-managed host — and everything else is diagnosis and guidance. Asserted in tests so
it cannot drift back.
Two issues visible only in real output
[critical] timeoutwith no context — a native collector timing out isshown to the user as a critical OpenClaw problem.
JSON5 parse failed: SyntaxError: JSON5: invalid character 'i' at 1:8.Both are noted in
REVIEW.mdrather than fixed here, to keep this change reviewable.Gates
387 node tests, 87 TUI tests, tsc clean.