MoonCatDAO technical ecosystem audit

Audit date: 2026-09-01
Scope: the 11 repositories visible in the MoonCatDAO organization inventory. This is an architecture and operations map, not a smart-contract security audit or a live deployment/chain verification.

Executive map

MoonCatDAO is a small, mostly static JavaScript ecosystem with three distinct centres of gravity:

1. Canonical generated data: name-index produces finalized and provisional MoonCat-name artifacts from Ethereum events. mooncat-holder-activity produces a separate, pinned holder-dormancy snapshot.
2. Curated technical publication: mooncat-kb holds source-aware, versioned technical data and documentation; mooncat-kb-library builds a static, human-facing archive from it.
3. Community/public surfaces: hof-website is the richest operational website, with both a static public viewer and optional Cloudflare-authenticated administration. mooncatdao-website is a simple DAO site that receives a deliberately limited HOF mirror. The remaining sites are static or content-oriented.

The strongest confirmed inter-repository dependency chain is:

flowchart LR
  ETH["Ethereum mainnet<br/>MoonCat contracts"] --> NI["name-index<br/>CatNamed scanner"]
  ALC["Alchemy custom webhook"] --> NIW["Cloudflare Worker<br/>in name-index"]
  NIW --> NIA["GitHub Actions<br/>provisional publication"]
  NI --> NID[("Finalized + live<br/>name JSON")]
  NID --> CAT["CatMoon / other consumers<br/>(documented)"]

  KB["mooncat-kb<br/>curated static evidence"] -->|repository_dispatch: kb-updated| KBL["mooncat-kb-library"]
  KBL -->|Vite build| PAGES["GitHub Pages<br/>mooncat-kb-library"]

  HOF["hof-website<br/>public files"] -->|whitelisted copy workflow| DAO["mooncatdao-website /hof/"]
  HOF --> HOF_PAGES["GitHub Pages<br/>mooncatdao.org/hof/"]
  HOF --> HOF_CF["Cloudflare assets + Functions<br/>optional admin surface"]

The repository set is not a monorepo and has no observed internal npm package dependency. Coupling occurs through checked-in JSON/static assets, GitHub Actions repository dispatches or direct cross-repository copies, contract/API conventions, and documentation.

Method and evidence rules

The organization inventory was read through authenticated GitHub API access on 2026-09-01 and cross-checked against local checkouts. Source/configuration claims below are marked as follows:

• Source/config confirmed — directly observed in a manifest, workflow, configuration, or source file.
• Remote metadata confirmed — GitHub repository metadata or latest commit information.
• Documented — stated in a repository README or checked-in operating document, but not exercised in this audit.
• Inferred — a restrained conclusion from source structure; it is labelled where used.
• Unknown — not established by the available source; no substitution has been made.

No repository was modified. No secrets, RPC requests, webhook deliveries, Cloudflare deployment credentials, GitHub Actions executions, marketplace calls, or browser/manual tests were performed. Environment-variable names are recorded where useful; values are intentionally omitted.

Organization inventory

The status labels are activity/architecture assessments, not an assertion that any service is currently online. “Active” is reserved for the only repository with a same-day remote publishing commit.

Architecture and data flows

1. Naming-index publication path

sequenceDiagram
  participant Chain as Ethereum mainnet
  participant Alchemy as Alchemy Custom Webhook
  participant Worker as name-index Cloudflare Worker
  participant Actions as name-index GitHub Actions
  participant Repo as name-index main branch
  participant Consumer as Static-data consumer

  Chain->>Alchemy: MoonCatRescue CatNamed log
  Alchemy->>Worker: signed GraphQL webhook
  Worker->>Worker: HMAC + contract/topic/schema validation
  Worker->>Actions: repository_dispatch(alchemy-naming-event, normalized provisional event)
  Actions->>Repo: pending-events + *-live.json + recent feed
  Actions->>Chain: delayed finalized overlap scan through configured RPC
  Actions->>Repo: events.jsonl + finalized/live derived artifacts
  Repo-->>Consumer: raw GitHub/static JSON consumption

Confirmed source/config details. name-index/src/constants.js pins Ethereum chain ID 1, original MoonCatRescue at 0x60cd862c9C687A9dE49aecdC3A99b74A4fc54aB6, a naming start block of 4,140,409, and the CatNamed(bytes5,bytes32) event. Its Worker accepts a bounded signed Alchemy request, validates the exact contract and event topic, normalizes exactly one event, and POSTs a GitHub repository_dispatch; it does not forward the raw body.

The worker configuration names ALCHEMY_SIGNING_KEY, GITHUB_TOKEN, GITHUB_OWNER, GITHUB_REPOSITORY, GITHUB_EVENT_TYPE, and optional GITHUB_API_BASE. The scheduled/finalization scan uses the Actions secret MOONCAT_RPC_URL (the local CLI accepts MOONCAT_RPC_URL or ETH_RPC_URL). The published README documents a six-hour reconciliation fallback and a roughly 15-minute confirmation delay after webhook dispatch. These integrations were not exercised.

The canonical finalized history is data/events.jsonl. Finalized current-name outputs include data/current-names.json, data/names-by-cat-id.json, data/names-by-rescue-order.json, data/names-simple.json, and data/names-timestamp.json; pending-events.json and the matching *-live.json set are explicitly provisional. This is an important provenance boundary for downstream consumers.

2. KB-to-library static publication

flowchart LR
  KBFILES[mooncat-kb\nMarkdown, JSON, static shards] -->|checkout at build time| GEN[mooncat-kb-library\ngenerate-kb.mjs]
  GEN --> PUB[public/kb/\ncopy + manifest + search index + profile lookup]
  PUB --> VITE[Vite + TypeScript build]
  VITE --> GHP[GitHub Pages]
  KB_PUSH[mooncat-kb push to main] -->|POST repository_dispatch\nkb-updated| LIB_WF[mooncat-kb-library deploy-pages.yml]
  LIB_WF --> GEN

mooncat-kb is deliberately an evidence-bearing source repository, not an application server. It supplies 25,440-row sharded static population data, 25,440 parser-derived render records, exact locally extracted ABI/event artifacts, curated source identities, and explicit limits on what the data does not establish. Its validation tooling is Python/Node based and designed for zero-network structural/provenance checking; it is not a live on-chain oracle.

mooncat-kb-library is a small read-only TypeScript/Vite application. Its generation script reads a sibling KB checkout by default (MCKB_PATH=../mckb), copies publishable materials into gitignored public/kb/, and derives manifest.json, search-index.json, and a profile lookup index. The Vite base is /mooncat-kb-library/; the app uses DOMPurify and markdown-it for local archive rendering.

The dependency is direct and build-time: mooncat-kb/.github/workflows/notify-library.yml sends the kb-updated repository dispatch to mooncat-kb-library. The receiver’s workflow checks out both repositories, sets MCKB_PATH=../mckb, runs npm ci and npm run build, then deploys library/dist using GitHub Pages actions. This gives a clear source-of-truth rule: the KB remains canonical; the library is a generated presentation copy.

3. Hall of Fame distribution path

flowchart LR
  ETH[Ethereum RPC + ENS + delegate.xyz] --> BUILD[hof-website\ndayoneclub.mjs]
  API[MoonCat Community API] --> NAME_SYNC[weekly name sync]
  BUILD --> MEMBERS[public/members.json]
  NAME_SYNC --> OVERRIDES[public/overrides.json]
  APIIMG[MoonCat Community image API] --> CACHE[image cache workflow]
  CACHE --> ASSETS[public/assets/mooncats]
  MEMBERS --> PAGES[GitHub Pages public site]
  OVERRIDES --> PAGES
  ASSETS --> PAGES
  PAGES_SRC[whitelisted public files] --> MIRROR[mooncatdao-website/hof]
  MIRROR --> DAO_PAGES[DAO site Pages surface]

The HOF workflow is a deliberately asymmetric distribution relationship. hof-website is the source; mooncatdao-website is only a static /hof/ mirror. The workflow copies a whitelist: public HTML/CSS/JS, members.json, overrides.json, public assets, and local vendor files. It specifically excludes admin UI, Cloudflare Functions, authentication/API code, and editing code. The target commit is pushed directly to mooncatdao-website/main with DAO_WEBSITE_SYNC_TOKEN.

hof-website additionally deploys public/ to GitHub Pages on public-path changes. Its optional Wrangler deployment is a separate asset + Functions setup, so GitHub Pages alone does not provide the authenticated administrator APIs.

Cross-repository relationship register

No evidence was found of a package import, git submodule, shared database, shared Cloudflare KV/D1/R2 binding, or shared internal npm package across the organization repositories.

Deployments and automation

Automation observed

• name-index: manual, repository-dispatch, and six-hour scheduled event reconciliation. It uses separate concurrency lanes for provisional writes and delayed reconciliation, caches scanner checkpoints, validates generated outputs, renders a timeline through Playwright, and commits an explicit generated-artifact allowlist.
• mooncat-kb: a narrow push-to-dispatch workflow with empty default permissions and MCKB_LIBRARY_DISPATCH_TOKEN for the target repository only.
• mooncat-kb-library: push/manual/KB-dispatch workflow with Pages permissions and non-cancelling pages concurrency.
• hof-website: update-members.yml runs every 12 hours and commits public/members.json; sync-mooncat-names.yml runs Mondays at 09:17 UTC and opens a pull request for reviewed name changes; image caching commits cached assets; public HOF mirroring runs on a limited input-path allowlist.

The Actions use major-version tags (for example, actions/checkout@v4/@v6) rather than commit-SHA pinning. This is a factual supply-chain observation, not a finding that compromise occurred.

Smart-contract and chain relationships

All observed on-chain reads target Ethereum mainnet (chain ID 1). The main contract and identifier distinction matters: a MoonCat bytes5 Cat ID, rescue order, ERC-721 token ID, wrapper token ID, and accessory ID are not interchangeable.

mooncat-holder-activity has the most explicit ownership-resolution logic: it scans a finalized reference block, reads Original/Acclimated/JumpPort surfaces, resolves WMCR mapping-backed token ownership, rejects unresolved wrapper/intermediate owners, and writes a schema-validated snapshot. It requires MOONCAT_RPC_URL or ETH_RPC_URL, uses viem, and has bounded ownership/activity concurrency options. Its checked-in data must be treated as a historical snapshot, not present ownership evidence.

Per-repository technical map

name-index

Purpose and status. The canonical maintained MoonCat naming-event index; source/config confirmed active. GitHub metadata says JavaScript and CC0-1.0. Remote main was 42881292 on 2026-09-01, matching the local checkout.

Implementation. Node.js 22+, ESM, viem ^2.33.2, Node’s built-in test runner, and Playwright for deterministic timeline-image rendering. Key modules include src/cat-named-logs.js, src/persistent-scanner.js, src/event-store.js, src/current-names.js, provisional/live artifact modules, timestamp/namer enrichment, and timeline/recent-feed generation. The Worker entry point is worker/src/index.js; wrangler.toml specifies the mooncat-name-index-wake Worker.

Entry points and generated data. npm scripts expose scanning, backfill, provisional ingestion, reconciliation, timestamp/namer enrichment, current-name generation, timeline generation, and checks. data/events.jsonl is canonical finalized history. JSON derivations are intentionally split into finalized versus provisional/live output families. RECENT-NAMINGS.md, a monthly count JSON, and a generated PNG timeline are secondary presentation artifacts.

External services. Ethereum JSON-RPC, Alchemy Custom Webhook, Cloudflare Worker runtime, GitHub repository-dispatch API, and GitHub Actions cache. Authentication is via the environment names listed above. The Worker fails a missing configuration with 503 and rejects invalid signatures/payloads rather than silently accepting broad webhook content; the final scan is the canonicality boundary.

Key relationships. It is the most important live-ish data producer in the organization. The repository README explicitly positions names-simple.json for websites, bots, and CatMoon. A consumer should choose finalized JSON for reproducibility and only choose the live family when it accepts reorg/reconciliation semantics.

mooncat-kb

Purpose and status. Public CC0 technical knowledge base, maintained but quiet. Its remote latest commit is 1dc3e2b (2026-08-25); the local mirror was one commit behind, so current workflow claims are taken from remote metadata/current source inspection.

Implementation. It is primarily Markdown, JSON, Python and small Node utilities rather than a web runtime. Main entry points are README.md, docs/mooncat-kb-guide.md, data/agent-index.json, data/task-recipes.json, scripts/validate-kb.py, scripts/audit-kb.py, manifest generators, and focused validators. Important data domains include static MoonCat population shards, deterministic render shards, contract/ABI/event registries, identifier conversion cases, source inventories, and generated manifest/provenance records.

Data and evidence model. The KB explicitly separates curated/static/reproducible records from live claims. It contains a complete 25,440-row snapshot and 25,440 parser-derived render records, but its own docs state that this does not establish current chain/API/marketplace/ownership/accessory state. A reviewed on-chain materialization snapshot is pinned to mainnet block 25798234, again as historical evidence rather than current state. data/name-index-integration.json documents consumption of the separately maintained index without vendoring it or asserting it as a live chain source.

Relationship/infrastructure. On every main push, .github/workflows/notify-library.yml POSTs the kb-updated event to mooncat-kb-library using MCKB_LIBRARY_DISPATCH_TOKEN. It has no observed deploy workflow for the KB itself. References to external upstream source snapshots and Etherscan/API material are evidence/provenance, not proof that the KB calls those services at runtime.

mooncat-kb-library

Purpose and status. Public CC0 human-readable LCARS-style archive for the KB; maintained but quiet. Remote/local main is 30510cac (2026-08-25).

Implementation. TypeScript 5.8, Vite 6.3, DOMPurify 3.2, markdown-it 14.1, with src/main.ts, src/mooncat-render.ts, src/style.css, and scripts/generate-kb.mjs as primary surfaces. It builds locally with npm run build; Vite’s deployment base is /mooncat-kb-library/.

Data contract. The generator reads a sibling KB checkout (MCKB_PATH, default ../mckb), copies only publication material, then generates local archive/search/profile indexes. Its profile feature reads static shard data and intentionally does not claim live ownership, market, accessory, provisional-name, or API state.

Deployment. deploy-pages.yml responds to main pushes, manual runs, and kb-updated. It checks out both repos, builds from the checked-out KB, then deploys dist through GitHub Pages. GitHub metadata confirms its Pages URL.

mooncat-holder-activity

Purpose and status. Public reproducible holder dormancy, tenure, and long-dormant-wallet snapshot. It is a point-in-time data product, not a continuously deployed service. The authoritative local checkout is mooncat-holder-activity-public, matching remote 0737f8b (2026-08-20). The remote declares an “Other” license (NOASSERTION), so no specific license should be inferred.

Implementation. Node.js 22 ESM and viem ^2.33.2, with built-in tests. Main scripts build classifications, ownership snapshots, activity/tenure scans, a full pipeline, and a Markdown/JSON summary. Main modules are src/rpc.js, src/ownership.js, src/activity.js, src/dormancy.js, and src/constants.js.

Data. Checked-in artifacts include data/mooncat-classifications.json, data/ownership-snapshot.json, data/holders.json, data/holding-tenure.json, and data/summary.json, plus dormancy-findings.md. The source validates all 25,440 rescue orders, represents collection provenance, and fails closed if wrapper ownership cannot be resolved beneficially.

External services. A caller must supply HTTPS Ethereum mainnet RPC using MOONCAT_RPC_URL or ETH_RPC_URL; source rejects embedded URL credentials and non-mainnet chain IDs. No RPC provider brand is hard-coded. Caching/resume is local artifact/state driven; it is not a public API.

hof-website

Purpose and status. Public AGPL-3.0 Hall of Fame site plus optional administrator system. GitHub metadata exposes homepage https://mooncatdao.org/hof/; local source shows an older commit than remote, so content-currentness is unverified while the architecture is strongly evidenced.

Implementation. Static browser HTML/JS/CSS, Node 20 scripts, viem ^2.38.5, Wrangler 4.95, Playwright test tooling, and Node built-in tests. Key runtime files are public/index.html, public/scripts/site.js, public/scripts/admin-core.js, local libmooncat-limited.js, public/members.json, public/overrides.json, and cached image manifest/assets. Key build scripts are scripts/dayoneclub.mjs, scripts/cache-mooncat-images.mjs, and scripts/sync-mooncat-names.mjs.

On-chain/API integration. dayoneclub.mjs uses a viem fallback transport with public endpoints ethereum-rpc.publicnode.com, cloudflare-eth.com, and eth.merkle.io; it reads original MoonCat ownership and trait/name data, queries ENS records, and consults the delegate.xyz registry for richer holder metadata. The name synchronizer fetches https://api.mooncatrescue.com/mooncat/traits/<rescueIndex> with retries; the image cache fetches the MoonCat Community image endpoint. These are build/admin data paths, not confirmed runtime service dependencies for a static viewer once artifacts are deployed.

Admin and Cloudflare boundary. wrangler.jsonc configures a public-assets deployment with Node compatibility and observability. Functions implement GitHub OAuth organization membership, HMAC-signed session cookies, and a GitHub Contents API update to public/overrides.json. Relevant environment names are GITHUB_CONTENT_TOKEN, GITHUB_REPO, optional GITHUB_OVERRIDES_PATH, optional GITHUB_BRANCH, GITHUB_CLIENT_ID, GITHUB_CLIENT_SECRET, GITHUB_ORG, SESSION_SECRET, and optional ADMIN_SESSION_TTL_SECONDS. The checked-in private security report describes this model and notes that GitHub Pages cannot run these Functions; actual Cloudflare production routing was not verified.

Automation and relationships. Four workflows build membership data, cache images, sync names through a review PR, deploy public files to Pages, and mirror static HOF files to the DAO site. The mirror is the sole confirmed direct source-code/data distribution into another organization repo.

mooncatdao-website

Purpose and status. Public official DAO static website, maintained but quiet. GitHub Pages is enabled and CNAME is mooncatdao.org; no local deploy workflow was observed.

Implementation. Plain static HTML/CSS/JS with index.html, style.css, allcats.html, images, a public/wiki/ port, and a hof/ subtree. It has no observed package manager manifest or server-side code. allcats.html links cats to mooncatrescue.com/mooncats/<id>.

Dependency boundary. /hof/ is a deployment artifact supplied by the HOF workflow. The DAO website does not receive the HOF admin page, Functions, OAuth, or GitHub-writing helper. A current local checkout had unrelated dirty files and was not altered.

dao-collab

Purpose and status. Private static research/collaboration reader, maintained but quiet. It contains ChainStation landing-page research rather than the ChainStation production application.

Implementation. Astro 7.2 static output, TypeScript 5.9, @astrojs/check, Playwright and Sharp for optional screenshot capture. Primary entry points are src/pages, src/lib/content.ts, content/chainstation/landing-pages/, and the capture script. astro.config.mjs sets output: 'static' and trailing slashes.

Content operations. .pages.yml configures a Pages CMS content collection that permits creation/rename but not deletion of Markdown records. It has no observed chain/RPC/backend integration and no confirmed hosting domain. This audit itself is intentionally added under its content/ tree, not its runtime source.

dao-stuff

Purpose and status. Private low-change governance document repository. The available remote tree contains proposal/product-requirement/scope-of-work templates, a proposal area, and rejected/withdrawn archives; its README describes it simply as a place for proposals and related material.

Implementation/deployment. Markdown only. No manifest, workflow, runtime source, or deployment configuration was observed. A local Projects/dao checkout has a non-MoonCatDAO origin and therefore was not treated as this repository’s mirror.

hof-website-private

Purpose and status. Private security and deployment documentation companion for HOF. Remote/local latest is 5afc89b (2026-06-07), and GitHub metadata identifies AGPL-3.0.

Contents. It has a package/Wrangler configuration matching the public HOF baseline, but the local root is documentation-led: SECURITY_AUDIT.md, PROJECT_CONTEXT.md, PUBLIC_REPO_REVIEW.md, deployment notes, and contributor/notice material. No workflow or public asset/function tree was observed in this local counterpart.

Notable boundary. Its checked-in audit reports no Critical/High finding in the reviewed version, but that document is historical review evidence rather than a fresh security conclusion. It explicitly notes direct admin writes to a configured branch, unpinned Action tags, and the need to confirm production Cloudflare routing. No automated synchronization from public HOF source to this private documentation repo was observed.

ratemymooncat-website

Purpose and status. Public, legacy/dormant ratemymoon.cat static site. Its last repository push was 2025-08-05; GitHub Pages is enabled and its root CNAME is ratemymoon.cat.

Implementation. Plain HTML/CSS and committed image/chart assets; no package manifest, CI workflow, server function, or client RPC code appeared in the remote tree. index.html includes Google Analytics, Google Fonts, and constructs outbound OpenSea/Blur collection-filter links. Its charts are editorial/community taxonomy, not an on-chain trait service; the page itself says they are subjective and not financial advice.

.github-private

Purpose and status. Private organization-profile/policy repository. The accessible tree contains only profile/readme.md; no application code, workflow, or deployment configuration was exposed. Its remote latest commit is d43ce30 (2026-03-24). The repository therefore belongs in the organizational inventory but not in application architecture diagrams.

Technology and external-service summary

Cross-repository observations

Factual observations

• The organization has no observed shared package layer. Contract addresses and MoonCat identifier semantics are duplicated in several task-specific repositories; mooncat-kb is the strongest written reference but not an imported runtime dependency.
• Generated artifacts committed to Git are a central operating pattern. It aids static hosting and auditability, but repository branch-write permissions, workflow credentials, and generated-data review discipline become important operational dependencies.
• The naming index is the only confirmed event-driven pipeline. It explicitly preserves a finalization boundary, which avoids treating a webhook as chain truth.
• HOF has the broadest operational surface: public static display, scheduled on-chain generation, third-party metadata/image calls, Cloudflare Functions/OAuth, GitHub Contents writes, two deployment methods, and a cross-repository mirror.
• The KB/library pair has the clearest source-of-truth design: mooncat-kb is canonical, mooncat-kb-library is an intentionally generated static presentation layer. The dispatch path reduces manual release drift.
• mooncat-holder-activity correctly treats wrapper forms as a resolution problem rather than assuming wrapper token IDs are rescue orders. Its snapshot has a strong “historical not live” framing.
• The private hof-website-private repository is documentation/audit-oriented and should not be conflated with the deployed public HOF source merely because package/Wrangler metadata overlaps.
• dao-stuff and .github-private are organizational support repositories, not software runtime components. Including them in an application dependency diagram would create false coupling.

Documentation and operational opportunities (recommendations, not implemented)

1. Maintain one compact organization-level dependency register for the three confirmed cross-repository write/build relationships: name data consumers, KB → library dispatch, and HOF → DAO HOF mirror. This would make tokens, event names, inputs, and fallback behavior easier to audit without searching workflows.
2. Preserve finalized-versus-provisional naming labels at every downstream consumer boundary. The name-index design is careful; accidental use of *-live.json as archival truth would be the main semantic risk.
3. Document the intended production split for HOF: GitHub Pages public viewer versus Cloudflare Functions-enabled admin host. The source explicitly says they have different capabilities, but current DNS/routing is external to repositories.
4. Consider a deliberate policy for GitHub Actions pinning and cross-repository credentials. Existing evidence identifies Actions major tags and direct main writes; this is a maintainability/supply-chain decision, not a reported compromise.

Important uncertainties and source-access limits

• This audit could read GitHub metadata and accessible repository content, including private repository inventory/tree information. It could not inspect organization settings, repository secrets, Action run history, webhook configuration, Cloudflare dashboard state, deployment logs, GitHub Pages DNS resolution, or permissions behind the configured tokens.
• No live Ethereum/API/RPC requests were made. Contract addresses and snapshot semantics are source-backed, but current ownership, current holder activity, current names, ENS/delegate metadata, and image/API behavior are unverified.
• The exact deployed HOF Cloudflare custom domain/function route is unknown from repository evidence. GitHub Pages deployment is confirmed by workflows/metadata; Function-host routing is only documented.
• dao-collab has Pages CMS configuration but no source-backed proof of its deployment host/domain.
• RateMyMoonCat’s Pages enablement and CNAME are repository metadata/configuration; live availability and analytics behavior were not tested.
• .github-private source access showed only the profile README tree; it is appropriately catalogued as an organizational repository, but its broader policy/administrative purpose cannot be inferred.
• Local checkout revisions and uncommitted state were observed only to determine evidence freshness. No local repository was updated, cleaned, fetched, or otherwise changed.

Source locations for follow-up

• Naming pipeline: name-index/README.md, src/constants.js, worker/src/index.js, docs/automated-publishing.md, .github/workflows/publish-naming-events.yml.
• KB/library boundary: mooncat-kb/README.md, data/name-index-integration.json, data/contract-registry.json, .github/workflows/notify-library.yml; mooncat-kb-library/README.md, scripts/generate-kb.mjs, .github/workflows/deploy-pages.yml.
• Holder snapshot: mooncat-holder-activity/src/constants.js, src/rpc.js, src/ownership.js, src/activity.js, README.md.
• HOF/public mirror: hof-website/README.md, wrangler.jsonc, scripts/dayoneclub.mjs, scripts/sync-mooncat-names.mjs, functions/, and .github/workflows/; mooncatdao-website/CNAME and hof/.
• Private HOF documentation: hof-website-private/SECURITY_AUDIT.md, PUBLIC_REPO_REVIEW.md, and PROJECT_CONTEXT.md.