2026-08-26: extensions.bazaar was echoed empty for every resource, found reconciling a real integrator's conformance report against the live deployment instead of assuming either side was right. Two of the report's three claimed gaps didn't match the raw 402 challenge (description and the bazaar declaration were both fully populated there), but did match GET /discovery/resources and GET /discovery/search, which both echoed extensions.bazaar: {} regardless. Root cause: the catalog tracked which extension keys a resource declared, never their actual payload, contradicting @x402/extensions/bazaar's own DiscoveryResource type, which documents that field as "Extension payloads echoed from discovery." Fixed with a new extension_payloads column, deployed, and verified against the live catalog with a real re-settled payment (12470945ac72..., Horizon-verified): GET /discovery/search now returns the full declared info/schema object. Separately deleted a stale Phase 4 test fixture (financial_analysis_da8703fa-..., literal placeholder asset/payTo values, surfacing in every search result regardless of relevance) that the same reconciliation turned up. The report's CORS-header claim, initially left unresolved, turned out to measure a different, unrelated deployment entirely (confirmed by the report's own author and independently corroborated), never Periplo.

The first real external seller published and settled for real the same round (agentpayments.fi), and found a genuine, money-relevant bug doing it: EXTENSION-RESPONSES never reached their code from /settle, even though cataloging worked. Root cause verified before fixing, not assumed: a direct fetch to /settle showed the header is sent correctly on the wire, so the gap traced to the installed @x402/[email protected] dependency itself, whose HTTPFacilitatorClient. settle()/.verify() read the header only to console.log it internally, then discard it, never attaching it to what those methods return to the caller, confirmed reading the actual compiled source. Filed as x402-foundation/x402#3270, with a proposed fix (populate the extensions field those response types already declare but never use). Status: fixed on our own side the same day, not waiting on the upstream merge. /settle's JSON body now also carries the outcome in that same already-declared-but-previously-empty extensions field, verified through the real official client, not just a raw fetch: transaction 10919a59342fc0cc..., Horizon-verified. A community member (Bartok9) built the upstream fix: #3278, open, not yet merged. Reviewed the real diff line by line before saying so, not on the strength of the PR description: it matches the body-wins/header-fallback precedence proposed in #3270 exactly, and ships four regression tests, not the three the PR's own summary implies (the fourth, a malformed-header case, wasn't something we'd asked for, a good defensive addition on its own initiative). Went further than reading the diff: pulled #3278's own branch (bartok9/extension-responses-header-3270, 54b136d), built its @x402/core directly, and ran a real payment through it against our own production facilitator, https://periplo-testnet.fly.dev, the exact deployment the original bug came from. verify()/settle() both real, settleResult.extensions populated, transaction 892af0974bee..., Horizon-verified. Honest about scope: this exercised the body-wins branch, the only one reachable against a facilitator that already sends extensions in the body on our own side, not the header-only fallback, which stays covered only by Bartok9's own mocked tests. A separate, unrelated version-skew finding from the same run (a client-side spendControls guard newer than what we pin) is tracked in docs/DEFERRED.md, not repeated here.

Update, 2026-08-30: the same finding rippled across three separate SDK implementations. wnjoon, who triaged #3270 in the thread, independently confirmed the identical gap in the Go client (go/http/facilitator_client.go's verifyHTTP/settleHTTP discard the decoded header the same way the TypeScript client does) and opened #3301 themselves, explicitly refing this issue and #3278 as its Go parity follow-up, deliberately keeping #3270 open rather than closing it against a single-language fix. A Python draft addressing the same gap in python/x402/http/facilitator_client.py's HTTPFacilitatorClient/HTTPFacilitatorClientSync is open as PhilBot402/x402#4 (a fork PR, still a draft, not yet opened against the upstream repo itself), also linking back to #3270 directly. Three independent SDK-language fixes now trace to the one issue this project opened: TypeScript (#3278, Bartok9), Go (#3301, wnjoon), Python (PhilBot402/x402#4, draft). All three open, none merged as of 2026-08-30, verified live before writing this (see the 2026-09-02 update below for what actually merged).

Resolved upstream, 2026-08-31, not by the three PRs above directly. #3270 closed the same day (stateReason: COMPLETED), but the fix that actually closed it was a maintainer's own separate PR, #3306 (Python, phdargen), merged 2026-08-31T15:59:00Z, two seconds before the issue closed. Its own description rejects the shape #3278/#3301 originally shipped, merging the header data into the existing extensions field, calling that "the wrong shape" since it leaks a server-only sidechannel into a field the resource server forwards to buyers via PAYMENT-RESPONSE. It introduces a separate extension_responses field instead, excluded from that buyer-facing encoding. #3278 was revised to match before merging, confirmed against its real merged diff: it now populates extensionResponses, explicitly "Never merges into extensions," and merged separately, 2026-08-31T17:34:56Z, after the issue had already closed. #3301 (Go) and the Python draft remain open, unmerged, presumably needing the same realignment.

Resolved in full, 2026-09-02. #3301 (Go) merged 2026-09-02T12:57:19Z by phdargen, confirmed against its real merged diff, not assumed from the "presumably" above: it carries the same realignment #3278/#3306 did, populating ExtensionResponses (not extensions) with a dedicated regression test, TestEncodePaymentResponseHeaderOmitsExtensionResponses, that fails outright if any extension data leaks into PAYMENT-RESPONSE. The Python draft, PhilBot402/x402#4, remains open in its author's own fork, never opened against the upstream repo itself. Three SDK-language fixes now trace to this one issue: TypeScript and Go both merged upstream, Python resolved separately by #3306, with a fourth, independent Python attempt left open in a fork that was never proposed upstream. No @x402/core release ships this shape yet (npm latest is still 2.24.0, from 2026-08-27), not a precondition either way: /settle now sends extensionResponses alongside the existing extensions field (neither replaces the other), the same way it already sent extensions ahead of any client reading it. Verified against the real merged httpFacilitatorClient.ts on main before writing this, not assumed: the official HTTPFacilitatorClient doesn't actually read extensionResponses from the body at all, settleResponseSchema doesn't declare it, so it gets populated purely from the EXTENSION-RESPONSES header this facilitator already sends correctly, no body change needed for that client specifically. The body field is for any other caller reading the JSON directly.

Protocol 28 ("Adapter") readiness, checked for real against testnet ahead of the 2026-09-16 mainnet vote, not just a version bump. Commit 32f5d56: @stellar/stellar-sdk upgraded 16.2.0 → 16.3.0, the LTS release backporting full Protocol 28 XDR support (CAP-85's new ContractExecutable variant, CAP-83) onto the stable v16 API, not 17.0.1 (npm latest), because @x402/stellar, this project's own dependency, still hard-pins ^16.0.1; a v17 bump would have split the install into two incompatible major versions of the same package. The same commit settled three real transactions on stellar:testnet under the new protocol, each Horizon-verified: exact (e102cf87...), upto's contract profile direct against the deployed contract (265d5c4e...), and upto's contract profile through this facilitator's own HTTP-route code (383b8319...). The run wasn't cosmetic: the same commit fixes a real bug it found, apps/facilitator/scripts/settle-demo.ts had never read MAX_TRANSACTION_FEE_STROOPS the way the deployed serve.ts does, so it failed on the real, current testnet fee (95,461 stroops that day, already above the 72,000 that first required the override in August). Also left a corroborating comment on OpenZeppelin/stellar-contracts#865, filed independently the same day by a separate project with a stronger repro (a real error[E0004] compiling against soroban-sdk 28.0.0-rc.1): the same ContractExecutable match gap, hit at a different soroban-sdk pin (26.1.1), a second, independent confirmation of the same root cause. Update, 2026-09-26 (checked against the GitHub API and crates.io that day): #865 was closed as completed by the maintainer through #866 (merged 2026-09-26), so it is fixed on main, with no release published: stellar-accounts on crates.io is still 0.7.2. soroban-sdk 28.0.0 itself was published as stable on 2026-09-18.

It is built on the official @x402/extensions/bazaar package, for the same reason the facilitator does not reimplement verify and settle. We kept packages/bazaar's own stricter routeTemplate check in place of the upstream equivalent; docs/INTEROP.md explains where and why. That work also surfaced a real bug in the upstream package itself, affecting mcp://tool/{toolName} URLs, the exact convention the Bazaar extension documents for MCP tools. We found it through the live integration test, not by reading the code, and filed it as x402-foundation/x402#3121. A fix is open against it as x402-foundation/x402#3138, built scheme-agnostic per a reviewer's suggested shape rather than an mcp://-specific patch. That same reviewer, whawk46, later found a real follow-on gap in the fix itself (the opaque-origin branch skipped the query/fragment stripping the function exists to do), we implemented the fix they suggested for it with a new regression test, and they reviewed that too, quoted verbatim: "LGTM as it stands — merge-ready from my side." Nine days later, still unmerged, whawk46 seconded their own review with a merge request, explicit about why the fix is a real defect rather than a cosmetic one, quoted verbatim: "a query string surviving into the canonical URL means the same resource indexes under as many identities as it has session parameters, which is the kind of thing that quietly inflates a catalog and is very hard to attribute afterward." The PR is open, mergeable, commented on three times by the person who reported the original bug, with a separate merge nudge from us the same week. Precision check, 2026-08-23: GitHub's own review API reports zero formal reviews on this PR (reviews: []); whawk46's "LGTM"/"nothing further" language is plain comment text, not a submitted GitHub review, and we have not confirmed whawk46 holds a maintainer or write-access role on this repo. Stated here as what it is: a positive, substantive comment from the person who reported the original bug, not a formal or authoritative approval. Still open, blocked on a maintainer actually merging it.

Reviewing the same @x402/extensions/bazaar package a second time turned up another real bug, this one in isValidRouteTemplate itself: its traversal and scheme-injection checks decode routeTemplate once, so a double percent-encoded payload survives the first decode still encoded and slips past both checks, verified directly against the function with two working repro payloads. Filed as x402-foundation/x402#3169. Status: closed 2026-09-09, fixed by another contributor adopting the same approach packages/bazaar's checkRouteTemplate already takes. Same pattern as #3121 and #3270: we reported it, a third party (ygd58) fixed it. ygd58's PR #3213 decodes to a fixed point with a bounded pass budget instead of one extra fixed pass, the same bounded-repeated decode Periplo's own checkRouteTemplate runs, and merged to x402 main on 2026-09-09. Before the merge we re-ran both original repro payloads directly against the actual diff, both correctly rejected, then went further than the original report asked for: triple-encoded payloads, and the decode-budget boundary checked from both sides (a payload needing exactly 4 passes still resolves and rejects; one needing 6 exceeds the 5-pass budget and rejects safely rather than hanging or passing through partially decoded). Recorded as a real review comment, not a thumbs-up. No npm release ships this fix yet (@x402/extensions is still at 2.25.0, tagged before the merge), so packages/bazaar's own check stays load-bearing until one does.

A separate one surfaced while working the OpenZeppelin smart-account issue below (#839): @stellar/stellar-sdk's AssembledTransaction.needsNonInvokerSigningBy() and signAuthEntries() only ever look at the top-level node of a SOROBAN_CREDENTIALS_ADDRESS_WITH_DELEGATES (CAP-71) auth entry, so a delegate signature that's still outstanding is never reported, verified with two real entries built via the SDK's own buildWithDelegatesEntry/authorizeEntry. CAP-71 isn't live on any network yet, so this has no impact today, but the bug is real in code already shipped. Filed as stellar/js-stellar-sdk#1655.

Update, 2026-09-26 (each item checked against the GitHub API and Horizon that day): our PR #1672 was closed without merging, in favor of the maintainer's own #1747, which Closes #1655 (approved 2026-09-24, still open at this update). #1683 was fixed on main by #1742 (merged 2026-09-24, Closes #1683), and #1681 by #1743 and #1744 (merged 2026-09-24), then closed as completed; #1700 was closed by a maintainer's documentation PR, #1745 (merged 2026-09-25). None of these fixes is in a published @stellar/stellar-sdk release yet (latest v17.1.0, 2026-09-14). A comment on #1747 (2026-09-26) names one case it does not cover, a signed C... account with an unsigned nested delegate, and corrects this entry's own first reproduction: it used G... top-level accounts, whose delegates, per #1747's docs, are not consulted in protocol 27 (CAP-72, which adds delegation for G... accounts, is still Draft), so only the C... variant applies. One more correction: the entries below say CAP-71 isn't live on any network yet, which was true when they were written. CAP-71's own header says protocol 27, and both horizon.stellar.org and horizon-testnet.stellar.org report protocol 28 today, so the "no impact today" severity notes no longer hold. The history below is kept as it happened.

Update, 2026-10-02 (checked against the GitHub API that day; this supersedes "none of these fixes is in a published release" above): the fixes are released. v17.2.0 (2026-09-28) contains #1742, #1743, #1744, #1745 and #1747 (each merge commit is an ancestor of the v17.2.0 tag, and none is in v17.1.0). #1747 merged on 2026-09-28 and closed #1655 as completed. The latest release is now v17.2.1 (2026-10-01), whose release notes list only asset-ordering and map-key-sorting fixes. The merged #1747 differs from the version described above: needsNonInvokerSigningBy() always walks delegate trees, and the opt-out is ignoreContractDelegates on sign() and signAndSend(). This repo pins @stellar/stellar-sdk 16.3.0 and has not been re-run against v17.2.0.

Status then (2026-09-01, see the update above): fixed, not just filed. stellar/js-stellar-sdk#1672, open and mergeable, 6663 tests passing, made needsNonInvokerSigningBy() and signAuthEntries() walk the full delegate tree instead of the top-level node only. On 2026-08-23 the maintainer, roebee, asked directly on #1655 whether this behavior change (a documented public API now reports every unsigned node, not just the top-level one) should ship as a v17.x bug fix or wait for v18, given CAP-71 isn't live on any network yet. We replied recommending v17.x. Rebased onto v17.0.1 on 2026-08-28 once upstream cut that release mid-PR-lifetime, settling the question by circumstance rather than a maintainer decision: the PR can now only ship as a later v17.x patch, not v18. Running the new tests surfaced a second, genuinely separate bug along the way, not the one we set out to fix: authorizeEntry()'s bare-signature fallback path infers publicKey from the entry's top-level address unconditionally, ignoring forAddress, so a signature correctly targeted at a delegate was verified against the wrong address and failed. Worked around narrowly, inside signAuthEntries()'s own callback, without touching authorizeEntry() itself, since that's out of scope for this PR, and never given its own issue at the time. Opened now, on its own, closing that gap: stellar/js-stellar-sdk#1683, with the exact code path quoted, applyExpirationAndSignature's own correct fallback rule cited as the pattern the verification step should mirror, and a proposed fix. On 2026-08-23 roebee posted three implementation questions to pin the fix down: how to derive the public key when the signer callback returns a bare Uint8Array instead of forAddress, what the resulting error text should say, and whether the verify step should follow applyExpirationAndSignature's own fallback rule. We replied the same day: throw rather than silently derive from forAddress, proposed error wording, and yes to matching the existing fallback rule, with this fix landing in the same PR as #1681's below since both converge on the same { signature, publicKey } return shape. Status then (see the 2026-09-26 update above): filed; the proposed fix (verify against forAddress on the naked-signature path in base/auth.ts, exactly the one line proposed in the issue) landed in code as part of #1672 on 2026-09-01, prompted by a second maintainer's review, Ryang-21, see below — not yet confirmed by roebee, and the issue itself stays open on GitHub until #1672 actually merges, not claimed closed early.

That same authorizeEntry() bare-signature fallback path turned up a second, separate way to trip it: attempting a genuine classic Stellar multisig payment (a second Ed25519 key registered on the buyer's account, weight 1, signing instead of the master key, not simulated, verified on a real testnet transaction that registers the signer) found AssembledTransaction.signAuthEntries() can't represent a non-master-key signer at all, for two separate reasons. First, signAuthEntries()'s own address default calls signerAddress() on signAuthEntry itself, a plain function per that option's own documented type (SignAuthEntryLike = SignAuthEntry | Signer | Keypair); signerAddress()'s guard requires an object, so it can never resolve for the simplest, most common, fully-documented usage, and silently falls back to an unrelated address instead. Second, even when a caller supplies address explicitly and sidesteps that (as @x402/stellar's own client does), the per-entry signing closure discards any signerAddress a custom signer returns before handing a bare signature to authorizeEntry(), landing on the exact fallback path above and verifying against the wrong key again, this time for a plain Address credential rather than a CAP-71 delegate. Filed as stellar/js-stellar-sdk#1681, with a proposed fix for both, checked against #1610 first to confirm it wasn't a duplicate. On 2026-08-23 roebee asked two questions to pin the fix: whether the missing-address default should throw or keep the current silent fallback to this.options.publicKey, and whether the signing closure should return { signature, publicKey } (and if so, whether that lands together with #1683 or as separate PRs). We replied the same day: throw rather than fail silently, return { signature, publicKey }, and land both fixes in one PR since they converge on the same return shape. Status then (see the 2026-09-26 update above): filed, our proposed direction posted in reply to the maintainer's questions, not yet confirmed by roebee, not fixed, open.

On 2026-08-24, GitHub Copilot's automated review on #1672 itself surfaced two more real, independently-verified problems, not just style nits. First, the regression-test comment for the #1655 case 1/2 tests claimed both were "built the same way (buildWithDelegatesEntry / authorizeEntry, not hand-constructed XDR)". Checked against the actual test code, that's false: both hand-construct SorobanAddressCredentialsWithDelegates XDR directly, with placeholder scvBytes/scvVoid signatures, same pattern as the file's own addrCreds/authEntry helpers. Fixed the comment to describe what the test actually does. Second, and more substantive: signAuthEntries()'s own default callback returned { signature, publicKey: target } unconditionally, where target is only who the SDK asked to sign, discarding a signerAddress the signing callback may report when the real signer differs, such as a delegate whose real key differs from the delegate node's own address. Reverting the fix reproduces a real signature doesn't match payload failure from authorizeEntry; a new regression test signs with a different keypair than the one requested and confirms the default path still verifies. Both fixed and pushed to the same branch: pnpm exec vitest run test/unit, 130 files, 6664 tests passing.

A second Copilot review, 2026-08-29, after the v17.0.1 rebase, found a real regression we introduced ourselves: resolving the CHANGELOG.md conflict during the rebase had deleted the entire v17.0.0 release section, jumping straight from v17.0.1 to v17.0.0-rc.2. Restored verbatim from upstream main, verified byte-for-byte identical to the real released section, fixed and pushed the same day. Three further comments from that review are still open, unresolved design questions on assembled_transaction.ts rather than regressions: whether needsNonInvokerSigningBy() should exclude a delegate an account's own policy may never require, whether its public documentation should describe contract-address delegates (not just accounts), and whether signAuthEntries() should preserve an entry's existing expiration once any node is signed rather than overwrite it with a fresh one on a later signer. Status then (see the 2026-09-26 update above): rebased, mergeable, three real review findings from Copilot pending a fix, not a version question anymore.

On 2026-09-01, a second real maintainer, Ryang-21, distinct from roebee's ongoing engagement above, left a formal review on #1672 itself: CHANGES_REQUESTED, five inline comments, each naming a genuine silent-signature-corruption or dead-end path, not a style nit. In order: reusing a fresh expiration default across sequential multi-party signers silently invalidates an earlier signer's signature (Error(Auth, InvalidAction) on the real host, no client-side warning first) — the same defect Copilot's own third open question above had already flagged, now confirmed and fixed by a second, independent reviewer; a missing !signer.signed guard let a repeat signAuthEntries() call for an already-signed address re-sign and re-bump the same shared expiration through a second door; a contract-address (C...) delegate target reached an unreachable signatureScVal branch, surfacing only an opaque strkey error; a pre-#1672 custom authorizeEntry with 4 declared parameters silently dropped the new forAddress (5th) argument, writing a delegate's signature to the entry's top level instead of the delegate node; and the #1683 fix belonged in base/auth.ts itself, not the narrower assembled_transaction.ts workaround this PR had shipped with. All five fixed in one commit, 0dd1c624, each with its own new regression test (the expiration-reuse test needed a rewrite mid-session from a passthrough mock, which never actually exercised the check, to real signing via contract.basicNodeSigner, caught before pushing). Replied inline to each of the five threads plus one summary comment, each referencing the real commit rather than asserting the fix happened. Merged upstream/main afterward (81466fd9, a merge commit, not a rebase, so Ryang-21's existing comment anchors didn't move) to pick up #1693/#1698, one CHANGELOG.md conflict resolved by hand. Re-verified in full post-merge: 132 test files, 6743 tests passing, both tsc -p invocations clean, eslint src/ clean, generated docs confirmed current by the repo's own pre-push hook. Signed and verified: gh api repos/Eras256/js-stellar-sdk/commits/81466fd9 --jq '.commit.verification.verified' returns true. CI (Tests, CodeQL, Docs build, Code Formatting, Guide snippets, e2e) shows action_required, confirmed via the Actions API rather than assumed from the check list alone: the standard GitHub gate for an external PR awaiting a maintainer's manual approval to run workflows, not a failure on this branch. Status: all five of Ryang-21's review points fixed with dedicated tests and evidence, merge conflict resolved and pushed, signed, nothing further actionable from this side until a maintainer approves CI and review resumes. Copilot's first two open design questions above (excluding a never-required delegate, documenting contract-address delegates) remain genuinely open, distinct from what Ryang-21's review covered.

Resuming the broader search this session had paused for the Ryang-21 review, the same defect class recurred independently, the same day, in a different official SDK: StellarCN/py-stellar-base's own authorize_entry() (stellar_sdk/auth.py) signs each CAP-71-01 delegate correctly in isolation, but sequential signing across multiple delegates silently overwrites the entry's one shared signature_expiration_ledger field, invalidating an earlier delegate's already-stored signature whenever two calls use different expiration values, with no error raised at either call. The library's own docstrings already state the requirement in prose, twice ("every signer of one entry must use the same valid_until_ledger_sequence, otherwise earlier signatures are invalidated"), but nothing in code enforces it, and AssembledTransaction.authorize()/sign_auth_entries() never reach this path at all: they only target the top-level address by design, so authorize_entry(..., for_address=...) is the only documented way to sign a delegates entry with this library, not a fallback. Reproduced for real against a0e9f8b7 (the commit last touching auth.py): two delegates signed with expirations 1000 and 2000, then the payload the network would actually verify the first delegate's stored signature against (rebuilt from the entry's current state, expiration 2000) compared byte-for-byte against the payload it was actually signed with (expiration 1000) — confirmed different. Checked for duplicates first (none found; the PR that added this support, #1189, has no discussion of this case in its own review). Filed as StellarCN/py-stellar-base#1215 with a proposed fix (raise a clear ValueError in authorize_entry() when an already-partially-signed entry's stored expiration disagrees with the one just passed, instead of silently overwriting it), not just the finding. Severity calibrated the same honest way as #1655's own entry above: CAP-71 wasn't live on any network yet when this was written (see the 2026-09-26 update under #1655 above), so this had no impact on a real transaction then, but the bug is real in code already shipped, in the only path this library offers for it. No PR opened yet, per this repo's own CONTRIBUTING.md, which asks contributors to check in before starting work on a significant change; the issue includes a full fix sketch so that step is fast once a maintainer responds.

Both #1672 and #3215 are the first pair of contributions from this project to go through the checklist in .claude/skills/claude-antigravity-setup/git.md in full: humanized, no filler, a visible AI co-authorship trailer on every commit, and root cause confirmed with real, run code before proposing the fix, not just reasoned about.

Investigating the discovery mechanism behind the stellar-build skill pack this project's own tooling uses (see docs/SKILLS.md) turned up a bug in a different, adjacent repository: stellar/stellar-dev-skill, the site behind the pack's public skill index. 27 of 28 community-skill entries in its llms.txt (an agent-fetchable index, per the llmstxt.org convention) linked to GitHub's rendered HTML page instead of the raw markdown, verified live against the deployed skills.stellar.org/llms.txt, not just the source. Root-caused to the repo's own contribution guide: its own example for adding a new entry used the wrong URL shape directly beneath the prose describing the correct one, which likely explains why 27 of 28 contributors made the same mistake independently. Fixed with a PR rather than just an issue: all 27 URLs, the contribution guide's example, and a new CI check preventing the mistake from recurring. Filed as stellar/stellar-dev-skill#103, merged 2026-08-28 by @kaankacar.

On 2026-08-24, Copilot's review on #103 flagged that the new CI gate's own regex, BLOB_PATTERN = /^https:\/\/github\.com\/[^/]+\/[^/]+\/blob\//, only matched the canonical https://github.com/... form, missing http://github.com/... and www.github.com/..., both of which serve the same HTML blob page the check exists to catch. Verified against the actual regex, confirmed real. Fixed by parsing with URL and comparing hostname (case-insensitive, www. stripped) and pathname instead of a fixed-scheme regex. Added scripts/check-ecosystem-links.test.mjs (Node's built-in test runner, no new dependency) covering the canonical form and the three variants that slipped through before, wired into both CI workflows as a new pnpm test:ecosystem-links step. node --test: 7 passed; the real gate still passes against the live 28-entry ECOSYSTEM_CARDS list. Both fixed and pushed to the same branch.

On 2026-08-27, Kaan Kaçar's own automated triage bot reviewed #103 directly and confirmed the original fix real (generate-llms-txt.mjs:156 writes copyValue verbatim into llms.txt, the deployed file held 28 blob links and 0 raw ones, all 27 rewritten URLs returned 200 text/plain), then raised three further findings, each verified independently before fixing rather than accepted on the bot's word alone. First, main had gained a new ecosystem card (PMLL) since the branch was cut, still pointing at a blob URL; it merged cleanly (no conflict) but left one blob copyValue in the tree, which would have failed check:ecosystem-links on the first deploy after merge. Fixed by rebasing onto origin/main and rewriting that entry, its raw URL confirmed 200 before writing it. Second, the wrong-URL-shape example from the original fix was only corrected in site/README.md; site/src/app/page.tsx's ADD_SKILL_SNIPPET (the copy actually rendered live in the site's "Add your skill" block) and site/CLAUDE.md's own contribution guide still carried it, both fixed to match. Third, rewriting every copyValue to raw.githubusercontent.com had silently changed each community card's "View source" icon to open plain text instead of GitHub's rendered page, since page.tsx passed sourceUrl={c.copyValue}, the same value for both. Decided on purpose rather than left as a side effect: a new ecosystemSourceUrl helper (site/src/lib/ecosystem-source-url.mjs) reconstructs the github.com/.../blob/... URL from the raw one instead of storing a second field that could drift, falling back to the original URL unchanged for a card not hosted on GitHub at all (stellarlight.xyz), verified against the real build output for both cases plus the newly-fixed PMLL entry. A smaller fix rode along: import.meta.url compared against a hand-built file:// string doesn't survive a checkout path needing URL-encoding, silently skipping the whole check; import.meta.filename compares raw paths directly instead. Left open for @kaankacar, not decided unilaterally: whether check:ecosystem-links should run in the PR lane at all, since preview-pr.yml skips fork PRs today. Fixed and pushed as 8eb4c4d: pnpm lint, lint:ts, and build clean, the real gate reporting 29 entries and no blob URLs, node --test 12/12 across both ecosystem-links test files.

On 2026-08-28, the same bot's third triage round on 8eb4c4d raised three more real, independently confirmed findings before this could go to @kaankacar for a human merge decision. First, check:ecosystem-links/test:ecosystem-links had never actually run in CI for this PR at all: site-ci-fork.yml, the only pre-merge lane a fork PR runs (preview-pr.yml skips forks, deploy-pages.yml only runs post-merge), landed on main after this branch was cut and only ran install/lint/lint:ts/build. Fixed by adding both steps to site-ci-fork.yml and correcting the workflow's own comment describing what it runs. Second, site/CLAUDE.md still said the site had "no test runner", now false since node:test was already in use with zero new dependencies; fixed the stale claim (cross-referencing the file's own "Don't add" policy rather than rewriting it) and added the two new scripts to both CLAUDE.md's and README.md's script lists, neither of which named them. Third, SkillCard.tsx's comment on showOpenLink = copyValue !== sourceUrl still described the pre-fix behavior (copyValue/sourceUrl always equal for ecosystem cards, chip never rendering); with sourceUrl now derived separately, all 28 GitHub-hosted cards' values differ, so the chip renders for them too, a second, direct link to the raw file alongside the header's link to the rendered page, confirmed on purpose in the real build output (PMLL's chip opens its raw SKILL.md, stellarlight.xyz's card still shows none) and the comment rewritten to describe the new behavior. Fixed and pushed as 40e6ce6, all four checks (lint, lint:ts, check:ecosystem-links, test:ecosystem-links at 12/12, build) clean. Kaan's bot then confirmed the fix live rather than on description alone: site-ci-fork.yml printed "29 entries checked, no blob-URL copyValue found" at 40e6ce6, all 29 copyValue URLs still resolved (28 raw at 200 text/plain, the one non-GitHub entry at 200 text/markdown), and the check now runs in all three CI lanes, site-ci-fork.yml and preview-pr.yml pre-merge, deploy-pages.yml's copy left as a post-merge backstop rather than the only enforcement point. This PR touches .github/workflows/, so the bot didn't merge it itself; @kaankacar did, the same day, at 254aff4f.

The upto spec thread itself went through the same evidence discipline as everything else here: an honest comparison against a competing design rather than defending our own, real fee numbers and independently-verified transaction XDR rather than trusting a PR description, and self-checks against external review that turned up four real gaps in our own code. All four now closed, each with its own commit and tests: GET /discovery/resources and GET /discovery/search exist, the catalog's dedupe key is extra.uptoProfile-aware, and /supported now reports upto for real via UptoStellarScheme, a real scheme implementation registered against x402Facilitator, with a real settled transaction through this facilitator's own verify()/ settle() recorded in conformance/RESULTS.md, not yet reflected on the live deployment (docs/DEFERRED.md). See "The ecosystem is converging on this spec" above for what two other teams in this same RFP round did with this thread, and docs/UPTO-CONVERGENCE.md for the full chronological writeup.

The facilitator reports the outcome through the EXTENSION-RESPONSES header: {"bazaar":{"status":"success"}}, or {"status":"rejected","rejectedReason":"routeTemplate failed validation"}. We verified this end to end against the real Supabase project: a catalog row appears for a valid HTTP or MCP listing, and a crafted hostile routeTemplate produces no row and a specific rejection reason. docs/SELLERS.md is the seller-facing how-to, including per-parameter descriptions, which search ranking now reads.

Real external QA (2026-08-19) found two dead rows already live in the catalog: an opaque-origin bug's null/... URL, and an unrelated unreachable localhost URL from local testing, both cataloged before a write-time check ever existed. Every search query returned one of the two regardless of relevance, making ranking quality unjudgeable from outside. Fixed with a write-time gate, checkCatalogUrl, enforced inside upsertCatalogResource itself rather than only at the one call site that produced the opaque-origin bug, so it covers both bug classes and any future one that writes a URL the same way. A real one-time backfill against the live Supabase project followed: two bad rows before, one correct row after, confirmed by re-querying the table, not from the migration's own reported success.

We then cataloged one real, externally reachable resource (https://periplo-testnet.fly.dev/demo/temperature-convert) for the first time: apps/facilitator/src/demo-resource.ts, a genuinely payment-gated temperature-conversion endpoint (self-facilitation, built on @x402/hono, @x402/core, and @x402/stellar, the same "do not reimplement the wire protocol" discipline as the rest of this project), deployed to the live facilitator. Real settlement: dde62ac5e67730a0751052a2dafc67dffc595df20bacbae9aaa1c758081deaea, Horizon-verified, and the resource is confirmed discoverable through GET /discovery/search?query=temperature+conversion against the live deployment, not just asserted. Two more real bugs turned up deploying it: @hono/node-server derives a request's scheme purely from socket.encrypted, with no X-Forwarded-Proto awareness, which is always false behind Fly's TLS-terminating proxy, fixed with an explicit resource URL on the route config rather than patching proxy internals; and @x402/stellar's inherited 50,000-stroop fee ceiling was too low for real testnet Soroban fees that day (about 72,000 stroops, confirmed against Horizon's own fee stats), fixed with a configurable ceiling on the deployed facilitator.