Copier templates, one per stack preset. They are versioned
together, by a repo-wide vX.Y.Z git tag — there is no per-preset tag series, and the
templates/<name>/vX.Y.Z scheme this file used to describe never existed. A release moves
every preset, which is why the table below has no version column: the answer is always the
newest vX.Y.Z (see docs/VERSIONING.md).
| Preset | Stack |
|---|---|
spring-kotlin-react/ |
Spring Boot 4 + Kotlin + jOOQ + Liquibase / React + TS + Vite |
hono-react/ |
Hono + TS + Drizzle / React + TS + Vite |
pulumi-gcp-ts/ |
Pulumi Infrastructure-as-Code (TypeScript) on GCP — stacks, ComponentResources, CrossGuard policy, mock tests |
_shared/CONTRACT.md |
the binding contract every template must satisfy (questions, required files, versioning) |
Generate from the repo root (one copier.yml serves all presets — required for
copier update to work):
uvx copier copy --trust <wellforge repo/URL> <dest> --data preset=<preset>— or use /wellforge:new, which interviews, recommends, generates, and verifies.
Upgrades: /wellforge:upgrade in a generated project (releases = repo-wide vX.Y.Z tags).
Every template MUST emit:
.forge/manifest.json—{ template, version, answers }, the upgrade contract.copier-answers.yml— Copier's own update record- a project-local
CLAUDE.md+.claude/settings.jsonpre-wired for the wellforge plugin - CI workflows that call
gates/workflows/(pinned tag), never copy them
Preset count: the original Phase 7 pilot rule capped this at 2 presets. pulumi-gcp-ts
was added as a deliberate third — an Infrastructure-as-Code path is orthogonal to the two
application stacks (it reuses the existing quality-node.yml gate, adds no new toolchain to
the gates), so the pilot risk it guarded against does not apply. Do not add a fourth without
revisiting the pilot decision.