Study X — Where next¶

Date: 2026-08 · Status: study — a proposed plan, for the owner to accept, reorder or reject

Honest diagnosis¶

Templetry is technically ahead of its own usage. In two weeks it went from an idea to a v1 with a written compatibility policy, 21 CI-verified forms across eleven ecosystems, 12 pieces, three forge integrations and an MCP server. That is a lot of capability.

What has not grown at the same pace:

Usage. The catalog is designed for people who will adopt it, but no project outside this org has been generated from it. Study VIII's own criterion — "a piece earns its place when it is rewritten badly in every project" — is currently applied from intuition, not evidence. The v1.0.0 soak window was waived; that debt is unpaid.
Reach of the newest capability. Pieces are the most differentiating thing the product does, and they are CLI-only. The desktop app cannot list or add one.
Maintenance surface. Thirteen repositories and ~30 workflows, maintained by one person. This is now a standing cost that competes with new features.

Two findings from auditing the catalog (2026-08-14)¶

Nothing is verified on a schedule. A form's CI runs only when its repo is pushed. A green badge therefore means "this worked the day it was last touched", not "this works". Templates rot silently as their upstream dependencies move — and a template with stale or broken dependencies is worse than no template, because it fails in the user's project, not in ours.
Parents verify against different, sometimes ancient CLIs. kmp and android still render with engine v0.1.0 — seven minors behind. Their green CI proves compatibility with a superseded engine, not with the one a user installs today. web, rust, node, jvm and dotnet sit at v1.4.0; only go and python are current.

Neither is a crisis today. Both are exactly the kind of quiet decay that makes a template catalog untrustworthy in six months.

Outcome (2026-08-15). The owner accepted the plan and reordered it. Phases 1, 2 and 5 are done; phase 3 runs continuously; phase 4 was answered "not yet" — Templetry stays a self-use scaffolding project for now, so certification, code signing and adoption work are explicitly out of scope, and the rule against speculative additions was lifted in favour of growing the catalog. Statuses below are marked inline.

The plan¶

Phase 1 — Keep the promises already made (days) — ✅ done¶

Things shipped code implies but does not yet do:

✅ Piece updates — shipped in engine v1.8.0. Auditing it also turned up two defects worth recording: templetry update <dir> --apply silently previewed (Go's flag package stops at the first positional, so the flag was never parsed), and the answers file was going through the three-way merge like ordinary content — it kept the pieces: section only by luck of the merge, and a conflict there would have corrupted the record the whole cycle depends on. It is now excluded from the diff and rewritten from the record.
✅ Pieces in the desktop — shipped in desktop v1.6.0. A panel in Local's project preview: list what the template offers, mark what is applied, add with the piece's own variables.

Phase 2 — Stop the rot (days, then permanent) — ✅ done¶

✅ Weekly scheduled CI in every parent. schedule: cron on the Verify workflow, so upstream drift surfaces here rather than in a user's project. This was the single highest-value change in the whole plan: it converts "green when pushed" into "green today".
✅ One pinned CLI version, centrally managed. All ten parents brought to the current release. Doing it exposed a real defect: parents fetched the CLI with curl -sL, so a 404 was silently written to disk as an executable — every parent now uses curl -fsSL.
✅ Dependency updates on the templates themselves — Renovate on every repository carrying dependencies, extending one shared preset (renovate-config), plus the same policy adoptable by generated projects as the renovate common piece. (Remaining human step: installing the Renovate GitHub App on the org.)

Phase 3 — Pay the soak-window debt by dogfooding (weeks, in the background) — ⏳ ongoing¶

The honest way to validate v1 is to run real work through it. The owner already has candidates: the portfolio (carreerV2), the career API worker, future side projects.

Regenerate or migrate at least one real project from a catalog form.
Adopt pieces on it (rbac, audit-trail) and live with them.
Run templetry update on it monthly and let the friction dictate the backlog.

Rule for this phase: no new forms or pieces are added speculatively. What dogfooding demands gets built; what it does not demand waits. This directly answers the diagnosis — it converts guesses into evidence.

Superseded (2026-08-15). The owner lifted this rule: the project keeps growing on purpose while it is a self-use tool, and breadth is being built ahead of demand deliberately rather than by drift.

Phase 4 — Decide whether adoption is a goal (owner's call) — ⛔ answered: not yet¶

This is the fork in the road, and it should be a conscious choice rather than a drift:

If Templetry stays a personal tool, most of what follows is unnecessary. Skip to "steady state". ← this is the answer: certification, code signing and the adoption checklist below are deliberately not being done.

If it is meant to have users, then the blockers are not features:

Code signing. SmartScreen on an unsigned installer stops non-technical users cold. ~10 €/month for Azure Trusted Signing; nothing else in this list matters if the app cannot be installed comfortably.
A landing page and docs site. The wiki is excellent for us and unreadable as a first contact. One page answering "what is this, why not Copier/Cookiecutter, how do I start in 60 seconds".
Packaging: winget (after signing) and a Homebrew tap.
A worked example, end to end: "generate an API, adopt RBAC, update it three weeks later" — with output shown.

Phase 5 — At most one ambitious bet (months) — ✅ bet chosen and shipped¶

Only after phases 1–3, and only one:

✅ Common pieces (study VII phase 2, now ADR-0016, engine v1.9.0). audit-trail is the same idea in every ecosystem; it would have been copied five times. Shipped as cross-template pieces with applies_to, per-ecosystem implementations behind one name, and the source recorded per piece so an upstream fix reaches every adopter. This was the bet.
Piece dependencies (requires between pieces) — smaller, already identified in study VIII, and a prerequisite if the piece catalog keeps growing.
Templetry as a CI action — regenerate/verify templates from other people's pipelines. Cheap to build, unclear demand.

What to stop doing¶

Adding forms and pieces speculatively. The catalog covers eleven ecosystems with zero external users; breadth is no longer the constraint. Depth of use is.
Treating green CI as proof of health until phase 2 lands.

Steady state, once phases 1–3 land¶

A monthly rhythm rather than a project: watch the scheduled CI, apply dependency updates, run templetry update on the dogfooded projects, and add a piece only when a real project asked for it twice.

Decision points for the owner — resolved¶

Adoption: yes or no? → Not yet. Self-use scaffolding for now; promotion is a later, deliberate step.
Certificate budget (~10 €/month) → No, follows from (1).
Which real project gets dogfooded first → open; the portfolio and the career API remain the candidates.
Which single bet in phase 5 → common pieces, shipped.

What replaced this study as the forward view: the "Where next" section of state-of-the-art.md, which is kept current.