Files

Paul Payne 05b28cb584 Rename Castle -> Wild PC across the repo

Repo-side rename only (Phases 1-3 of the migration plan); the live box
(~/.castle, systemd units, /data/castle, domains) is a separate cutover.

- Slug `castle` -> `wildpc`: CLI command, module names (wildpc_core/cli/api),
  dist names, entry point `wildpc = wildpc_cli.main:main`.
- Identifiers: CastleConfig/NATSClient/DirError/MDNS -> Wildpc*.
- Env/constants: CASTLE_* -> WILDPC_*; ~/.castle -> ~/.wildpc, castle.yaml ->
  wildpc.yaml, /data/castle -> /data/wildpc.
- Systemd UNIT_PREFIX castle- -> wildpc-; own programs castle-api/gateway/etc.
- Display prose "Castle" -> "Wild PC" in docs, agent-guide files, README, frontend.
- Package dirs and bootstrap yaml renamed via git mv; lockfiles regenerated;
  redundant nested uv.lock files dropped (workspace root lock is authoritative).

Tests: core 273, cli 47, wildpc-api 120 all pass. Frontend type-checks + builds.
Fixed a stale test fixture (secret_env_path kind arg) broken pre-rename.

2026-07-18 22:55:08 -07:00

3.9 KiB

Raw Blame History

Hugo static sites in Wild PC

This is a stack — creation-time guidance for writing new sites. A stack is a template + conventions, not a runtime requirement. wildpc program create --stack hugo scaffolds from it (via Hugo's own hugo new site) and seeds the program's default build verb. An existing Hugo site adopted with wildpc program add doesn't need this stack — it declares its own commands: / build:. See @docs/registry.md for commands:, stack: (optional), and repo:.

How to build, serve, and manage Hugo sites as wildpc programs.

Stack

Generator: Hugo (extended recommended — needed for SCSS/asset processing)
Build: hugo --gc --minify → public/
Served: manager: caddy static deployment, in place at <name>.<gateway.domain>, with spa: false — the gateway resolves directory indexes (/posts/ → /posts/index.html) and 404s missing paths. (The default spa: true is a single-page-app fallback that serves the root index.html for every unmatched path — correct for React/Vite, but it swallows a Hugo site's in-page links back to the homepage. wildpc program create --stack hugo sets spa: false for you.)
Package manager (only if a theme needs an asset pipeline): pnpm

Hugo has one meaningful dev verb — build. It has no native lint/test/type-check, so the stack advertises only build / install / uninstall; wildpc check and friends aren't offered (a site can still declare its own, e.g. an HTML linter, under commands: — a declared verb always wins over the stack).

Create a new site

wildpc program create my-site --stack hugo --description "My site"
cd /data/repos/my-site
wildpc program build my-site      # hugo --gc --minify -> public/
wildpc apply my-site              # serve at my-site.<gateway.domain>

The scaffold delegates the canonical skeleton to hugo new site (archetypes/, content/, layouts/, static/, themes/, hugo.toml) and overlays the pieces a bare skeleton lacks: minimal layouts/ so the site builds and serves without a theme, an example content/posts/hello.md, a wildpc-flavored hugo.toml (baseURL = "/", so assets resolve at the root of the site's own subdomain), and a .gitignore for the regenerated public/ and resources/.

Develop with the live server:

hugo server -D        # http://localhost:1313, rebuilds on save

Adding a theme

Drop a theme under themes/ (usually a git submodule) and set theme in hugo.toml:

git submodule add https://github.com/<owner>/<theme>.git themes/<theme>

Themes with an asset pipeline (e.g. Blowfish + Tailwind) need a pre-build step before hugo. Declare it as a two-step build in programs/<name>.yaml — a declared build.commands overrides the stack's single-step default:

build:
  commands:
    - [pnpm, build]          # compile the theme's CSS/JS
    - [hugo, --gc, --minify] # render the site -> public/
  outputs: [public]

One-time setup those themes expect (run once in the source tree):

git submodule update --init --recursive
cd themes/<theme> && pnpm install

Deployment shape

wildpc program create --stack hugo writes:

programs/<name>.yaml — source, stack: hugo, build.outputs: [public].
deployments/statics/<name>.yaml — manager: caddy, root: public, reach: internal (flip to public to also expose over the tunnel).

The gateway serves <source>/public in place — no copy, no Node/Hugo process at runtime. wildpc program build regenerates public/; wildpc apply renders the route and reloads the gateway.

Adopting an existing Hugo site

No stack needed — adopt the repo and declare how it builds:

wildpc program add /path/to/site --name my-site

Then set build.commands (as above) and add a manager: caddy deployment. This is how a site with a bespoke build (submodule theme + Tailwind) is wired without the scaffold. See @docs/registry.md.

3.9 KiB Raw Blame History