Design-Paritaet 1.5 -> 1.6:
- Site-Set-page.tsconfig erreicht keine Datensaetze in Ordnern neben dem
Site-Root; solche Konfiguration gehoert in die globale page.tsconfig
der Extension. Symptom ist, dass eine TCEFORM-Aenderung genau fuer
einen Datensatztyp wirkungslos bleibt.
- Angebotene und gerenderte Crop-Variante koennen auseinanderlaufen,
dann beschneidet die Redaktion ins Leere.
- Feste Bildhoehe laesst das Seitenverhaeltnis ueber die Breakpoints
wandern, sodass kein Zuschnitt mehr ueberall passt; aspect-ratio statt
fester Hoehe.
- Umbrechende Labels brauchen eine reservierte Zeilenhoehe, sonst
springt der Rhythmus des Rasters; dabei die Untermarge des Absatzes
neutralisieren und die schmalste Geraetebreite pruefen, nicht nur 360.
- :has() laesst sich nicht in :has() verschachteln, die Regel wird
komplett verworfen - ohne jede Fehlermeldung.
- Neuer Abschnitt zu Meldungen, die Rasterartefakte statt Fehler sind:
gegen die Referenzseite pruefen, ueber mehrere Zoomstufen UND
Subpixel-Versaetze messen, das Ganze per Canvas in einem Durchgang -
und rechtzeitig sagen, dass Geometrie es nicht loest.
v11->v14 1.1 -> 1.2:
- Ein "verlorenes" Feld ist oft ein umgebautes Feld; zwei Spalten werden
gern zu einem Feld plus Schalter. Erst das neue Modell pruefen, bevor
man eine fremde Extension patcht - dann ist es eine Datenmigration.
Dazu die abgesicherte UPDATE-Bedingung und der Hinweis, dass Fluid
keinen !-Operator kennt.
- Vor "Regression" gegen die Referenzseite pruefen: zwei Tickets zum
selben fehlenden Element koennen Verlust und Neuwunsch sein.
Cutover 1.1 -> 1.2:
- Eingebettete Fremddienste sperren sich per frame-ancestors oft gegen
Staging. Solche Tests sind dort in keinem Browser moeglich; frueh
klaeren, den eigenen Anteil trotzdem pruefen.
Redmine 1.3 -> 1.4:
- Textile beendet den Durchstrich am ersten Bindestrich im Text, ein
Pfeil laesst also die Handlungsaufforderung ungestrichen stehen; HTML
hilft nicht, Redmine escapt es. Und das Ergebnis nachsehen, die API
bestaetigt nur die Speicherung.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die Skill wird von mehreren Personen genutzt, deshalb kann bei Ilja
nicht "(the user)" stehen - wer sie bedient, ist offen. Stattdessen ein
Hinweis, dass jede der genannten Personen gerade am Werk sein kann und
ein Ticket nicht deshalb ihres ist, weil sie danach fragt.
Ilja ausserdem als Senior-Entwickler gefuehrt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sven stand bisher nur als Anhaengsel in Iljas Punkt. Er bekommt einen
eigenen Eintrag mit seiner Rolle als Senior-Entwickler und Maintainer
der gemeinsam genutzten Extensions.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Nachtrag zur Rollenuebersicht: Ranju gehoert ebenfalls zur
Entwicklungsseite, ein ihr zugewiesenes Ticket ist also technisch und
nicht redaktionell.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Bearbeiter eines Tickets sagt, um welche ART von Arbeit es geht.
Die Rollen sind ueber alle TYPO3-Projekte hinweg dieselben, deshalb
gehoeren sie in die Skill und nicht in ein Projektgedaechtnis, das nur
fuer ein Projekt geladen wird.
Festgehalten: Ilja und Sven entwickeln, Corinna macht Design und den
Grossteil der redaktionellen Arbeit, Eva fuehrt das Projekt und aendert
redaktionell im Kleinen. Daraus folgen zwei Regeln, die sich in der
Praxis bewaehrt haben: ein redaktionelles Ticket nicht stillschweigend
selbst erledigen, aber CSS und Code auch dann uebernehmen, wenn das
Ticket jemand anderem zugewiesen ist - Tickets mischen beides oft, also
nach der Natur der einzelnen Punkte aufteilen und sagen, welche Haelfte
man liegen laesst.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Notiz und Status setzen ist in Ordnung, assigned_to_id nicht anfassen —
das entscheidet der User selbst.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Zwei Ergaenzungen zu den Posting-Regeln: keine Icons, Emoji oder
dekorativen Symbole im Ticket-Text, und als Norm zwei bis drei Saetze
ohne Commit-Hashes, Dateinamen oder Messwerte. Der Kunde hat nicht
gefragt, wie etwas geloest wurde, sondern ob.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Small, generic skill for reading/updating a self-hosted Redmine over its
REST API from the CLI: API-key-in-header auth (never inline the secret),
issues/journals/attachments endpoints, editing a journal note in place,
the collection-ticket pattern, Textile (not Markdown) formatting +
localized statuses, and the team posting-style rules (minimal
customer-visible notes — strike through or "erledigt", never the bug's
cause; don't post unless asked). Distilled from the IVV Redmine notes.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
melnicenkoandClaude Opus 5