[karczuRF]

Summary

The fourth deploy (task 0026, for 0027's x402@ fix). It promotes develop at 67f03a6e onto deploy/production (68e778e3, the third deploy): 155 commits, 18 pull requests. The head is develop itself, so a later merge into develop joins this pull request too: check the list again if it moves before the merge.

The reason for it now is #163: every planned stop of x402@production ended failed (Compose's 130 after systemd's stop signal) and counted facilitator_failures_total. Since facilitator-failed went live on 2026-11-09, every deploy or restart would fire it falsely.

• What changes in the running service:
  • fix(lore-0027): count a planned facilitator stop as a success #163 (0027): SuccessExitStatus=130 in deploy/systemd/x402@.service. It reaches the server only through the playbook run after the deploy, and takes effect at the unit's next stop.
  • feat(lore-0063): list a resource from the seller's own 402 #89 and feat(lore-0063): list an MCP tool from its unpaid tools/call answer #90 (0063): a listing comes from the seller's own 402 answer, and an MCP tool from its unpaid tools/call answer. Every attempt to change a listing is recorded (catalog_attempts, migration below).
  • fix(lore-0063): list the attempt counter's labels in the catalog #155 and fix(lore-0063): give catalog_attempts_total its stage and outcome labels #157 (0063): catalog_attempts_total's labels in the metrics catalog (stage, outcome). fix(lore-0063): give catalog_attempts_total its stage and outcome labels #157 fixed develop's typecheck.
  • fix(lore-0046): answer rpc_unavailable when /settle's checks get no answer #159 (0046): /settle answers rpc_unavailable when its checks get no answer from the RPC.
  • refactor(lore-0101): read the payer's auth expiry in one place [refactor] #147 (0101): the payer's auth expiry is read in one place. Same behaviour.
  • Not part of the service: feat(lore-0027): [logic] watch the networks' protocol from off the server #145 and feat(lore-0027): turn on the facilitator, host and log volume alarms #150 (alarms and the Watch stack, deployed from a laptop and already live), test(lore-0046): give the MCP e2e its own facilitator and time limit [low risk] #127, test(lore-0029): commit the gate's run of record on the deployed facilitator [low risk] #148, feat(lore-0046): let list_resources filter by scheme #151 and test(lore-0046): pin the store guard a claim sweep relies on [low risk] #161 (tests, MCP), and docs and lore (docs(lore-0077): describe one facilitator for both networks #93, docs(lore-0027): record the balance alarms' first firing #144, docs(lore-0027): record the alarms deploy of #145 and #150 #158, docs(lore-0027): close 0027 on the live alarms, spawn 0127 #160, docs(lore-0027): record the alarm drill; memory 90%, disk 80%, audit-disk 90% #164, docs(lore-0027): list every metric and alarm, record the disk drill #166).
• What it proves: the fourth digest, and a planned stop that no longer counts as a failure once the playbook has run.

Merge it with Create a merge commit, like #119, #132 and #137, so deploy/production keeps develop's commits as they are.

Before the merge

• One new migration, 0006_catalog_seller_check (feat(lore-0063): list a resource from the seller's own 402 #89). ALTER TABLE catalog ADD COLUMN checked_at bigint (nullable) and a new catalog_attempts table with an index. It expands only, so the image in digest.good keeps working on it after a rollback. Its number is older than the migrations the server already ran (0007–0012). migrate applies every name not yet in schema_migrations, whatever its place, so it runs once, after 0012.
• The new image works with the server's current files. No change to the production compose file, the Dockerfile or the workflows. The only change under deploy/ is fix(lore-0027): count a planned facilitator stop as a success #163's unit line and its test.
• CI on the head is green. develop's push run at 67f03a6e is running; e7c921bf before it is green.

After the merge

1. Deploy production builds the image, then waits for the production environment's approval from someone other than whoever merged. It migrates, drains the old facilitator, starts the new image and waits for ready. On a failure it rolls back to digest.good.
2. Expect one facilitator-failed in #stellar-x402-bot: this deploy's restart still runs under the old unit. Post in the channel first.
3. Check /health and /supported. /health's commit is the merge commit on deploy/production.
4. Once the workflow run has ended, run the playbook from this merge (runbook, The playbook), --check --diff first. Its diff must show x402@.service gaining SuccessExitStatus=130 and nothing else, then a daemon-reload.
5. Check it: systemctl show x402@production -p SuccessExitStatus must print SuccessExitStatus=130 …. From the next stop on, a planned stop ends inactive and writes no failure.

Testing

CI on develop: green at e7c921bf, and the run at 67f03a6e is running. Merge only once the run on the head is green. #163's own test (deploy/test/units.test.ts) fails without the line. Testnet: N/A. This pull request is the deploy, and the steps above are its checks.