Pre-1.0 · first area: frontend, 16 decisions
A distribution of decisions.
Teishoku (定食) is a Japanese set meal: a fixed, complete, coordinated combination — no choices to make, reliably good, every day. This project applies that idea to technical decision-making: one chef's versioned menu of opinionated choices, pinned by git commit hash and executed on your behalf by coding agents.
Tell your agent: Read https://github.com/sjdhome/teishoku/blob/master/ONBOARDING.md and set up Teishoku.Works with Claude Code today; other agent harnesses are best-effort. The agent installs the Skill and, if you want, pins your project.
The idea
One set meal, not a buffet
Teishoku exists to cure two diseases. The first is decision paralysis: every layer of a modern web stack offers a dozen defensible choices, and the energy spent weighing them is energy not spent building. Rework — and plenty of books since — made the point long ago: don't burn your best hours agonizing over details; get the thing you actually want to make out the door.
The second disease arrives later: long-term maintenance. The real cost of a choice shows up years after it — the abandoned library, the breaking major, the security patch nobody applied. So a decision here is a maintained artifact, not a recommendation: pinned majors, recorded rationale, migration plans, and advisories that reach even the oldest pin.
The first consumers are coding agents — Claude Code, Codex, pi — building web apps for product creators who cannot independently review engineering choices. Instead of asking an agent to re-litigate the stack on every project, Teishoku hands it a menu that has already been decided, implemented, and verified in production.
No choices to make
Decisions arrive as a coordinated set, not a menu of trade-off essays. Each decision declares what it requires and what it forbids, so the combination is coherent by construction.
Reliably good
Only decisions the chef personally runs in production and is willing to stand behind, long term. Every one records its rationale, the alternatives it rejected, and the signals that would sunset it.
Every day
The menu is maintained with release-engineering discipline: versioned by git commit, never changing under your feet, with security advisories that reach even the oldest pins.
How it works
Pin a commit, eat the meal
- 1
A menu version is a git commit
The whole repository is the menu. Pointing at a commit hash names an exact, immutable set of decisions — reproducible forever, at no cost.
- 2
Your project pins it
A teishoku.lock file at the project root records the menu version and the decisions actually adopted. New menu versions never silently change an existing project.
- 3
An agent executes it
A thin Skill teaches your coding agent the contract: read menu content at the pinned commit, follow each decision's implementation spec exactly, run its verification steps, and stop instead of improvising when a need falls outside the menu.
- 4
Errata reach you anyway
Advisories and known pitfalls are always read from the tip of main, regardless of the pin. Security corrections arrive for free, however old your menu version is.
{
"spec": 1,
"repo": "https://github.com/sjdhome/teishoku",
"track": null,
"resolved":
"6bababa0e00ad906512cd9426fbf816e75dbe444",
"applied": [
"fe-language", "fe-framework",
"fe-build", "fe-node-manager",
"fe-styling", "fe-formatting",
"fe-lint", "fe-project-layout",
"fe-routing"
]
}Upgrades are loud, never silent
A new menu version never changes an existing project. An upgrade happens only at your explicit request, and only through a migration plan derived from the target version's recorded migrations, a plain risk statement, a backup and rollback path, and your approval — in that order.
One decision per file, seven required sections, an immutable ID. Decision files are never deleted: a reversed decision is marked superseded, a dropped one retired. History stays in place.
- Decision
- The ruling, in one or two sentences: use X.
- Scope
- When it applies — and when it does not.
- Rationale
- Why, backed by the author's own production use.
- Rejected
- The alternatives considered, and why each lost.
- Implementation
- An executable spec for agents: directories, configuration, patterns, anti-patterns.
- Verification
- How an agent self-checks: commands and expected outcomes.
- Sunset
- The signals that would trigger re-evaluating the decision.
--- id: fe-framework status: active decided: 2026-08-24 requires: [fe-language, fe-build] forbids: [] --- ## Decision Use Next.js with the App Router as the application framework. ## Scope … ## Rationale … ## Rejected … ## Implementation … ## Verification … ## Sunset …
The first area: frontend
Sixteen decisions covering the frontend of a standard SaaS / CRUD web app. Areas are added only as real decisions accumulate — backend, infrastructure, and tooling follow when their time comes.
- fe-language
Language and strictness settings
- fe-framework
Framework and rendering model
- fe-build
Package manager, toolchain versions and scripts contract
- fe-node-manager
Node.js version management
- fe-styling
Styling approach
- fe-formatting
Code formatting
- fe-components
Component library policy
- fe-routing
Routing
- fe-data
Data fetching and state
- fe-forms
Forms
- fe-schema
Runtime schema validation
- fe-lint
Lint and typecheck
- fe-testing
Unit and component testing
- fe-e2e
End-to-end testing
- fe-project-layout
Directory structure
- fe-errors
Error handling and reporting
Requests outside the menu stop — they are recorded as candidates, never improvised. That refusal is a feature: it is what keeps every adopted decision one the chef actually stands behind.
Versioning & support
Payment buys the promise, not the bits
Every branch is public, LTS lines included. LTS branches open only when someone commits to paid support — what you pay for is the maintenance promise, never access to patches.
Free for every project, forever
- Pinning and reproducibility, forever
- Security advisories — including on old versions
- Upgrade prompts with plain risk framing
- The public menu itself, every branch included
Paid: LTS support
- LTS maintenance of a fixed menu version
- Proactive notification and upgrade assistance
- An SLA — a commitment to keep your version working
Detailed terms are defined when the first paid commitment exists — never speculatively.
Trust model
You are trusting one chef
The point of this repository is to make that trust inspectable. Every decision records its rationale, rejected alternatives, applicable conditions, and sunset criteria. The git history records every patch and reversal. Advisories record what turned out to be wrong.
Technical readers are welcome to audit; the menu's users borrow that public scrutiny. Menu content is not open to contribution — one chef — but pitfall reports and out-of-menu candidates are welcome as issues.
Get started
Order the set meal
Tell your agent: Read https://github.com/sjdhome/teishoku/blob/master/ONBOARDING.md and set up Teishoku.The agent reads ONBOARDING.md, installs the Skill for its harness, and — only if you ask — pins your project to the current menu version. From then on the pinned version never changes silently, and advisories reach you for free no matter how old your pin is.