feat(site): rewrite public copy around the batch chain

Replace slogan-heavy bilingual copy with concrete industrial prose on home, about, work, notes, and contact, without invented metrics or em dashes.

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Jan Wagner
2026-08-16 19:05:53 +02:00
co-authored by Cursor
parent 7e8313c96e
commit 042ea88d94
13 changed files with 383 additions and 199 deletions
+92 -48
View File
@@ -20,9 +20,9 @@ export type LocalizedProject = {
stance: string;
stack: string;
role: string;
situation: string;
situation: string[];
decisions: string[];
outcome: string;
outcome: string[];
proof: string;
lesson: string;
stages: { title: string; text: string }[];
@@ -42,46 +42,70 @@ const projects: Record<ProjectSlug, { number: string; href?: string; images: Pro
status: "Öffentliche Produkt-Demo",
label: "Industrie-Software · Produktentwicklung",
title: "W-Make Batch",
summary: "Batchmanagement für die Behälterglas-Produktion vom Satzzettel bis zum Tagesprotokoll.",
stance: "Das Produktionsprodukt. Eine öffentliche Demo zeigt den Ablauf, nicht den Kundenstand.",
summary: "Batchmanagement für die Behälterglas-Produktion: vom Satzzettel über den Siloabzug bis zum Tagesprotokoll.",
stance: "Das Betriebsprodukt. Die öffentliche Demo zeigt den Ablauf, nicht den Kundenstand.",
stack: "Node.js · Express · SQLite · Web Components · native Tests · Playwright",
role: "Domänenmodell, Full-Stack-Entwicklung und technische Qualität.",
situation: "Ein Produktionsprozess lebt von Rezepten, Materialverbrauch, Silos, Schichten und Berechnungen. Wird das als lose Sammlung von Masken gebaut, gehen fachliche Zusammenhänge verloren — und Buchungen werden zu editierbaren Tabellenzeilen.",
situation: [
"In der Behälterglas-Produktion ist der Tag eine Kette. Eine Rezeptversion gilt, ein Satzzettel geht an die Waage, der Verbrauch geht vom Silo ab, Oxid und Redox müssen zur Wanne passen, die Schicht übergibt, der Tag schließt. Bricht eines dieser Glieder, stehen am nächsten Morgen drei Zahlen im Raum, die nicht zusammenpassen.",
"Wird das als lose Sammlung von Masken gebaut, kopiert jemand die Werte von einem Blatt auf das nächste. Der Satzzettel sagt etwas anderes als der Silostand, das Protokoll etwas anderes als beides. Die schnellste Korrektur in Software ist dann das Löschen oder Überschreiben einer Zeile. Nach dem Wiegen ist das bereits eine Lüge gegenüber Bestand und Schicht.",
"Dazu kommt der Druck der Schichtübergabe. Was mündlich nachgereicht wird, steht nirgendwo. Wer morgens übernimmt, erbt eine Halle und eine Tabelle, die sich widersprechen.",
],
decisions: [
"Fachliche Buchungen sind Zustände, keine CRUD-Datensätze zum beliebigen Löschen.",
"Der Satzzettel und das Tagesprotokoll gehören in dasselbe Modell, nicht in getrennte Tools.",
"Berechnungen und Materialflüsse bleiben nachvollziehbar, auch wenn die Oberfläche schlank bleibt.",
"Fachliche Buchungen sind Zustände. Eine Korrektur nach dem Siloabzug ist eine Gegenbuchung, ein Storno oder ein Abgleich, kein DELETE auf der Zeile.",
"Satzzettel, Gemengebuch und Tagesprotokoll gehören in dasselbe Modell. Zwei Tools an dieser Naht erzeugen denselben Papierbruch, den die Software ersetzen sollte.",
"Oxid, Redox, Satzgröße und Kosten bleiben an der Rezeptversion hängen und liegen in eigenen Modulen. Die Oberfläche zeigt die Zahl, sie erfindet sie nicht.",
"Schichtbeginn ist eine gemeinsame Uhr, kein voreingestelltes Feld in einem Formular. Ohne diese Uhr driftet der Tag zwischen Stationen.",
"Migrationen, Sicherung und ein Abschluss, den man wiederholen kann, gehören zum Produkt. Ein System, das nur in der Demo schließt, schließt in der Halle nicht.",
"Die öffentliche Demo zeigt das Modell. Kundendaten, Mengen und interne Kennzahlen bleiben außen vor.",
],
outcome: [
"Ein betreibbares System mit öffentlicher Demo unter batch.w-make.com. Man kann den Weg von der Rezeptversion über den Satzzettel in das Tagesprotokoll nachgehen, ohne einen Kundenstand zu sehen.",
"Vertrauliche Hallendaten, Rezepte und Mengen stehen nicht auf dieser Site. Es gibt keine veröffentlichten Durchsatzzahlen, keine Verfügbarkeitsversprechen und keine Kundennamen.",
],
outcome: "Ein betreibbares System mit öffentlicher Demo. Vertrauliche Kundendaten, Mengen und interne Kennzahlen bleiben bewusst außen vor.",
proof: "Öffentliche Produkt-Demo unter batch.w-make.com. Die Case Study beschreibt das Modell, nicht den Kundenstand.",
lesson: "Ein Produktionssystem wird besser, wenn die fachliche Irreversibilität Teil der Architektur ist — nicht eine Validierung im Formular.",
lesson: "Ein Produktionssystem wird besser, wenn die fachliche Unumkehrbarkeit im Datenmodell steckt. Eine Validierung im Formular kommt zu spät, sobald Silo und Protokoll schon geschrieben haben.",
stages: [
{ title: "Rezept", text: "Zusammensetzung und Version bleiben mit dem späteren Verbrauch verbunden." },
{ title: "Satz", text: "Der Satzzettel ist ein fachlicher Auftrag, kein Ausdruck einer Tabelle." },
{ title: "Protokoll", text: "Der Tag schließt als nachvollziehbarer Zustand, nicht als exportierte Liste." },
{ title: "Rezept", text: "Zusammensetzung, Version, Temperatur und Kosten bleiben mit dem späteren Verbrauch verbunden." },
{ title: "Satzzettel", text: "Der Zettel ist der Auftrag an die Waage, kein Ausdruck einer Tabelle." },
{ title: "Silo", text: "Der Verbrauch geht vom Bestand ab. Danach ist die Buchung Teil der Halle." },
{ title: "Gemengebuch", text: "Was eingewogen wurde, bleibt an Satz und Rezeptversion gebunden." },
{ title: "Protokoll", text: "Der Tag schließt als Zustand, den die nächste Schicht vorfindet, nicht als exportierte Liste." },
],
},
en: {
status: "Public product demo",
label: "Industrial software · product development",
title: "W-Make Batch",
summary: "Batch management for container-glass production from the batch ticket to the daily log.",
stance: "The production product. A public demo shows the flow, not a client installation.",
summary: "Batch management for container-glass production: from the batch ticket through silo deduction to the daily log.",
stance: "The operations product. The public demo shows the flow, not a client installation.",
stack: "Node.js · Express · SQLite · Web Components · native tests · Playwright",
role: "Domain model, full-stack development, and technical quality.",
situation: "A production process lives on recipes, material use, silos, shifts, and calculations. Built as a loose set of screens, the domain relationships disappear — and bookings become editable table rows.",
situation: [
"In container-glass production the day is a chain. A recipe version holds, a batch ticket goes to the scale, consumption leaves the silo, oxide and redox have to match the furnace, the shift hands over, the day closes. If one link breaks, three figures that do not agree are waiting the next morning.",
"Built as a loose set of screens, someone copies values from one sheet to the next. The ticket says one thing, the silo another, the log a third. The fastest correction in software is then to delete or overwrite a row. After weighing, that is already a lie to stock and to the shift.",
"Shift handover adds pressure. What is passed on verbally is written nowhere. Whoever takes over in the morning inherits a hall and a table that contradict each other.",
],
decisions: [
"Domain bookings are states, not CRUD records that can be deleted at will.",
"The batch ticket and the daily log belong in one model, not in separate tools.",
"Calculations and material flows stay traceable even when the interface stays lean.",
"Domain bookings are states. A correction after silo deduction is a reversing entry, a cancellation or a reconcile, not a DELETE on the row.",
"Batch ticket, batch book and daily log belong in one model. Two tools at that seam recreate the paper fracture the software was meant to replace.",
"Oxide, redox, batch size and cost stay bound to the recipe version and live in their own modules. The interface shows the figure. It does not invent it.",
"Shift start is a shared clock, not a default in a form field. Without that clock the day drifts between stations.",
"Migrations, backup and a close you can repeat belong to the product. A system that only closes in the demo will not close on the floor.",
"The public demo shows the model. Client data, volumes and internal metrics stay off the site.",
],
outcome: [
"An operable system with a public demo at batch.w-make.com. You can follow the path from recipe version through the batch ticket into the daily log without seeing a client installation.",
"Confidential plant data, recipes and volumes are not on this site. There are no published throughput figures, no uptime claims and no client names.",
],
outcome: "An operable system with a public demo. Confidential client data, volumes, and internal metrics stay unpublished.",
proof: "Public product demo at batch.w-make.com. This case study describes the model, not a client installation.",
lesson: "A production system improves when domain irreversibility is part of the architecture — not a form validation.",
lesson: "A production system improves when domain irreversibility lives in the data model. A form validation comes too late once silo and log have already been written.",
stages: [
{ title: "Recipe", text: "Composition and version stay tied to later consumption." },
{ title: "Batch", text: "The ticket is a domain order, not a printout of a table." },
{ title: "Log", text: "The day closes as a traceable state, not an exported list." },
{ title: "Recipe", text: "Composition, version, temperature and cost stay tied to later consumption." },
{ title: "Ticket", text: "The ticket is the order to the scale, not a printout of a table." },
{ title: "Silo", text: "Consumption leaves the stock. After that the booking is part of the hall." },
{ title: "Batch book", text: "What was weighed stays bound to the batch and the recipe version." },
{ title: "Log", text: "The day closes as a state the next shift will find, not as an exported list." },
],
},
},
@@ -96,46 +120,66 @@ const projects: Record<ProjectSlug, { number: string; href?: string; images: Pro
status: "Eigenständig betreibbares Produkt",
label: "Standalone · Recipe Engineering",
title: "Batchmaker Studio",
summary: "Schlankes Recipe-Studio für Rezepte, Rohstoffe, Satzzettel und Glaschemie.",
stance: "Die Werkbank am Schreibtisch. Derselbe Fachkern, bewusst ohne Silos, Schichten und laufende Buchungen.",
summary: "Schlankes Recipe-Studio für Rezepte, Rohstoffe, Satzzettel und Glaschemie, ohne Silos und ohne laufende Schichten.",
stance: "Die Werkbank am Schreibtisch. Derselbe Fachkern wie W-Make Batch, ohne den Betrieb der Halle.",
stack: "Node.js · Express · node:sqlite · Vanilla JS · Vite · native Tests",
role: "Produktarchitektur, Full-Stack-Entwicklung und Calculation Engine.",
situation: "Rezeptarbeit braucht denselben fachlichen Kern wie die Produktion — aber nicht Silos, Schichten und laufende Buchungen. Ein volles Betriebssystem ist für die Entwicklung am Schreibtisch zu schwer.",
decisions: [
"Derselbe Domänenkern, bewusst kleinerer Zuschnitt.",
"Eigener Server, eigene SQLite-Datei, eigene schlanke Oberfläche.",
"Validierung als sichtbarer Schritt, nicht als versteckte Nebenwirkung.",
situation: [
"Rezeptarbeit braucht denselben fachlichen Kern wie die Produktion: Rohstoffe, Oxidrechnung, Redox, Satzgröße, Kosten, Versionen. Sie braucht nicht Silos, Schichten und laufende Buchungen. Ein volles Betriebssystem ist für die Entwicklung am Schreibtisch zu schwer. Man will eine Rezeptversion ändern, die Chemie prüfen und einen Satzzettel drucken, ohne eine Schicht zu eröffnen.",
"Wer beides in ein Produkt zwingt, belastet die Werkbank mit Hallenregeln und die Halle mit Entwurfszuständen. Entwürfe geraten in den Bestand, oder der Bestand wird am Schreibtisch nachgebaut. Beides ist teuer.",
],
outcome: "Ein eigenständig betreibbares Werkzeug für Rezeptentwicklung, Glaschemie und druckfertige Satzzettel. Keine unbelegten Effizienzversprechen.",
proof: "Öffentliche Case Study und der bewusst getrennte Produktzuschnitt gegenüber W-Make Batch.",
lesson: "Produktgrenzen sind Architektur. Ein gutes Werkzeug muss den Nachbarprozess nicht vollständig abbilden.",
decisions: [
"Derselbe Fachkern für Rezept, Rohstoff und Glaschemie, kleinerer Zuschnitt: keine Silos, keine Schichten, keine laufenden Buchungen.",
"Eigener Server, eigene SQLite-Datei, eigene schlanke Oberfläche. Studio hängt nicht am Betriebsprodukt.",
"Validierung ist ein sichtbarer Schritt. Eine Rechnung, die still im Speichern mitläuft, wird später niemand mehr finden.",
"Satzzettel entstehen hier als Entwurf und Druckvorlage. Gebucht wird erst in W-Make Batch.",
"Keine unbelegten Effizienzversprechen. Das Produkt ist die Werkbank, nicht ein Ersatz für den Betrieb.",
],
outcome: [
"Ein eigenständig betreibbares Werkzeug für Rezeptentwicklung, Glaschemie und druckfertige Satzzettel. Man kann am Schreibtisch arbeiten, ohne eine Schicht zu simulieren.",
"Die Grenze zu W-Make Batch bleibt sichtbar. Was in Studio entworfen wird, wird in Batch zum Auftrag. Die Case Study belegt den Zuschnitt, nicht einen Kundenstand.",
],
proof: "Öffentliche Case Study und der getrennte Produktzuschnitt gegenüber W-Make Batch.",
lesson: "Produktgrenzen sind Architektur. Ein gutes Werkzeug muss den Nachbarprozess nicht vollständig abbilden. Wer Studio und Betrieb vermischt, trägt Entwürfe in den Bestand oder den Bestand an den Schreibtisch.",
stages: [
{ title: "Rezepte", text: "Versionieren, vergleichen, importieren und exportieren." },
{ title: "Glaschemie", text: "Oxide, Redox, Physik und nachvollziehbare Berechnungen." },
{ title: "Rezepte", text: "Versionieren, vergleichen, importieren und exportieren, gebunden an Rohstoffe und Kosten." },
{ title: "Rohstoffe", text: "Stammdaten, aus denen Oxid und Satz später gerechnet werden." },
{ title: "Glaschemie", text: "Oxide, Redox, Physik und Rechnungen, die man prüfen kann." },
{ title: "Satzzettel", text: "Entwurf, Skalierung, Vorschau, druckfertige Ausgabe." },
{ title: "Validierung", text: "Ein eigener Schritt, bevor eine Version als brauchbar gilt." },
],
},
en: {
status: "Independently operable product",
label: "Standalone · recipe engineering",
title: "Batchmaker Studio",
summary: "A lean recipe studio for recipes, raw materials, batch tickets, and glass chemistry.",
stance: "The desk-side workbench. The same domain core, deliberately without silos, shifts, and live bookings.",
summary: "A lean recipe studio for recipes, raw materials, batch tickets and glass chemistry, without silos and without live shifts.",
stance: "The desk-side workbench. The same domain core as W-Make Batch, without the halls operations.",
stack: "Node.js · Express · node:sqlite · Vanilla JS · Vite · native tests",
role: "Product architecture, full-stack development, and calculation engine.",
situation: "Recipe work needs the same domain core as production — but not silos, shifts, and live bookings. A full operations system is too heavy for desk-side development.",
decisions: [
"The same domain core, deliberately smaller scope.",
"Its own server, SQLite file, and lean browser interface.",
"Validation as a visible step, not a hidden side effect.",
situation: [
"Recipe work needs the same domain core as production: raw materials, oxide calculation, redox, batch size, cost, versions. It does not need silos, shifts and live bookings. A full operations system is too heavy for desk-side development. You want to change a recipe version, check the chemistry and print a ticket without opening a shift.",
"Force both into one product and the workbench inherits hall rules while the hall inherits draft states. Drafts leak into stock, or stock is rebuilt at the desk. Both are expensive.",
],
outcome: "An independently operable tool for recipe work, glass chemistry, and print-ready batch tickets. No unverifiable efficiency claims.",
proof: "This public case study and the deliberate product boundary against W-Make Batch.",
lesson: "Product boundaries are architecture. A good tool does not have to model the neighbouring process in full.",
decisions: [
"The same domain core for recipe, raw material and glass chemistry, smaller scope: no silos, no shifts, no live bookings.",
"Its own server, SQLite file and lean browser interface. Studio does not hang off the operations product.",
"Validation is a visible step. A calculation that runs quietly on save will not be found later.",
"Batch tickets originate here as draft and print-ready output. Booking happens in W-Make Batch.",
"No unverifiable efficiency claims. The product is the workbench, not a substitute for operations.",
],
outcome: [
"An independently operable tool for recipe work, glass chemistry and print-ready batch tickets. You can work at the desk without simulating a shift.",
"The boundary with W-Make Batch stays visible. What is drafted in Studio becomes an order in Batch. This case study documents the cut, not a client installation.",
],
proof: "This public case study and the separate product boundary against W-Make Batch.",
lesson: "Product boundaries are architecture. A good tool does not have to model the neighbouring process in full. Mix studio and operations and you carry drafts into stock, or stock onto the desk.",
stages: [
{ title: "Recipes", text: "Version, compare, import, and export." },
{ title: "Chemistry", text: "Oxides, redox, physics, and traceable calculations." },
{ title: "Recipes", text: "Version, compare, import and export, bound to raw materials and cost." },
{ title: "Materials", text: "Master data from which oxide and batch size are later calculated." },
{ title: "Chemistry", text: "Oxides, redox, physics, and calculations you can inspect." },
{ title: "Tickets", text: "Draft, scale, preview, print-ready output." },
{ title: "Validation", text: "A dedicated step before a version counts as usable." },
],
},
},