feat(discover): pin this deployment's paid endpoints ahead of the sweep

[A1igator]

Scope

• src/lib/vip-listings.ts: static pin data plus the query filter. First-party entries are built from settings.baseUrl and fixed paths, so a self-hosted deployment pins its own endpoints; v1 pins exactly one, /api/phone-lookup (/api/answer stays out so a later CLI integration is not pre-shaped, and article reads stay search-driven). Matching is exact word overlap against keywords and description words, no stemming and no fuzzy matching; no query is browse-everything, a query with no usable token matches nothing.
• src/commands/discover.ts: renders the pins ahead of the flat list, labeled first-party or VIP (curated, quality not guaranteed), and adds an additive pinned array to the JSON envelope with the kind field; every existing key is unchanged. An endpoint the sweep also lists renders once, in the pinned block, with the registry's live price, using the pay lane's own resource-identity rule (sameResourceUrl, now exported from src/lib/bazaar.ts) so dedupe and pay-time verification cannot disagree about what the same endpoint is.
• Risk: none of this can move money. Pins are never probed and never written to bazaar-listings.json, so a stale or wrong pin can only recommend badly; a pin no registry lists still refuses as unlisted at pay time. src/commands/discover.test.ts pins that hard rule by byte-comparing the evidence store from a run where a pin matches the sweep against one where it does not.

Ecosystem pins ship empty, on purpose

The ecosystem kind, its label, its rendering, and its tests are all in place, but the shipped array is empty pending operator seeding, so adding entries later is a data-only change. An entry belongs there only once a reviewer has confirmed a configured registry currently lists the endpoint, re-verified each release; the same bar docs/ecosystem.md publishes.

Ecosystem and VIP listing docs

• docs/ecosystem.md (new, linked from the README's new ## Ecosystem section) tells third parties how to list themselves, strictly by opening a PR. Both tiers are entered and reviewed the same way, an open PR that is accepted or rejected; what separates them is where the entry lands. An Ecosystem row lists a project in that file (name, URL, one sentence on what it does and how it relates to Tenjin, contact). A VIP entry does that and additionally ships inside the CLI as a discover pin, which is why it carries the extra bar, and why its PR must include the exact payable endpoint URL, registry evidence a reviewer can reproduce (which registry lists it and the terms it advertises there, via tenjin discover "<keyword>" --json output or the query run), keywords, and the one-line description to print.
• The VIP bar is the plan's curation rule stated in public: currently listed in CDP Bazaar or UltraVioleta, exact scheme, USDC on Base, re-verified against the registries each release, entries removed when they stop checking out. The doc uses "curated" to mean exactly what the CLI's VIP (curated, quality not guaranteed) label means, we read the PR and checked its claims, and says plainly what a listing does not buy: no preferential pay path, no safety or quality claim, no permanence.

Verification: is PR-based listing the industry pattern?

Checked before writing, and the answer is a qualified yes with one honest correction.

BlockRun does not do this for anything commercial. blockrun.ai/services and blockrun.ai/partners both carry a "List Your API Service" CTA that links to a Telegram DM (https://t.me/bc1max). No form, no repo file, no registry. Only the Community Integrations row of BlockRunAI/awesome-blockrun's ECOSYSTEM.md is self-service ("Open an issue or submit a PR!"), and it offers an issue first. Their de facto tiers match ours in shape (curated commercial tier vs open community tier), but the curated bar is a private conversation, not a written rule.

The pattern does hold elsewhere in this space. coinbase/x402 took ecosystem entries as a PR adding app/ecosystem/partners-data/<slug>/metadata.json plus a logo, five categories, review in five business days. Swader/x402facilitators (rendered at facilitators.x402.watch) is a pure PR-based registry. Merit-Systems/x402scan takes facilitators as a PR to facilitators/config.ts (services go through a web form instead). Both awesome-lists, Merit-Systems/awesome-agentic-commerce and xpaysh/awesome-x402, are PR-only with written acceptance criteria, and outside x402 so is cncf/landscape (landscape.yml).

Two things worth knowing that argue against us. None of those PR-based lists has a curated tier at all; the projects that do run tiers gate them on a measured event rather than editorial taste, which is the model our VIP bar follows: x402-list.com grades Payment-Ready (a live 402 inside a 7-day window) vs Verified (a paid delivery-probe that settled on-chain), and Virtuals ACP gates Graduated on 10 successful sandbox transactions plus review. And the x402 project itself retired its in-repo ecosystem listing on moving to the Linux Foundation (x402-foundation/x402 has no partners-data; the README now points at external directories), the same path MCP took from modelcontextprotocol/servers to a hosted registry. In-repo PR listing reads as the right early pattern and the thing an ecosystem outgrows.

What we chose and why. A PR flow in this repo, with the VIP bar written as a reproducible registry check rather than taste, because it costs no server surface, keeps curation reviewable as code, and matches the sellers we are actually asking to list (people already comfortable opening a PR). The tiers differ by where an entry lands, not by how much we stand behind it: shipping inside the CLI is what earns the extra bar, since a pin that has fallen off every registry is a suggestion tenjin pay will refuse to act on. CDP Bazaar indexes automatically and ERC-8004 registers permissionlessly, so neither replaces a reviewed tier. If the list churns, the plan's own note applies: a server-sourced VIP page is the follow-up.

Not verified: x402.org/ecosystem 404s, and x402scan's /resources/register form fields are JS-rendered and unreadable.

Proposed prose (operator sign-off)

The file is operator-voiced. These are its load-bearing sentences; everything else is scaffolding around them.

Entry is strictly by pull request: open a PR against this repository. That is the only route in. There is no form and no application, and an issue asking to be added is not a listing.

There are two tiers. Both work the same way: you open a PR, we review it, and it is accepted or rejected. What separates them is where the entry ends up.

Ecosystem lists your project in this file, in the table at the bottom. We check that the entry is real and that the description matches what you actually ship.

VIP does that and one thing more: the entry ships inside the CLI... as a pin tenjin discover prints ahead of the registry sweep. That is why it carries an extra bar. A VIP entry goes in front of every agent that runs discover, so it has to still be payable when one acts on it.

The endpoint is currently listed in CDP's Bazaar or in UltraVioleta... This is not a formality. tenjin pay refuses any foreign endpoint no configured registry lists, so a pin no registry carries is a suggestion the CLI itself will not let an agent act on.

The CLI labels these pins VIP (curated, quality not guaranteed), and this file means the same thing by that word. Curated means we read the PR and checked the claims in it. It is not a judgment about your product, your uptime, or your business, and it is not a reason for an agent to skip its own checks.

VIP entries ship empty until an operator seeds them, and an Ecosystem row is not a queue for VIP. They are separate PRs and separate decisions.

Registry evidence: ... Paste the output of tenjin discover "<your keyword>" --json, or the registry query you ran, so a reviewer can reproduce it rather than take your word for it.

We may ask for changes to the wording, and we may decline a VIP pin while accepting the Ecosystem row. We remove entries that go stale, fail re-verification, or turn out to misdescribe what they sell.

No permanence. Listings are code in a repository, reviewed like code, and changed like code.

Both earlier open calls are settled by the operator: entry is strictly by PR with no issue path (where BlockRun and awesome-blockrun also accept an issue), and the file says nothing about fees at all.

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.

[A1igator]

Rebased onto the rebased #187 after #151 squash-merged (014932a): git rebase --onto A1igator/cli-builder-code-attribution <old #187 head> replayed only this layer's commit, no conflicts, 0d2a192 → 6573517, force-pushed with lease. Base stays #187's branch, the PR is MERGEABLE, and the diff is the same eight files as before. Gates re-run on the rebased tree: lint, typecheck, and format:check clean, pnpm run check 2265 passed / 10 skipped. Repo CI still does not fire here (ci.yml is pull_request: branches: [main] and this layer targets #187's branch); it will once #187 lands and GitHub retargets this PR.

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.

[A1igator]

Added the ecosystem listing docs (a9c3cc4): docs/ecosystem.md plus a ## Ecosystem section in the README pointing at it. Third parties list themselves by opening a PR, with the two tiers separated explicitly: Ecosystem is an open directory row in that file (name, URL, one sentence, contact) and carries no endorsement; VIP is the curated discover pins in src/lib/vip-listings.ts, reviewed as endorsement, and needs the exact payable endpoint plus reproducible registry evidence on top.

I verified the PR-based flow against the field first, and one thing in the PR body is worth flagging here because it corrects the premise: BlockRun does not use a PR flow for anything commercial. Both blockrun.ai/services and blockrun.ai/partners route "List Your API Service" to a Telegram DM; only the Community Integrations row of BlockRunAI/awesome-blockrun's ECOSYSTEM.md is self-service, and it offers an issue before a PR. The pattern does hold elsewhere in x402 (coinbase/x402's partners-data, Swader/x402facilitators, x402scan's facilitator config, both awesome-x402 lists) and outside it (cncf/landscape). Two counter-signals are in the body too: none of those PR-based lists runs a curated tier, and the x402 project retired its own in-repo ecosystem listing when it moved to the Linux Foundation. Full citations and what we chose and why are in the PR description.

The description also carries a Proposed prose section with the file's load-bearing sentences for sign-off, and names two calls to confirm or overrule: the flat "no fee", and PR-only where BlockRun also takes an issue.

Gates on this tree: lint, format:check, and pnpm run check clean (2265 passed / 10 skipped), including the README tests in src/skills-text.test.ts that existence-check every relative link in the README. skill-drift passes; repo CI still does not fire on this layer until #187 lands and GitHub retargets it.

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.

[A1igator]

Reframed the tiers per the correction (8078e6c). The endorsement contrast is gone: docs/ecosystem.md now opens with "There are two tiers. Both work the same way: you open a PR, we review it, and it is accepted or rejected. What separates them is where the entry ends up." An Ecosystem row lists a project in that file; a VIP entry does that and additionally ships inside the CLI as a discover pin, which is stated as the reason for the extra bar (present in CDP Bazaar or UltraVioleta with reproducible evidence, re-verified each release), since a pin that has fallen off every registry is a suggestion tenjin pay will refuse to act on.

The md now defines "curated" to mean exactly what the CLI's VIP (curated, quality not guaranteed) label means: we read the PR and checked its claims, not a judgment about your product or a reason for an agent to skip its own checks. I swept the rest of the layer for the same framing so nothing contradicts it, so the README section, the vip-listings.ts and discover.ts comments, the hard-rule test comment, the changeset, and the tenjin-pay skill all lost their endorsement/vouching wording too; the hard rule now reads as "a pin is this repo's own say-so, the evidence store is what a registry returned", which is the same invariant without the claim.

PR description updated: the Proposed-prose section carries the new sentences for sign-off, and the rationale paragraph no longer leans on the contrast. The two open calls are unchanged (the flat "no fee", and PR-only where BlockRun also accepts an issue).

Gates on this tree: format:check, lint, typecheck clean; pnpm run check 2265 passed / 10 skipped, README link tests included. skill-drift green.

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.

[A1igator]

Both open calls settled (926847e): entry is now stated as strictly by pull request, with an issue explicitly not counting as a listing, and every mention of fees is gone from the file rather than restated as "no fee". Proposed-prose section updated to match. Gates clean: format:check, lint, pnpm run check 2265 passed / 10 skipped, README link tests included.