Catalog

The canonical record of what Cosmic Bull has built and deployed.

Where to start if you want to use this code

catalog/api/ — the exported API of every deployed package, with signatures, doc comments and crossing-function flags, generated from vm/qdoc on live pearl-1.

It exists because gnoweb's $help view, which is otherwise an excellent live interface and links to a ready-made gnokey maketx call command, renders exported top-level functions only. For the seventeen realms that is the whole API and nothing is lost. For the four /p/ primitives it shows 11 of 67 exported symbols — every method and every type is invisible — and deployed bytes are immutable, so no README can be added to fix it in place. The measured figures and the reasoning are in DISCOVERY_APIDOCS.md.

/usr/bin/python3 tools/gen_api_docs.py           # regenerate from the chain
/usr/bin/python3 tools/gen_api_docs.py --check   # exit 0 matches, 1 DRIFT, 2 could not complete
sh tools/test_gen_api_docs.sh                    # the generator's own tests -- 36 cases

Last run: 2026-09-22, MATCHES — 22 pages, 372 exported symbols from 21 packages, and 36 passed, 0 failed.

The prose here is now checkable

Everything above is human-written and can drift from the chain. Since 2026-09-22 the same inventory also exists as a manifest, and every claim it makes is proved against live pearl-1 and against the committed source:

/usr/bin/python3 tools/verify_catalog.py     # exit 0 VERIFIED, 1 DIVERGENT, 2 could not complete
bash tools/test_verify_catalog.sh            # the verifier's own tests -- 89 cases

The check is two-sided: every manifest entry must exist on chain with matching bytes, and every package in the namespace must appear in the manifest. An undocumented deploy and a phantom record are both exit 1.

What it does and does not cover — in particular that the curated prose fields below are deliberately out of scope — is docs/CATALOG.md.

Last run: 2026-09-22, VERIFIED — 877 checks, 0 findings against pearl-1. That verdict covers the counting and completeness claims in this file; it does not cover the descriptive prose.

How to read an entry

Every application entry carries the provenance chain:

application repository
  → exact GitHub SHA
    → Pearl deployment transaction
      → deployed realm path and address
        → verification record

Every link in that chain is independently checkable. The SHA is on GitHub. The transaction is on pearl-1. The deployed bytes can be fetched with vm/qfile and hashed. The verification record is pearl/DEPLOYMENT.md.

Source-of-truth boundary

This catalog describes applications; it does not contain them. Each application's own repository is authoritative for its source code.

Application source is deliberately not copied here. A second copy that can drift from the first is worse than no copy: it looks authoritative and is not.

What this repository does hold, in pearl/r/<app>/, is the port and remediation working tree — the audit evidence for how the deployed bytes were produced. Where that working tree diverges from the live realm, the divergence is recorded in pearl/INFRASTRUCTURE.md and is deliberate.

Counting

4 /p/ primitives · 15 application realms · 5 pipeline applications · 5 application-factory applications.

The 15 application realms are vault, bounties, coindemo, grants, market, plus the five pipeline applications, plus the five factory applications bounty_panel, duebook_demo, permbook_demo, service_market and subscriptions.

Two further realms exist on-chain and are excluded from that count: cointest (h572543) and cointest2 (h572561) are throwaway validation helpers used to probe out-of-band coin sends and realm-issued denoms. They are not products and were never audited as such. They are listed here so the on-chain package count reconciles.

Chain-verified. Enumerating the agent namespace on pearl-1 at height 640217 (block_time 2026-09-23T03:16:51Z) returns exactly twenty-one packages: coinio, feeledger, duebook, permbook, and the seventeen realms above. The count reconciles with no residue, and nothing is deployed that this catalog does not record.

The previous enumeration, at height 628232 (block_time 2026-09-22T16:30:55Z), returned twenty. The one addition is subscriptions at height 639086 — application-factory build #5, recorded at §17. No other package changed, and no existing package was redeployed: all twenty prior [addpkg] heights were re-proved by the same verify_catalog.py run (877 checks, 0 findings) that verified the addition.

The enumeration before that, at height 613026 (block_time 2026-09-22T02:51:45Z), returned nineteen. The one addition is service_market at height 628080 — factory benchmark #4, recorded at §15. No other package changed, and no existing package was redeployed: all nineteen prior [addpkg] heights were re-read after the deploy and every one is unchanged.

Verification status of the addresses in this catalog

All eleven recorded realm addresses have been reproduced from the derivation bech32("g", sha256("pkgPath:" + pkgPath)[:20]) and matched against their recorded values. (Corrected 2026-09-22 from "twelve pre-factory realm addresses": re-deriving all 17 deployed packages and intersecting with every address in the records matches nine. Only realms whose address is actually written down somewhere can be checked this way, so nine is the coverage, not the portfolio size.) See docs/TOOLCHAIN.md for why that check matters.

The five factory-realm addresses split into two strengths, stated precisely.

Confirmed against the realm itself — three. bounty_panel's derived address was confirmed against the live realm's own Address() after deployment (recorded in pearl/DEPLOYMENT.md §12). service_market's was read off the chain first — vm/qeval on its Address() view, returning the value init captured from unsafe.CurrentRealm() — and the derivation was then run and reproduced it exactly (§15). Because that realm custodies escrow, the address was also checked against auth/accounts directly, which reported 0ugnot at the end of live verification; a wrong address would have shown a stranded balance. subscriptions' followed the same strong form as service_market: derivation validated against the recorded anchor first, then the live realm's own Address() evaled and matched (§17).

Derived only — two. duebook_demo's and permbook_demo's were produced by the same derivation and have never been confirmed against the realms themselves, because neither exposes an Address() view nor holds coins. The confidence in them is indirect: the derivation run that produced each also reproduced the known-good anchors exactly, and as of 2026-09-22 a single run reproduces the recorded values — including every chain-confirmed one — with no mismatch. That is strong evidence the derivation is correct, and it is still not the same thing as asking the realm.