Discovery record — the portfolio manifest and its verifier

Objective. Turn Cosmic Bull's growing software inventory into something that can be discovered, understood, reused, and eventually exposed through cosmicbull.net — and decide what, if anything, should be built, and what belongs on-chain versus in the repository.

Date. 2026-09-22. Chain. pearl-1, height 628232+.

This record follows docs/DISCOVERY_AND_REUSE.md. It is written before the implementation, and the decision it reaches is a refusal to build the obvious thing — so the reasoning matters more than usual, and a reviewer should be able to disagree with it on evidence.

1. The candidate shapes

Three shapes were considered from the start, and named explicitly so that rejecting one is a recorded decision rather than an omission:

2. Sources searched

Coverage — stated honestly

The on-chain sweep enumerated all 647 paths but read 12 packages in depth. The selection rule was: the four mandated targets, then a ~30-term keyword grep over names, then deliberate sampling of unhinted names to test the grep's blind spot (r/moul/present/v2, p/moul/nestedpkg/v1, r/moul/x/daily/linktree/v1, r/g16m0r…/bountyboard — all negative).

That blind-spot test is required here because of a recorded prior miss: our own permbook discovery found that p/samcrew/basedao is a live role-and-member store matching none of access|perm|rbac|role|auth|acl|grant. Four negative samples is mild evidence the grep caught the real candidates. It is not a sample that licenses an ecosystem-wide claim. The 45-package nftmarket cluster, the ~85-package r/moul set and most of r/gnoswap were sampled, not enumerated. A basedao-class miss remains possible in the unread remainder.

Accordingly: no relevant existing implementation was found in the searched sources. Not "none exists".

3. Cosmic Bull's own inventory — the first reuse question

Three of our own live realms are registries. Each was evaluated as the home for this capability before anything new was considered.

The finding that governs this whole record: a new "Cosmic Bull package registry" realm would be an EXACT DUPLICATE of service_registry, which is live, audited (1 RED + 7 YELLOW, all resolved), and currently holds 1 of 1000 entries against a 1 of 20 per-owner quota.

This is the same call made before, and it is made the same way: a reusable permission capability was refused as an exact duplicate of the deployed permbook. Consistency here is the point.

4. On-chain findings

4.1 The decisive finding — the chain is already the registry

The chain's own query surface was read from the pinned toolchain (gno.land/pkg/sdk/vm/handler.go) and then executed against pearl-1. It already serves most of what an index would store:

gnomod.toml cannot carry descriptive metadata: the schema (gnovm/pkg/gnomod/file.go:11-45) is Module, Gno, Ignore, Draft, Private, Replace[], AddPkg — there is no description, author, license, tags or repository field, and AddPkg is chain-injected ("filled by the vmkeeper… not intended to be used offchain").

What the chain does NOT answer, and therefore what is genuinely missing:

• which packages form one portfolio (curation and grouping)
• the link from deployed bytes → git commit → audit record
• verification status — byte match, closure equivalence, audit verdict
• reverse dependencies — who imports X (derivable only by fetching all 647)
• a human description and reuse contract

5. Why an on-chain catalog realm is REFUSED

Shape (c) is the obvious thing to build and it is the wrong thing to build. Four independent reasons, any one of which would be sufficient:

1. It duplicates our own deployed work. service_registry already stores pkgPath + description + serviceType + freeform metadata with enumeration. §7 of CLAUDE.md classifies that as EXACT DUPLICATE.
2. It would re-store, in weaker form, facts the chain already attests. vm/qpkgmeta_json returns creator and height written by the chain at deploy. A realm holding a second copy holds a forgeable copy: the publisher types it in. Replacing a chain-attested fact with a self-attested one is a downgrade presented as a feature.
3. It cannot be made self-proving. grc20reg is safe because the key derives from cur.Previous().PkgPath() — a realm cannot register under another realm's path. No equivalent proof exists for a catalog entry describing a frozen /p/ package that will never call anything. Every field an index cares about — description, audit status, commit SHA — is inherently an attestation. Our own service_registry says so on Resolve: "A resolution is an ATTESTATION, NOT A PROOF." A new realm inherits that and adds nothing.
4. The ecosystem's prevailing principle says not to. gnopm's design note states it directly: "No centralized registry exists. Instead, chains serve as the registry." vm/qpaths is that registry.

Cost is a fifth reason and deliberately the weakest: ~5M ugnot to publish claims that are already free to query.

6. Off-chain findings

No EXACT DUPLICATE was found in the searched sources for a verifier that proves inventory claims against chain bytes.

7. The decision

Build (a) + (b) as repository infrastructure. Deploy nothing new. Reuse service_registry for on-chain discoverability.

What makes (b) worth building

Today, catalog/README.md claims "nothing is deployed that this catalog does not record." That claim is true. It was established by hand, in a conversation, and the last repo-wide audit found "stale counts across 13 docs" — prose drift is the failure mode, and it scales with the inventory.

verify_catalog.py turns that sentence into a re-runnable proof, two-sided: every manifest entry must exist on chain with matching bytes, and every on-chain package in the namespace must appear in the manifest. An undocumented deploy and a phantom record both become exit 1.

The on-chain step, and its honest limit

Registering the four /p/ primitives in service_registry is reuse, not construction — no bytes are deployed, and the realm's [addpkg] height is unchanged, which is the proof of that. It addresses a recorded gap: both permbook and duebook carry "known limitation — one consumer; its reusability is a design argument, not a demonstrated fact."

It does not make those registrations proofs. service_registry's INTEGRATOR CONTRACT applies unchanged and in full: attestation-not-proof, name-is-not-authorization, target-can-change.

8. Limits of this record

• 12 of 647 pearl-1 packages were read in depth. §2 states the selection rule and the residual risk. This record supports "not found in the searched sources" and nothing stronger.
• Unverified, and flagged rather than assumed: whether a pearl-1 tx-indexer endpoint is publicly available; GnoScan API stability; the status of gnolang/gno issue #522; whether a package-metadata GNIP/ADR exists in a branch newer than the pinned toolchain.
• r/leon/hor was never read — it is not deployed on pearl-1, so the "Hall of Realms" pattern is classified from its description in r/docs/registry's render text, not from its source.
• The refusal in §5 is a judgment call. The alternative — deploying a catalog realm — is written down in §1 and §5 precisely so a reviewer can disagree with the reasoning rather than guess at it.