m/paliad
1
0
Fork 0
Code Issues 151 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

Submission generator — unified auto-naming scheme (date · initiator · …) + customizable #155

New Issue
Open
opened 2026-05-27 22:38:35 +00:00 by mAi · 3 comments
mAi commented 2026-05-27 22:38:35 +00:00
Collaborator
Copy Link

Request (m, 2026-05-28 00:37)

can we have our submission generator generally have a unified naming scheme where the date comes first, then the "initiator" ... the automated name should be customizable somewhere

Shape

  • Default pattern: <date> <initiator> <…> — date leads, then the initiator (party filing? lawyer drafting? case reference?), then the rest.
  • Customizable somewhere — a single place that controls the auto-generated submission name, so a firm / user / template can tweak without code changes.

Today's state

Auto-naming logic likely lives in internal/services/submission_draft_service.go or submission_base_service.go (whatever fills the default title on a freshly-created draft). Quick audit needed to confirm current pattern and where the format string lives.

Decisions to lock before implementing (worth a quick m grilling)

  1. What is "initiator"?
    • Filing party (claimant/defendant/court)
    • Drafting lawyer (current user)
    • Case reference (project.case_number)
    • Something else
  2. What date?
    • Today (draft creation date)
    • The deadline date the submission is for
    • The intended filing date (if known)
  3. Format spec
    • Date format: YYYY-MM-DD (sortable, ISO) or DD.MM.YYYY (German conventional)?
    • Separator: · / — / - / _ ?
    • Spaces in tokens? (e.g. firm names with spaces)
  4. Customization scope — where the override lives:
    • Per user (each lawyer's preference; user.settings JSON)
    • Firm-wide (admin setting; one pattern for all HLC users)
    • Per submission template (different bases override the pattern — e.g. UPC SoC vs DE Klageerwiderung)
    • All three (cascade: template > user > firm > built-in default)
  5. Format string grammar — define the syntax:
    • Go template ({{.Date}} {{.Initiator}} {{.Caseref}}) — flexible but lawyer-unfriendly
    • Simple tokens (%date% %initiator% %caseref%) — friendlier, less power
    • YAML/JSON config struct (no string template — explicit fields ordered) — least flexible, most validated

Acceptance (high level)

  • New draft auto-name follows the pattern; default is <date> <initiator> per m's brief
  • Override surface visible in settings (location TBD per Q4)
  • Tests cover the cascade if multi-level (Q4)
  • Existing drafts not retroactively renamed

NOT

  • Not blocking — the prod-500 fire (m/paliad#154) takes precedence.
  • Not in this train — this is a fresh feature, separate inventor/coder cycle.
  • Bump after the current Litigation Builder train (B3+) lands, unless m says sooner.
## Request (m, 2026-05-28 00:37) > can we have our submission generator generally have a unified naming scheme where the date comes first, then the "initiator" ... the automated name should be customizable somewhere ## Shape - **Default pattern**: `<date> <initiator> <…>` — date leads, then the initiator (party filing? lawyer drafting? case reference?), then the rest. - **Customizable somewhere** — a single place that controls the auto-generated submission name, so a firm / user / template can tweak without code changes. ## Today's state Auto-naming logic likely lives in `internal/services/submission_draft_service.go` or `submission_base_service.go` (whatever fills the default title on a freshly-created draft). Quick audit needed to confirm current pattern and where the format string lives. ## Decisions to lock before implementing (worth a quick m grilling) 1. **What is "initiator"?** - Filing party (claimant/defendant/court) - Drafting lawyer (current user) - Case reference (project.case_number) - Something else 2. **What date?** - Today (draft creation date) - The deadline date the submission is for - The intended filing date (if known) 3. **Format spec** - Date format: `YYYY-MM-DD` (sortable, ISO) or `DD.MM.YYYY` (German conventional)? - Separator: ` · ` / ` — ` / ` - ` / `_` ? - Spaces in tokens? (e.g. firm names with spaces) 4. **Customization scope** — where the override lives: - **Per user** (each lawyer's preference; user.settings JSON) - **Firm-wide** (admin setting; one pattern for all HLC users) - **Per submission template** (different bases override the pattern — e.g. UPC SoC vs DE Klageerwiderung) - **All three** (cascade: template > user > firm > built-in default) 5. **Format string grammar** — define the syntax: - Go template (`{{.Date}} {{.Initiator}} {{.Caseref}}`) — flexible but lawyer-unfriendly - Simple tokens (`%date% %initiator% %caseref%`) — friendlier, less power - YAML/JSON config struct (no string template — explicit fields ordered) — least flexible, most validated ## Acceptance (high level) - New draft auto-name follows the pattern; default is `<date> <initiator>` per m's brief - Override surface visible in settings (location TBD per Q4) - Tests cover the cascade if multi-level (Q4) - Existing drafts not retroactively renamed ## NOT - Not blocking — the prod-500 fire (m/paliad#154) takes precedence. - Not in this train — this is a fresh feature, separate inventor/coder cycle. - Bump after the current Litigation Builder train (B3+) lands, unless m says sooner.
mAi self-assigned this 2026-05-27 22:38:35 +00:00
mAi commented 2026-07-29 16:09:24 +00:00
Author
Collaborator
Copy Link

This is already built. Both asks shipped in t-paliad-352 and t-paliad-356 (slices 2–5); the issue simply has no comment saying so. No code was written for this pass — there is no commit link because there is nothing to commit, and adding a third generator would have been the wrong move.

1. One engine, not two disagreeing generators

This was the thing worth checking, and the answer is the opposite of what was expected. pkg/nomen composes names from ordered segments (variable, separator, wrapping, and a per-segment missing-value policy). internal/services/namegen.go registers exactly two artifacts:

  • submission_draft_title — date · client · forum · opponent · keyword
  • the submission filename — date · keyword · (case_number)

They do not disagree about how a name is built: both render through the same engine, with the same precedence — user override → firm override → system default. There is no second generator to unify.

2. Customizable in two of the three places; per-template is genuinely absent

  • Per-user — a "Namensschemata" tab in Settings, backed by GET/PUT/DELETE /api/me/name-compositions plus a live POST …/preview. Stored in paliad.users.name_compositions.
  • Firm-wide — /api/admin/name-compositions behind the admin gate, backed by paliad.firm_name_compositions.
  • Per-template — does not exist, and nothing pretends it does. firm_name_compositions is keyed by artifact, not by template, so per-template would be a third scope rather than a row in the existing table.

One line worth having before deciding anything: firm_name_compositions has zero rows after two months. A surface that is built, reachable and never used is a different finding from one that was never wired — it may mean nobody needs a firm default, rather than that it is missing.

3. Date first, and it has held since 2026-06-02

Measured on prod: 33 drafts — 20 date-first, 13 starting Entwurf N. The cut is clean. Every Entwurf N draft was created between 2026-05-25 and 2026-06-01; every draft from 2026-06-02 onwards is date-first. The 13 are legacy rows, not a live gap. One user has a personal override.

The decision that needs you first

The two artifacts disagree about a missing value, and the filename is the one that got it right.

  • Filename: case_number uses Placeholder("TBD"), so a missing docket renders visibly as (TBD).
  • Draft title: all five segments use Omit — a missing client, forum or opponent vanishes along with its separator.

So a project with no opponent renders 2026-05-31 Bayer AG ./. UPC. That looks like a complete, deliberate name — and it looks identical whether the opponent is genuinely not recorded yet or exists and failed to resolve. Nothing distinguishes the two.

The engine already implements Placeholder and Literal, and the filename artifact already uses one. This is a policy choice, not a missing capability. It changes every future draft title, so it is being left exactly as it is until you decide.

Two smaller ones, if you are deciding anyway

"The initiator" has three readings and only one is wired.

Reading Possible today?
the party we act for Wired — the client segment, the root ancestor of the project tree. Note this is not "the party filing": we file only when we act for the proactive party, which project.our_side carries.
the lawyer drafting Not in the name catalog. user.display_name exists in the submission variable bag — a different catalog — so it would need adding.
the case reference In the filename catalog as case_number, not in the title catalog.

All three are reachable, two need a catalog entry, and they produce visibly different names.

Whether the firm-wide surface should carry a default at all, given the zero rows above.

Not closing — only m closes issues.

**This is already built.** Both asks shipped in t-paliad-352 and t-paliad-356 (slices 2–5); the issue simply has no comment saying so. No code was written for this pass — there is no commit link because there is nothing to commit, and adding a third generator would have been the wrong move. ## 1. One engine, not two disagreeing generators This was the thing worth checking, and the answer is the opposite of what was expected. `pkg/nomen` composes names from ordered segments (variable, separator, wrapping, and a per-segment missing-value policy). `internal/services/namegen.go` registers exactly two artifacts: - `submission_draft_title` — `date · client · forum · opponent · keyword` - the submission filename — `date · keyword · (case_number)` They do not disagree about *how* a name is built: both render through the same engine, with the same precedence — **user override → firm override → system default**. There is no second generator to unify. ## 2. Customizable in two of the three places; per-template is genuinely absent - **Per-user** — a "Namensschemata" tab in Settings, backed by `GET/PUT/DELETE /api/me/name-compositions` plus a live `POST …/preview`. Stored in `paliad.users.name_compositions`. - **Firm-wide** — `/api/admin/name-compositions` behind the admin gate, backed by `paliad.firm_name_compositions`. - **Per-template** — does not exist, and nothing pretends it does. `firm_name_compositions` is keyed by *artifact*, not by template, so per-template would be a third scope rather than a row in the existing table. One line worth having before deciding anything: **`firm_name_compositions` has zero rows after two months.** A surface that is built, reachable and never used is a different finding from one that was never wired — it may mean nobody needs a firm default, rather than that it is missing. ## 3. Date first, and it has held since 2026-06-02 Measured on prod: 33 drafts — 20 date-first, 13 starting `Entwurf N`. The cut is clean. Every `Entwurf N` draft was created between 2026-05-25 and 2026-06-01; every draft from 2026-06-02 onwards is date-first. **The 13 are legacy rows, not a live gap.** One user has a personal override. --- # The decision that needs you first **The two artifacts disagree about a missing value, and the filename is the one that got it right.** - Filename: `case_number` uses `Placeholder("TBD")`, so a missing docket renders **visibly** as `(TBD)`. - Draft title: **all five segments use `Omit`** — a missing client, forum or opponent vanishes along with its separator. So a project with no opponent renders `2026-05-31 Bayer AG ./. UPC`. That looks like a complete, deliberate name — and it looks identical whether the opponent is genuinely not recorded yet or exists and failed to resolve. Nothing distinguishes the two. The engine already implements `Placeholder` and `Literal`, and the filename artifact already uses one. **This is a policy choice, not a missing capability.** It changes every future draft title, so it is being left exactly as it is until you decide. ## Two smaller ones, if you are deciding anyway **"The initiator" has three readings and only one is wired.** | Reading | Possible today? | |---|---| | **the party we act for** | **Wired** — the `client` segment, the root ancestor of the project tree. Note this is *not* "the party filing": we file only when we act for the proactive party, which `project.our_side` carries. | | **the lawyer drafting** | Not in the name catalog. `user.display_name` exists in the submission *variable bag* — a different catalog — so it would need adding. | | **the case reference** | In the **filename** catalog as `case_number`, not in the **title** catalog. | All three are reachable, two need a catalog entry, and they produce visibly different names. **Whether the firm-wide surface should carry a default at all**, given the zero rows above. ## Not closing — only m closes issues.
mAi commented 2026-07-30 18:04:50 +00:00
Author
Collaborator
Copy Link

Gemessen, nicht geraten — und das meiste war schon da

Branch mai/hades/issue-155-naming, zwei Commits:
9c3b475 Der Dateiname kann den Initiator benennen
8254cf5 Die Messung: docs/findings-submission-naming-155-2026-07-30.md

Die drei Fragen aus dem Issue, beantwortet aus dem Code

1. Wie viele Stellen erzeugen einen Namen? Ein Trichter, zwei Artefakte.

Drei HTTP-Pfade liefern ein .docx aus. Alle drei rufen submissionDownloadFilename. Es gibt keinen zweiten Generator zu vereinheitlichen.

Der Entwurfstitel ist ein zweiter Name für eine zweite Sache. Beide laufen über dieselbe Engine (pkg/nomen).

2. Was ist der "Initiator"? Schon entschieden — das Identitäts-Trio.

Geliefert mit t-paliad-352: <Datum> <Mandant> ./. <Forum> ./. <Gegner>. Das ist genau das Trio, das du selbst genannt hast ("CLIENTNAME / UPC / OPPONENTNAME").

Gemessener Render, Systemvorgabe, nichts aufgelöst:

2026-07-30 [Mandant] ./. [Forum] ./. [Gegner]
2026-07-30 Bayer AG ./. [Forum] ./. [Opponent]

Eckige Klammern — die Familie spricht schon die Konvention aus #162.

3. Wo gehört "anpassbar" hin? Schon gebaut, auf vier Ebenen.

paliad.firm_name_compositions passt — es ist die Firmen-Ebene einer Kette, die es bereits gibt. Kein zweiter Mechanismus nötig:

Ebene Speicher Oberfläche
pro Dokument composer_meta.name_overrides Dateinamen-Zeile im Entwurf
pro Nutzer users.name_compositions (mig 160) /einstellungen, Token-Feld + Palette + Live-Vorschau
Firma firm_name_compositions (mig 162) /api/admin/name-compositions, Admin-gated
System Code die ausgelieferte Vorgabe

docs/plans/prd-filename-generator-2026-06-01.md ist die Antwort auf dieses Issue. Alle fünf Slices sind gelandet.

Was wirklich gefehlt hat

Der .docx-Dateiname konnte den Initiator gar nicht benennen.

Sein Katalog kannte nur date, keyword, case_number. Die Engine hat das gewünschte Schema schlicht abgelehnt:

filename composition with client/opponent -> Validate err = nomen: unknown variable: client

Eine Firma konnte also die Einstellungsseite öffnen, die genau dafür gebaut wurde, und <Datum> <Mandant> ./. <Gegner> trotzdem nicht auf den Dateinamen legen.

Was der Branch ändert

  • Das Trio steht jetzt im Dateinamen-Katalog, unter denselben Schlüsseln wie im Titel. Ein einheitliches Schema ist eine Aussage über das Vokabular, nicht nur über die Vorgabe: wenn client im Titel etwas anderes hieße als im Dateinamen, könnte eine Konvention nicht über beide tragen.
  • Die Werte kommen aus dem einen Trichter, damit keine Download-Stelle sie falsch oder gar nicht auflöst. Parteien und Verfahrenstyp liegen ohnehin vor; nur der Mandant kostet eine Abfrage.
  • Die Systemvorgabe bleibt unverändert. Kein Dateiname ändert sich.
  • Neu: Artifact.ExtraMissing. Jede Variable, die ein Artefakt anbietet, braucht eine Antwort auf "und wenn sie leer ist" — nicht nur die, die seine Vorgabe zufällig benutzt. Sonst würde ein einkomponierter client still verschwinden: ein Dateiname, der sich perfekt liest und die Partei nicht enthält, nach der er benannt ist.

Markiert wird mit dem TBD dieses Artefakts, nicht mit dem eckigen Label des Titels. Das Label ist sprachabhängig, und eine gespeicherte Komposition darf keine Sprache in die Renders der anderen einfrieren — genau der Fehler, den dieses Artefakt schon einmal hatte ("Az. folgt" im englischen UI).

Die Einstellungsseite brauchte keine Änderung

Die Palette wird aus dem Katalog gebaut, die Reihenfolge kannte alle sechs Variablen schon, und die Vorschau liefert bereits Beispielwerte für Mandant/Forum/Gegner. Die drei Chips erscheinen von selbst. Das Design hat das vorgesehen — es fehlte nur der Katalog-Eintrag.

Eine Frage bleibt für dich

Soll die Vorgabe für den Dateinamen künftig mit dem Initiator führen?

Heute, und auch nach diesem Branch:

2026-07-30 Klageerwiderung (UPC_CFI_1_2026).docx

Möglich, seit das Vokabular existiert:

2026-07-30 Bayer AG ./. Sandoz Klageerwiderung (UPC_CFI_1_2026).docx

Ich habe das nicht entschieden, aus zwei Gründen:

  1. Es benennt jedes erzeugte Dokument ab dem nächsten Deploy um. Vorhandene Dateien behalten ihren Namen, ein Aktenordner trägt danach beide Konventionen.
  2. Es schreibt den Namen des Gegners in einen Dateinamen, der per Mail verschickt wird. Das ist eine Vertraulichkeitsfrage, keine Formatfrage — ein Dateiname reist weiter als der Inhalt: Betreffzeilen, Anhangslisten, Dateiablagen.

Wer es will, kann es heute schon firmenweit unter /admin setzen, ohne Deploy. Das ist das Argument, die Vorgabe zu lassen. Deine Antwort entscheidet, ob das so bleibt.

Nicht gemacht

  • Kompositionen pro Vorlage. Eine deiner vier Optionen; das PRD hat die Projekt-Ebene auf v1.1 verschoben und pro-Vorlage nie aufgenommen. Ohne konkreten Bedarf wäre eine vierte Ebene genau der zweite Mechanismus, den dieses Issue zu Recht vermeidet.
  • Bestehende Entwürfe umbenennen. Die Akzeptanzkriterien des Issues schließen das aus.

Geprüft

Harness auf Port 15489. scripts/ci-test-gate.sh grün (0 known-failing toleriert), make check-gofmt sauber, 426 Frontend-Tests, go vet sauber, -race grün. Branch nicht hinter origin/main. Keine Migration nötig.

Ein Befund am Rande: vier Tests benutzten client bzw. opponent als ihr Beispiel für eine unbekannte Variable — weil sie fehlten. Zwei davon laufen nur gegen die Live-DB und wären ohne den vollen Gate nicht aufgefallen. Sie benutzen jetzt ein Unsinnswort, und ein positiver Fall prüft, dass das Trio gültig ist.

## Gemessen, nicht geraten — und das meiste war schon da Branch `mai/hades/issue-155-naming`, zwei Commits: | | | |---|---| | [9c3b475](https://mgit.msbls.de/m/paliad/commit/9c3b475) | Der Dateiname kann den Initiator benennen | | [8254cf5](https://mgit.msbls.de/m/paliad/commit/8254cf5) | Die Messung: `docs/findings-submission-naming-155-2026-07-30.md` | --- ## Die drei Fragen aus dem Issue, beantwortet aus dem Code **1. Wie viele Stellen erzeugen einen Namen? Ein Trichter, zwei Artefakte.** Drei HTTP-Pfade liefern ein `.docx` aus. Alle drei rufen `submissionDownloadFilename`. Es gibt keinen zweiten Generator zu vereinheitlichen. Der **Entwurfstitel** ist ein zweiter Name für eine zweite Sache. Beide laufen über dieselbe Engine (`pkg/nomen`). **2. Was ist der "Initiator"? Schon entschieden — das Identitäts-Trio.** Geliefert mit t-paliad-352: `<Datum> <Mandant> ./. <Forum> ./. <Gegner>`. Das ist genau das Trio, das du selbst genannt hast ("CLIENTNAME / UPC / OPPONENTNAME"). Gemessener Render, Systemvorgabe, nichts aufgelöst: ``` 2026-07-30 [Mandant] ./. [Forum] ./. [Gegner] 2026-07-30 Bayer AG ./. [Forum] ./. [Opponent] ``` Eckige Klammern — die Familie spricht schon die Konvention aus #162. **3. Wo gehört "anpassbar" hin? Schon gebaut, auf vier Ebenen.** `paliad.firm_name_compositions` passt — es ist die Firmen-Ebene einer Kette, die es bereits gibt. Kein zweiter Mechanismus nötig: | Ebene | Speicher | Oberfläche | |---|---|---| | pro Dokument | `composer_meta.name_overrides` | Dateinamen-Zeile im Entwurf | | pro Nutzer | `users.name_compositions` (mig 160) | `/einstellungen`, Token-Feld + Palette + Live-Vorschau | | Firma | `firm_name_compositions` (mig 162) | `/api/admin/name-compositions`, Admin-gated | | System | Code | die ausgelieferte Vorgabe | `docs/plans/prd-filename-generator-2026-06-01.md` ist die Antwort auf dieses Issue. Alle fünf Slices sind gelandet. --- ## Was wirklich gefehlt hat **Der `.docx`-Dateiname konnte den Initiator gar nicht benennen.** Sein Katalog kannte nur `date`, `keyword`, `case_number`. Die Engine hat das gewünschte Schema schlicht abgelehnt: ``` filename composition with client/opponent -> Validate err = nomen: unknown variable: client ``` Eine Firma konnte also die Einstellungsseite öffnen, die genau dafür gebaut wurde, und `<Datum> <Mandant> ./. <Gegner>` trotzdem nicht auf den Dateinamen legen. ### Was der Branch ändert - Das Trio steht jetzt im Dateinamen-Katalog, **unter denselben Schlüsseln wie im Titel**. Ein einheitliches Schema ist eine Aussage über das Vokabular, nicht nur über die Vorgabe: wenn `client` im Titel etwas anderes hieße als im Dateinamen, könnte eine Konvention nicht über beide tragen. - Die Werte kommen aus dem einen Trichter, damit keine Download-Stelle sie falsch oder gar nicht auflöst. Parteien und Verfahrenstyp liegen ohnehin vor; nur der Mandant kostet eine Abfrage. - **Die Systemvorgabe bleibt unverändert.** Kein Dateiname ändert sich. - Neu: `Artifact.ExtraMissing`. Jede Variable, die ein Artefakt **anbietet**, braucht eine Antwort auf "und wenn sie leer ist" — nicht nur die, die seine Vorgabe zufällig benutzt. Sonst würde ein einkomponierter `client` still verschwinden: ein Dateiname, der sich perfekt liest und die Partei nicht enthält, nach der er benannt ist. Markiert wird mit dem `TBD` dieses Artefakts, nicht mit dem eckigen Label des Titels. Das Label ist sprachabhängig, und eine gespeicherte Komposition darf keine Sprache in die Renders der anderen einfrieren — genau der Fehler, den dieses Artefakt schon einmal hatte ("Az. folgt" im englischen UI). ### Die Einstellungsseite brauchte keine Änderung Die Palette wird aus dem Katalog gebaut, die Reihenfolge kannte alle sechs Variablen schon, und die Vorschau liefert bereits Beispielwerte für Mandant/Forum/Gegner. Die drei Chips erscheinen von selbst. Das Design hat das vorgesehen — es fehlte nur der Katalog-Eintrag. --- ## Eine Frage bleibt für dich **Soll die Vorgabe für den Dateinamen künftig mit dem Initiator führen?** Heute, und auch nach diesem Branch: ``` 2026-07-30 Klageerwiderung (UPC_CFI_1_2026).docx ``` Möglich, seit das Vokabular existiert: ``` 2026-07-30 Bayer AG ./. Sandoz Klageerwiderung (UPC_CFI_1_2026).docx ``` Ich habe das nicht entschieden, aus zwei Gründen: 1. Es benennt **jedes** erzeugte Dokument ab dem nächsten Deploy um. Vorhandene Dateien behalten ihren Namen, ein Aktenordner trägt danach beide Konventionen. 2. Es schreibt den **Namen des Gegners in einen Dateinamen, der per Mail verschickt wird**. Das ist eine Vertraulichkeitsfrage, keine Formatfrage — ein Dateiname reist weiter als der Inhalt: Betreffzeilen, Anhangslisten, Dateiablagen. Wer es will, kann es heute schon firmenweit unter `/admin` setzen, ohne Deploy. Das ist das Argument, die Vorgabe zu lassen. Deine Antwort entscheidet, ob das so bleibt. --- ## Nicht gemacht - **Kompositionen pro Vorlage.** Eine deiner vier Optionen; das PRD hat die Projekt-Ebene auf v1.1 verschoben und pro-Vorlage nie aufgenommen. Ohne konkreten Bedarf wäre eine vierte Ebene genau der zweite Mechanismus, den dieses Issue zu Recht vermeidet. - **Bestehende Entwürfe umbenennen.** Die Akzeptanzkriterien des Issues schließen das aus. ## Geprüft Harness auf Port 15489. `scripts/ci-test-gate.sh` grün (0 known-failing toleriert), `make check-gofmt` sauber, 426 Frontend-Tests, `go vet` sauber, `-race` grün. Branch nicht hinter `origin/main`. Keine Migration nötig. **Ein Befund am Rande:** vier Tests benutzten `client` bzw. `opponent` **als** ihr Beispiel für eine unbekannte Variable — weil sie fehlten. Zwei davon laufen nur gegen die Live-DB und wären ohne den vollen Gate nicht aufgefallen. Sie benutzen jetzt ein Unsinnswort, und ein positiver Fall prüft, dass das Trio gültig ist.
mAi commented 2026-07-31 00:03:14 +00:00
Author
Collaborator
Copy Link

m's Antwort (2026-07-30): Vorgabe bleibt, Firmen wählen es selbst

Der Standard-Dateiname ändert sich nicht. Wer den Initiator auf der Datei will, stellt ihn firmenweit unter /admin ein.

m's Gründe waren die beiden aus der Frage: der Name des Gegners reist über Betreffzeilen und Anhangslisten, und ein Aktenordner trüge sonst zwei Konventionen nebeneinander.

Damit ist der gebaute Teil die ganze Lieferung, nicht die Hälfte. Vorher bot die Einstellungsseite eine Anpassung an, die die Engine ablehnte — Validate gab nomen: unknown variable: client zurück, eine Firma konnte den Initiator also konfigurieren und trotzdem nicht bekommen. Das Opt-in funktioniert jetzt, und kein vorhandener Dateiname ändert sich.

Erstes Branch merged nach main: bf3dd6f.

Nachtrag für die nächste Person in pkg/nomen

Ein Negativ-Test, dessen Fixture "etwas, das es nicht gibt" ist, hört auf zu testen, sobald es das gibt — und zwar still.

Vier Tests hier benutzten client bzw. opponent als ihr Beispiel für eine unbekannte Variable, gerade weil diese Schlüssel im Dateinamen-Katalog fehlten. Als die Schlüssel dazukamen, prüften alle vier nichts mehr: die Behauptung lautet "das wird abgelehnt", und ein jetzt gültiger Wert wird eben nicht abgelehnt.

Zwei der vier laufen nur gegen eine Live-Datenbank. go test -short blieb grün; nur der volle Gate hat es gemeldet.

Das Fixture heisst jetzt unknownNameVar (internal/services/name_composition_spec_test.go) und trägt die Regel: es muss ein Unsinnswort bleiben, nie eine echte Variable, die zufällig gerade in einem Katalog fehlt. Wer ein Vokabular erweitert, sucht die Tests nach den hinzugefügten Wörtern ab.

Folge-Commit: mai/hades/issue-155-followup — nur Tests und Doku, keine Verhaltensänderung. Gate grün (0 known-failing toleriert), check-gofmt sauber, 441 Frontend-Tests.

Die vollständige Messung samt m's Entscheidung steht in docs/findings-submission-naming-155-2026-07-30.md.

## m's Antwort (2026-07-30): **Vorgabe bleibt, Firmen wählen es selbst** Der Standard-Dateiname ändert sich nicht. Wer den Initiator auf der Datei will, stellt ihn firmenweit unter `/admin` ein. m's Gründe waren die beiden aus der Frage: der Name des Gegners reist über Betreffzeilen und Anhangslisten, und ein Aktenordner trüge sonst zwei Konventionen nebeneinander. **Damit ist der gebaute Teil die ganze Lieferung, nicht die Hälfte.** Vorher bot die Einstellungsseite eine Anpassung an, die die Engine ablehnte — `Validate` gab `nomen: unknown variable: client` zurück, eine Firma konnte den Initiator also konfigurieren und trotzdem nicht bekommen. Das Opt-in funktioniert jetzt, und kein vorhandener Dateiname ändert sich. Erstes Branch merged nach main: `bf3dd6f`. --- ## Nachtrag für die nächste Person in `pkg/nomen` **Ein Negativ-Test, dessen Fixture "etwas, das es nicht gibt" ist, hört auf zu testen, sobald es das gibt — und zwar still.** Vier Tests hier benutzten `client` bzw. `opponent` **als** ihr Beispiel für eine unbekannte Variable, gerade weil diese Schlüssel im Dateinamen-Katalog fehlten. Als die Schlüssel dazukamen, prüften alle vier nichts mehr: die Behauptung lautet "das wird abgelehnt", und ein jetzt gültiger Wert wird eben nicht abgelehnt. Zwei der vier laufen nur gegen eine Live-Datenbank. `go test -short` blieb grün; nur der volle Gate hat es gemeldet. Das Fixture heisst jetzt `unknownNameVar` (`internal/services/name_composition_spec_test.go`) und trägt die Regel: es muss ein Unsinnswort bleiben, nie eine echte Variable, die zufällig gerade in einem Katalog fehlt. Wer ein Vokabular erweitert, sucht die Tests nach den hinzugefügten Wörtern ab. Folge-Commit: [`mai/hades/issue-155-followup`](https://mgit.msbls.de/m/paliad/commits/branch/mai/hades/issue-155-followup) — nur Tests und Doku, keine Verhaltensänderung. Gate grün (0 known-failing toleriert), `check-gofmt` sauber, 441 Frontend-Tests. Die vollständige Messung samt m's Entscheidung steht in `docs/findings-submission-naming-155-2026-07-30.md`.
mAi added the
done
 label 2026-07-31 00:03:18 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
done
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees mAi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#155
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?