{
  "markdown": "# RFP Hub\n\n[![CI](https://github.com/The-RFP-Hub/the-rfp-hub/actions/workflows/ci.yml/badge.svg)](https://github.com/The-RFP-Hub/the-rfp-hub/actions/workflows/ci.yml)\n[![code: MIT](https://img.shields.io/badge/code-MIT-blue.svg)](./LICENSE)\n[![standard: CC0-1.0](https://img.shields.io/badge/standard-CC0--1.0-lightgrey.svg)](./packages/standard/LICENSE)\n\nAn open, neutral aggregation layer and **standard** for **Ethereum-ecosystem funding\nopportunities** — grants, hackathons, bounties, accelerators, VC funds, and RFPs. It indexes,\nverifies, and distributes opportunities through a standard format, a public API, open data\nexports, and agent-friendly tooling (M2 ships these as running, tested code) — and where an entry\ncarries an **application link**, it sends you to the\nopportunity's own submission channel to apply. (Carrying one is ingestion policy on the Hub's own\ndata, with named exceptions — four of the 142 seeded entries have no public application URL, each\ndocumented in [the API README](./packages/api/README.md); the schema itself leaves\n`applicationUrl` optional, so third-party documents may omit it.)\n\nThat link (`applicationUrl`) is the single link-back target in the standard, and it carries\nwhatever the submission channel actually is — an application portal, a form, or a forum thread\nwhere no portal exists. The Hub is where you find the opportunity, never where you apply.\n\npnpm monorepo. The hand-authored **JSON Schema is the single source of truth**; TypeScript types\nare generated from it, and every other format the standard does or doesn't ship is listed in\n[`ARTIFACTS.md`](./packages/standard/ARTIFACTS.md).\n\n## The Standard\n\nThe heart of the project is the **RFP Hub Standard** — a versioned, documented, validated\nJSON Schema (draft 2020-12) describing a funding opportunity. It's published as\n[`@the-rfp-hub/standard`](./packages/standard) (CC0-1.0) and ships generated TypeScript types.\n\n- Schema: [`packages/standard/schemas/v1.0.0/opportunity.schema.json`](./packages/standard/schemas/v1.0.0/opportunity.schema.json)\n- Field reference: [`FIELDS.md`](./packages/standard/schemas/v1.0.0/FIELDS.md)\n- Status of this version (maturity, known issues): [`STATUS.md`](./packages/standard/schemas/v1.0.0/STATUS.md)\n- Prior-art crosswalk (DAOIP-5 · schema.org/Grant): [`CROSSWALK.md`](./packages/standard/schemas/v1.0.0/CROSSWALK.md)\n- Validated against real-world funding data: [`BENCHMARK.md`](./packages/standard/schemas/v1.0.0/BENCHMARK.md)\n- What's normative vs. informative: [`NORMATIVE.md`](./packages/standard/NORMATIVE.md)\n\nValidate anything against it:\n\n```bash no-run\nnpx rfphub-validate opportunity.json\n```\n\n## Packages\n\n| Package | npm | License | Purpose |\n|---|---|---|---|\n| `packages/standard` | `@the-rfp-hub/standard` | CC0-1.0 | Canonical JSON Schema, generated TS types, registries, conformance suite, migration table. Zero runtime deps. **SSoT.** |\n| `packages/validate` | `rfphub-validate` | MIT | `npx rfphub-validate` CLI + typed validation library, with an advisory warning tier over the registries. |\n| `packages/api` | — | MIT | Public `/v1/` REST API (Fastify + Postgres), plus the authenticated write, review and administration surfaces. |\n| `packages/frontend` | — | MIT | RFP Hub frontend (Next.js) — the public directory and the publisher dashboard: submit, claim, review, keys, and per-entry analytics, one app and one deploy pipeline for both. See [`packages/frontend/README.md`](./packages/frontend/README.md). |\n| `packages/client` | `@the-rfp-hub/client` | MIT | Typed HTTP client *(planned)*. |\n| `packages/mcp` | `@the-rfp-hub/mcp` | MIT | Model Context Protocol server (stdio): search and fetch opportunities from any MCP client, plus an optional write behind an approval a person grants at their own terminal. See [`packages/mcp/README.md`](./packages/mcp/README.md) and [`adr/0012`](./adr/0012-mcp-server-per-user-credential-stdio-out-of-band-approval.md). |\n| [`skills/funding-search`](./skills/funding-search/SKILL.md) | — | MIT | Agent Skill for searching funding opportunities — prefers the MCP server when installed, otherwise a bundled zero-dependency Node script. See [`skills/README.md`](./skills/README.md) for install channels (multi-agent installer, Claude Code plugin marketplace, or manual copy). |\n\nEvery package takes its *contract* from `@the-rfp-hub/standard` alone, and never reaches into\nanother package's internals (dependency inversion at the package level). The only non-Standard\ncross-package dependency is `packages/api` → `rfphub-validate`, through that package's published\nAPI, so the Hub validates with the same reference implementation everyone else runs.\n\n**Two version axes.** A package's `version` is its npm distribution version and moves freely; the\n**spec version** (`1.0.0`, in `specVersion` and the schema `$id`) is the data contract and moves\nonly under [`PROCESS.md`](./packages/standard/PROCESS.md). They are different numbers on purpose.\n\n## Governance\n\nThe standard is governed by written process, not by whoever is around:\n\n- [`GOVERNANCE.md`](./GOVERNANCE.md) — editors, the decision rule, review windows, appeals,\n  non-discrimination and ranking (what decides indexing, what never does, and why there is no paid\n  placement), and the list of things this project deliberately does *not* have.\n- [`REVIEW-CRITERIA.md`](./REVIEW-CRITERIA.md) — what a reviewer checks on a single submitted\n  listing, what is explicitly not a criterion, what \"pending\" means, and who decides.\n- [`PUBLISHERS.md`](./PUBLISHERS.md) — how an organization becomes a verified publisher, claims an\n  entry, and how verification is revoked.\n- [`packages/standard/PROCESS.md`](./packages/standard/PROCESS.md) — feature stages, what\n  \"breaking\" means operationally, deprecation, how to register a vocabulary value, the\n  [RFC process](./packages/standard/PROCESS.md#rfc-process) routing table, the release checklist.\n- [`adr/`](./adr) — the decision records behind the shape of the data model.\n\n## Guides\n\n[`docs/`](./docs) holds the handoff guides — four documents, each written for one person doing one\njob, linking to the per-package detail rather than duplicating it:\n\n- [`docs/deployment.md`](./docs/deployment.md) — what runs where, what must exist in the cloud\n  account **before** the first deploy (there is no infrastructure-as-code), the required variables,\n  the first-deploy sequence, rollback, the manual npm release runbook, and the three ways to deploy\n  a copy of the frontend.\n- [`docs/api-integration.md`](./docs/api-integration.md) — a five-minute read-only quickstart, the\n  write flow from an email address to a publishing key, the scope table, and the nine contracts\n  that surprise integrators.\n- [`docs/publisher-onboarding.md`](./docs/publisher-onboarding.md) — for whoever operates the Hub:\n  running a publisher application end to end, refusing one, revoking verification, and deciding a\n  disputed claim.\n- [`docs/external-deploy-test.md`](./docs/external-deploy-test.md) — the two-hour protocol that\n  proves an outside developer can deploy a frontend against the public API from the docs alone.\n\nEvery shell block in those guides is marked `no-run`, `safe-read` or `staging-write`; the\nconvention is defined in [`docs/README.md`](./docs/README.md).\n\n## Deploy your own copy, or install the skill\n\n**Deploy your own copy of the frontend** with the one-click Deploy Button in\n[`packages/frontend/README.md`](./packages/frontend/README.md#deploying-your-own-copy). It lives in\nexactly one place on purpose — a Deploy Button URL carries the whole build configuration in its\nquery string, so a second copy of the button is a second configuration that drifts. The other two\npaths, and the read-only limitation every copy inherits, are in\n[`docs/deployment.md` §9](./docs/deployment.md#9-the-frontend-three-ways-to-deploy-a-copy).\n\n**Install the agent skill** through any of three channels, all of which install the same directory:\n\n```sh no-run\n# 1. multi-agent installer: detects the agents you have and copies the skill into each\nnpx skills add The-RFP-Hub/the-rfp-hub --skill funding-search\n\n# 2. Claude Code plugin marketplace\nclaude plugin marketplace add The-RFP-Hub/the-rfp-hub\nclaude plugin install rfp-hub@rfp-hub\n\n# 3. a plain copy into whichever agent's skill directory applies\ncp -R skills/funding-search ~/.claude/skills/\n```\n\nEvery agent's directory, with the citation for each, is in\n[`skills/README.md`](./skills/README.md).\n\n## Repo topology\n\nDeveloped as one pnpm workspace for fast iteration (the schema and its generated types move\ntogether in a single change), and published as independent npm packages. At handoff the\npackages can be split into per-component repos (`the-rfp-hub/standard`, `the-rfp-hub/validate`,\n…) via `git subtree split`. The per-package `LICENSE`, `README` and `package.json` provide the\nmetadata for a future split. Before splitting, replace `workspace:*` dependencies with registry\nranges and verify standalone install, build and test; `packages/api` is not published.\n\n## Develop\n\n```bash no-run\npnpm install\npnpm codegen        # regenerate TS types from the JSON Schema\npnpm codegen:check  # fail if generated types drift from the schema (CI gate)\npnpm build          # build all packages\npnpm test           # run the test suite (vitest)\npnpm typecheck\npnpm lint           # biome\n```\n\n**Already have a dev database from M2?** It needs one upgrade before the current migrations will\napply. `packages/api/docker-compose.yml` now pins `pgvector/pgvector:pg15` instead of\n`postgres:15-alpine`, because `CREATE EXTENSION vector` ships as a migration. Same major version, so\nthe data directory is compatible and the named volume is reused — but the C library underneath\nchanges with the image, and with it the collation provider. Run the script; it dumps first, refreshes\nthe collation version, reindexes, migrates, and compares row counts before and after:\n\n```bash no-run\npackages/api/scripts/upgrade-dev-postgres.sh\n```\n\nIt takes no arguments and **refuses** anything resembling `down -v`, because the one-word-shorter\nversion of this operation destroys the seeded dev corpus. Details, and the escape hatch if the\ncollation change causes trouble, are in\n[`packages/api/README.md`](./packages/api/README.md#upgrading-an-existing-dev-database-to-the-pgvector-image).\n\n## Verifying a deployment\n\nCompletion criteria are checkable rather than assertable, and there are two tools because there are\ntwo kinds of criterion.\n\n**`scripts/check-deployment.mjs` only reads.** Health and TLS, every operation in the *published*\nOpenAPI document executed against the *live* service (including the strict-`400` negative contract),\nevery served document validated against the Standard, and the CC0 export's freshness and\n`latest.json`/`latest.csv` pair invariant:\n\n```bash\npnpm check:deployment --milestone m2 --api https://api.example.org --export-url https://data.example.org\n```\n\nPass/fail per criterion on stdout, a JSON report alongside, non-zero exit on any failure. Nothing\nabout a particular host or dataset is baked in, and the tool holds no credential flag at all — which\nis what makes it safe to point at production, where its defaults already point. Run it by hand, or\nfrom any external runner, against whichever deployment you want an answer about.\n\nThe nightly publishing job runs exactly this, against the deployment and the export it has just\npushed, and fails if it does not pass — so the job going green means *published and independently\nverified*, not merely \"ran\". See [Open data](#open-data).\n\n**`scripts/accept-writes.mjs` writes**, which is the other half: the publisher lifecycle, the review\nqueue, the audit trail, duplicate detection, source verification, publisher analytics and the\nstaleness job:\n\n```bash\npnpm accept:writes --milestone m3 --api https://api-staging.example.org \\\n  --namespace my-org --session-token \"$SESSION\" --admin-token \"$ADMIN\"\n```\n\nBecause it writes, it refuses far more. The target must be loopback or an explicitly allowlisted\nstaging origin, over https, with the redirect chain re-checked — there is no flag that forces\nproduction. It refuses to start without a namespace, a publisher credential and a reviewer\ncredential, the last because its teardown rejects and unlists everything the run created and a run\nthat cannot clean up after itself has no business writing. Everything it creates is prefixed\n`compliance-`. It is deliberately **not** wired into CI — CI has no deployment to write to, and a\nsign-off tool needing a standing publisher credential in repository secrets would be a worse thing\nto have than a tool somebody runs.\n\nBoth tools, their criteria and their exit codes: [`scripts/compliance/README.md`](./scripts/compliance/README.md).\n\nThe same read-only tool covers governance, the reference frontend, the MCP server, the agent skill\nand the handoff docs:\n\n```bash no-run\npnpm check:deployment --milestone m4 --site https://ethrfps.app --api https://api.ethrfps.app --browser\n```\n\nThe one case that could look like a write — `submit_opportunity`'s fail-closed behavior — runs\nagainst a local recording server the checker starts itself, never against `--api`. Pass `--browser`\nfor the checks that need a rendered page (search/filter/pagination, `/publishers`, the three\nresponsive viewports); without it those requirements are reported unmet, which makes their criterion\nincomplete and the run exit non-zero. `--offline` applies to the docs criterion only, so the\ncombination that means anything is `--only docs --offline` — a docs lint, labeled as such and never\na deployment sign-off.\n\nThe write side has a second profile, staging only, which drives the real MCP `submit_opportunity`\ninterlock end to end — preview, an out-of-band `rfphub-mcp approve`, commit — and tears the fixture\ndown afterwards:\n\n```bash staging-write\npnpm accept:writes --milestone m4 --api https://api.staging.example.org \\\n  --session-token \"$REVIEWER_SESSION\" --api-key \"$RFPH_KEY\"\n```\n\nThe same three credential flags as the publisher profile, under the same target guard: a session\nwhose account may review (or an `--admin-token`), because the teardown rejects the entry, and the\nwrite-scoped `rfph_` key the MCP server submits with. No run without both.\n\n## Open data\n\nThe dataset is published to [`exports/`](./exports) on the default branch by a scheduled workflow\n([`.github/workflows/nightly-export.yml`](./.github/workflows/nightly-export.yml)), under\n**CC0-1.0**. No bucket and no credentials: the files are served directly, over TLS, from the\nrepository, and every snapshot is a commit, so what the dataset said on any past day is `git log`.\n\n```\nhttps://raw.githubusercontent.com/The-RFP-Hub/the-rfp-hub/main/exports/latest.json\nhttps://raw.githubusercontent.com/The-RFP-Hub/the-rfp-hub/main/exports/latest.csv\nhttps://raw.githubusercontent.com/The-RFP-Hub/the-rfp-hub/main/exports/latest.manifest.json\n```\n\n`latest.json` and `latest.csv` are two independently named mutable files, so a consumer fetching\nboth can, rarely, catch one of each run. **`latest.manifest.json` is the answer to that**: it is\nreplaced by a single atomic operation, and it names both archives by immutable, content-addressed\nfilenames with the full sha256 of each. Resolve it once, fetch what it names, hash the bytes,\ncompare — and the pair is *provably* one run's rather than assumed to be.\n\nThe publishing job sources its data from the live API rather than from a database, validates every\nrecord against the Standard before writing anything, and refuses to publish a dataset that is empty,\nshort, or inconsistent with what `/v1/stats` reports.\n\nIf you want the dataset **as of right now** rather than as of last night, the API serves the same\nthing live, in one call, from the same serializer — `GET /v1/export/opportunities.json` and\n`GET /v1/export/opportunities.csv`. The trade is deliberate: a live download is current but\nanonymous, while a nightly snapshot is up to a day old and *verifiable* — immutable, digest-named,\nand vouched for by the manifest. Build a pipeline on the snapshot; reach for the endpoint when you\nwant today's answer. See\n[`packages/api/README.md`](./packages/api/README.md#open-data-export) for the file layout, the\nmanifest contract and the guarantees each one carries.\n\n## Using the API\n\nRunnable client examples — curl, TypeScript (zero-dependency `fetch`), and Python\n(stdlib-only) — live in [`examples/`](./examples), one endpoint-by-endpoint tour each. All\nthree read the API's base URL from `RFPHUB_API_BASE` (default `http://localhost:3001`); see\n[`packages/api/README.md`](./packages/api/README.md) to run one locally.\n\nThe [TypeScript example](./examples/typescript) installs\n[`@the-rfp-hub/standard`](./packages/standard) from npm and types its responses with it, so it\ndoubles as a type-contract demo — CI clean-installs and typechecks it the way a consumer would.\nThat step covers the TypeScript client only: it makes no request, does not read the curl or Python\nexamples, and resolves the standard from the registry, so it catches a *published* release that\nbreaks a consumer, not a change to `packages/standard` in this repo.\n\nTwo syndication feeds — `/v1/feeds/opportunities.atom` (Atom 1.0) and\n`/v1/feeds/opportunities.rss` (RSS 2.0) — publish the most recent opportunities for any reader or\nbot that would rather subscribe than poll JSON; both are `ETag`-validated, so a poller that sends\n`If-None-Match` gets a `304`. See [`packages/api/README.md`](./packages/api/README.md#feeds-atom-10-and-rss-20).\n\nThe API's list query contract is strict — an undefined parameter or an out-of-enum value is a\n`400`, never a silently unfiltered `200` — so the examples show a typo failing loudly.\n\n## Publishing to the Hub\n\nReading is public and unauthenticated, and stays that way. **Writing** is authenticated, and the\ncredential you hold decides not only whether a submission is accepted but whether it goes live:\n\n```sh no-run\nAPI=https://api.ethrfps.app\n\n# Who am I, and what may I do?\ncurl -H \"Authorization: Bearer $TOKEN\" $API/v1/me\n\n# Mint a publishing key. The secret is in this response and nowhere else, ever.\ncurl -X POST -H \"Authorization: Bearer $TOKEN\" -H 'content-type: application/json' \\\n  -d '{\"name\":\"programme-sync\",\"scopes\":[\"read\",\"write\",\"publish\"]}' $API/v1/keys\n\n# Submit. Live on arrival only if the key carries `publish` AND the account is a verified member\n# of the namespace in the entry's id; otherwise it is stored and queued for review.\ncurl -X POST -H \"Authorization: Bearer $KEY\" -H 'content-type: application/json' \\\n  --data-binary @opportunity.json $API/v1/opportunities\n```\n\nTwo credential kinds share one header: a signed-in **session**, and a long-lived scoped **API key**\n(`rfph_…`). Which one you present decides real authority — keys are refused outright on the routes\nthat manage credentials, change account identity, review or administer, so a leaked key cannot mint\na stronger one. The tiers, the scopes, the per-route matrix and the reasoning are in\n[`packages/api/docs/auth.md`](./packages/api/docs/auth.md).\n\n**To publish under your own namespace without review**, apply as a verified publisher:\n[`PUBLISHERS.md`](./PUBLISHERS.md) is the whole process — what qualifies, what is checked, what\napproval grants, and how it is revoked.\n\nBeyond the public read surface, the API serves:\n\n| | |\n|---|---|\n| **Write** | `POST /v1/opportunities` · `PUT /v1/opportunities/:id` · `POST /v1/opportunities/:id/claim` |\n| **Provenance** | `GET /v1/opportunities/:id/audit` · `/duplicates` · `/verification` |\n| **Account** | `GET\\|PATCH /v1/me` · `/v1/me/opportunities[/:id]` · `/v1/me/duplicates` · `GET\\|POST /v1/keys` · `DELETE /v1/keys/:id` |\n| **Publishers** | `GET /v1/publishers` (public) · `PATCH /v1/organizations/:slug` |\n| **Insights** | `GET /v1/insights/opportunities/:id` · `GET /v1/insights/me/summary` |\n| **Link-outs** | `GET /v1/r/:id/apply` · `GET /v1/r/:id/source` — `302` to the opportunity's own channel |\n| **Review (T3)** | `/v1/review/opportunities` · `/claims` · `/duplicates` · `/organizations` · `/accounts` |\n| **Administration (T4)** | `/v1/admin/accounts/:id/role` · `/direct-create` · `/v1/admin/jobs/:job/run` |\n\nEvery mutation — by a person, a key, or a job — writes a row to an append-only trail enforced by a\ndatabase trigger, and the trail for any entry is publicly readable.\n\nThe nightly maintenance jobs that close past-due and long-abandoned listings, roll up analytics and\nbackfill source checks are documented, schedule and runbook, in\n[`packages/api/docs/jobs.md`](./packages/api/docs/jobs.md). They run as one task on the deployed\nimage — `node packages/api/dist/jobs.js all` runs the whole chain in order in one process — which\nis scheduled outside this repository and runs before the open-data export, which publishes on its\nown cron; nothing here schedules it, and an operator who needs a job run outside that starts the\nsame one-off task by hand.\n\n## Licensing\n\nCode is **MIT**; the standard and datasets are **CC0-1.0**. See [LICENSING.md](./LICENSING.md)\nfor the per-path breakdown.\n\n## Contributing\n\nSee [CONTRIBUTING.md](./CONTRIBUTING.md) and our [Code of Conduct](./CODE_OF_CONDUCT.md).\nSecurity issues: [SECURITY.md](./SECURITY.md).\n",
  "bytes": 21248,
  "sha": "88dbd3f5971416c2163951f7878742e82cc3b89bc6c04b1fca2418d6998ca693",
  "repo_slug": "the-rfp-hub/the-rfp-hub",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_the_rfp_hub_rfp_hub_c732de0f/readme"
}