MoonCat DAO Collab

A small, static Astro reader for collaborative MoonCat DAO research. Markdown is the source of truth, GitHub is the canonical datastore, Pages CMS provides lightweight browser editing, and Cloudflare Pages publishes the reader automatically from main.

The current workspace focuses on ChainStation landing-page research under content/chainstation/landing-pages/.

How to use the site

There are two normal editing workflows.

Quick content edit in the browser

Open a document in the public reader.
Click Edit this document in the document header, or Edit in the sticky site header while viewing a document.
Pages CMS opens directly on that Markdown file.

If Pages CMS asks you to sign in, use whichever access method applies to you:
- GitHub access: sign in with GitHub if you already have access to the mooncatdao/dao-collab repository.
- Pages CMS collaborator: if you do not want to use GitHub/Git, ask a DAO maintainer for a Pages CMS collaborator invite to your email address, then sign in through that invitation.
Make the change and click Save.
Use the browser Back button to return to the published reader when you are done.
Pages CMS commits the edit directly to main on GitHub.
Cloudflare Pages detects the new commit and rebuilds the public site automatically.

The public reader may take a few minutes to update while Cloudflare completes the deployment.

Local/code/heavier edit

Before starting local work, sync remote changes first because Pages CMS or another contributor may have committed since the last local session:

git pull --rebase

Then make the change locally and validate it:

npm run check
npm run build

Commit and push as usual:

git add <files>
git commit -m "Describe the change"
git push

Cloudflare Pages will rebuild from the pushed main commit.

Using rebase for pulls keeps local commits on top of browser-edited commits without creating unnecessary merge commits. This repository can use rebase by default with:

git config pull.rebase true

Do not force-push main just to resolve a normal Pages CMS/local divergence.

Reading and search

The reader generates navigation and routes from the Markdown files at build time. Search is also generated at build time and runs entirely in the browser; there is no hosted search service.

Search matches document titles, paths, and document text. Results show context around the matching text when possible. When the match is in document text, opening the result jumps to and highlights the first matching occurrence.

Document pages show the most recent Git commit date for the source file when Git history is available at build time, plus direct View source and History links. Section headings expose a # control on hover/focus for copying a direct link to that section.

The repository README is also rendered in the reader as How to use this site.

Local development

Requirements: Node.js 22.12+ (Astro 7 requirement).

npm install
npm run dev

Open the local URL printed by Astro. The site has no runtime server, database, authentication, or required external service.

Useful commands:

npm run build    # Generate the static site in dist/
npm run preview  # Serve the generated site locally
npm run check    # Astro and TypeScript diagnostics

Content and routes

Add or edit collaborative Markdown under content/chainstation/landing-pages/. Files and nested folders are discovered at build time, so a new document does not need a route file.

README.md files inside that content tree are treated as repo/project documentation and are excluded from the landing-page document collection, navigation, search, and Pages CMS collection. The root repository README.md is handled separately and is rendered as How to use this site.

Pages CMS-managed Markdown documents should use YAML frontmatter matching the collection fields:

---
title: A friendly document title
description: A short description for metadata and listings.
---

The generated landing-page navigation retains nested folder context.

Pages CMS

The root .pages.yml exposes content/chainstation/landing-pages/, including nested folders, with a Markdown rich-text editor. Changes are written directly back to GitHub; Pages CMS is not a second content store.

The reader’s Edit this document action deep-links directly to the corresponding file in the mooncatdao/dao-collab Pages CMS collection.

Contributor access

There are two ways to give someone editing access:

GitHub contributor: give the person access to the repository. They can edit through Pages CMS or use the normal Git workflow.
Pages CMS collaborator: for someone who does not want to use GitHub/Git directly, ask for their email address and invite them as a Pages CMS collaborator. They can then edit the exposed Markdown content in the browser without needing repository access.

Pages CMS collaborator access is intended for content editing only; repository configuration and site code remain managed through GitHub/local development.

Pages CMS is configured with settings.commit.identity: user, so browser edits include the editor’s name and email in Git commit metadata when available. Collaborator writes are still authorized through the Pages CMS GitHub App when the contributor does not have repository access.

If Pages CMS saves a change while a local checkout also has work, sync with:

git pull --rebase

before the next push.

PUBLIC_GITHUB_REPO_URL can be set at build time to enable exact per-document GitHub source links. PUBLIC_PAGES_CMS_URL can override the default Pages CMS edit base if the repository or branch changes.

These are public build-time URLs, not secrets. Do not put tokens or credentials in the Astro project or Cloudflare environment.

Cloudflare Pages

The public reader is deployed from the GitHub repository with Cloudflare Pages.

Current build settings:

Production branch: main
Build command: npm run build
Build output directory: dist
Node version: 22.12 or newer

Cloudflare automatically rebuilds when a commit lands on main, whether that commit came from Pages CMS or from local development. The output is fully static and does not need Functions, a database, or a special adapter.

Screenshot research tooling

Reference-site screenshots are captured locally with the repo tooling. The survey remains the source of truth for capture targets.

npm run screenshots                 # desktop captures
npm run screenshots:mobile          # mobile captures
npm run screenshots:thumbnails      # generate missing thumbnails without web capture

Existing screenshots are skipped unless the capture script is run with --force. Full captures live under content/chainstation/landing-pages/research/screenshots/; generated thumbnails live in the thumbs/ subfolder.

Scope

This workspace currently covers ChainStation landing-page research and collaboration. It does not add governance proposals, comments, accounts, realtime collaboration, custom CMS code, or a GitHub write API. Additional DAO collaboration areas can be added later as separate content collections without changing the current landing-page source boundary.