Levandor

Partner-facing release TjK — document structure

9 min read

The partner-facing release Tesztelési jegyzőkönyv (TjK) is a hand-authored .docx — one per partner per release — with one Heading2 section per shipped ticket. This note captures its reverse-engineered structure so a new one can be authored or appended-to programmatically. Reverse-engineered 2026-08-11 from the 2026-08-10 Raiffeisen … Release 1.9.11.100.docx draft (raiffeisen-1.9.11.100).

This shape is now the standard for every partner (decision 2026-08-11)

Historically each partner had its own TjK format. As of 2026-08-11 all partners standardize on the release-doc shape described here, and the newest TjK in ~/Downloads is the authoritative current format — that is where the live Google-Docs export lands, so it beats any ticket attachment. Match TjK files by name (Tesztelési jegyzőkönyv / Tesztjegyzokonyv); Downloads holds unrelated documents of near-identical size.

The legacy shapes survive only as priorShape in partners.json, to tell a customer their format changed:

ShapeProductionToolPrior users
release-doc — this note, the targetBevezetés + a Heading2 section per ticketappend_release_sections.pyRaiffeisen (ASSRAFIPI-133/130/127/123)
sablon (legacy)one dev ticket, 19 <…> placeholder substitutionrender_tjk.py (tesztjegyzokonyv-generation-flow)NÚSZ (ASSNUSZ-116)
spreadsheet (legacy).xlsx test-case matrixnoneMKB through 1.9.11.63, docx/PDF from .65

fileStem stays per partner — customers file documents by name. Raiffeisen Raiffeisen - Tesztelési jegyzőkönyv - VUER OSS CSS - Release 1.9.11.<NN>, NÚSZ Tesztelési jegyzőkönyv - NÚSZ - 1.9.11.<NN>.

The two renderers are not two views of one thing — they build different production artifacts. Pushing a release-doc through render_tjk.py produces nonsense, and vice versa. /fk-tjk detects the shape and routes; only bypass it if you already know the partner’s shape. A partner’s priorShape in partners.json stays null until someone verifies it against that partner’s newest attachment — null means unknown, not none.

Rebasing one partner's TjK onto another leaks ticket ids

The table of contents is a static field: it keeps the previous document’s heading text until someone refreshes it. Rebase a Raiffeisen TjK into a NÚSZ one and the TOC still reads ASSRAFIPI-124, SLARAFIPI-59 — another customer’s ticket ids inside this customer’s document, invisible in the body. append_release_sections.py newdoc clears the cached entries and refuses to write if any ASS…/SLA…/CR…/BUG… id from the source survives.

For Agents

  • Just run /fk-tjk <partner> — it starts from a historian subagent synthesis, resolves the partner’s own release train, takes the base from ~/Downloads, drafts, and writes a tester runbook. Do not carry a release number in from conversation; trains are per-partner (Raiffeisen .100 while NÚSZ was on .48).
  • This note is the single source for the document shape, including the verbatim Hungarian boilerplate. The former on-disk spec docs/tjk-raiffeisen-document-structure.md was folded in here and retired — knowledge lives in the vault, not in the facekom working directory. Only executable config stays on disk: /Users/levander/coding/facekom/.claude/commands/fk-tjk.md and .claude/scripts/tjk/*.py + partners.json.
  • Renderers: .claude/scripts/tjk/append_release_sections.py (release-doc, JSON-driven) and render_tjk.py (sablon). Both take --selfcheck, self-verify their output, and never mutate their input.
  • Hard rule: section headings use the partner-side ticket id (ASSRAFIPI-/SLARAFIPI-/CRRAFIPI-). FKITDEV-<n> never appears in a customer document — the tool asserts this.
  • Hard rule: never invent evidence. Leave the block empty and flag it if the test has not run.

File naming and destination

<Partner> - Tesztelési jegyzőkönyv - VUER OSS CSS - Release 1.9.11.<NN>.docx

Attached to the partner release ticket (ASS<PARTNER>-<n>) as .pdf with the same stem. Verified present on ASSRAFIPI-133 (.99), -130 (.98), -127 (.96), -123 (.95). Download/lookup recipe: youtrack-tesztjegyzokonyv-attachment-recipe.

Document skeleton

#StyleContent
1TitleTesztelési jegyzőkönyv — fixed
2Normal<Partner> - VUER OSS / CSS
3SubtitleRelease 1.9.11.<NN>
4…NormalAuto TOC field (TOC \h \u \z \t "Heading 1,1,…,Heading 6,6,") built from Heading 1–6
—Heading2Bevezetés
—Heading2one per shipped ticket, repeated

The TOC is a static Word field — appending sections does NOT update it

Programmatic append leaves the table of contents describing the previous release’s sections. Open in Word / Google Docs and refresh the TOC before exporting the PDF. There is no way around this from the zip side.

Per-ticket section shape

Heading2   <PARTNER-TICKET-ID> - <ticket title>     ← ASSRAFIPI- / SLARAFIPI- / CRRAFIPI-, never FKITDEV-
Heading3   Fejlesztés
Normal     what changed and why, 1–4 paragraphs, plain Hungarian
Heading3   Teszteset
Normal     how it was tested
…          evidence block (see below)
Heading4   Elvárt működés                           ← OPTIONAL
Normal     the expected behaviour, one paragraph
  • Section order follows the release ticket’s changelog order, not ticket number.
  • Elvárt működés is included where the change has an observable behavioural contract; skipped for pure log/report tweaks.
  • Numbered sub-cases inside one Teszteset are plain Normal paragraphs starting 1. , 2. , 3. — not a Word list.

Example mapping for 1.9.11.100: ASSRAFIPI-119 ← FKITDEV-8827, SLARAFIPI-60 ← FKITDEV-8787.

Evidence blocks — three accepted forms

1. Monospace text dump (API responses, test output, CSV/log excerpts) — strongest form. One Normal paragraph per line, with these run + paragraph-mark properties:

<w:rFonts w:ascii="Roboto Mono" w:cs="Roboto Mono" w:eastAsia="Roboto Mono" w:hAnsi="Roboto Mono"/>
<w:color w:val="37474f"/><w:sz w:val="21"/><w:szCs w:val="21"/>

Introduce each dump with a short label paragraph (Document recognition V3, MRZ detection, Az exportált állomány tartalma:).

2. Inline screenshots — <w:drawing> in a Normal paragraph, embedded as word/media/imageN.png. For visual proof (admin UI, log viewer). Introduce with e.g. Csatolom a képeket a logból.

3. Narrative — a sentence asserting the case passed inside a broader flow, e.g. “Self service folyamat tesztelésnél látszik, hogy a folyamat sikeresen, hiba nélkül végig futott.” Weakest form; acceptable only when the change is observed as a side effect of an end-to-end run.

Bullets anywhere in the document use numId=1, ilvl=0, ind left=720 hanging=360.

Bevezetés block

Fixed order, all Normal unless noted:

  1. Eme jegyzőkönyv a VUER OSS és CSS rendszerek 1.9.11.<NN> Release keretén belül történt fejlesztések teszteléséről szól. A tesztelés localhost-on történt, mock-olt adatokkal.
  2. blank
  3. A tesztelés az alábbi eszközökön és böngészőkben történt:
  4. Mobilt érintő részek → bullets: iOS version, phone model, browsers
  5. Böngészőben tesztelhető részek → bullets: OS, browser + build string
  6. blank
  7. A tesztelés az alábbi verzión történt: → bullets VUER CSS - <partner>-1.9.11.<NN>, VUER OSS - <partner>-1.9.11.<NN>
  8. blank
  9. A tesztelés ideje: → <YYYY.MM.DD.>
  10. blank ×2
  11. Closing recommendation paragraph — the pass/fail statement (verbatim text below)

The closing recommendation paragraph — verbatim

Reproduce it exactly as below, swapping only the partner name. <Partner> appears twice and both occurrences get replaced:

A fejlesztői környezetben végrehajtott tesztesetek alapján a fejlesztői, tesztek sikeresen zárhatóak. A szállító által biztosított <Partner> fejlesztés a jelen tesztelési jegyzőkönyv eredményei szerint telepítésre ajánlott a <Partner> PROD környezetbe. Más szállítói, fejlesztői tesztre nincs szükség és lehetőség, az elvégzett fejlesztői tesztek lefedik a megvalósítható(“Feasible and Practical Testing”) eseteket. A fejlesztői környezetben végrehajtott tesztek mind sikeresek voltak, nem volt hibás eredmény.

Keep the quirks — they are in the real document

  • Double space before A fejlesztői környezetben végrehajtott tesztek mind sikeresek voltak (after eseteket.). Do not normalise it.
  • No space in megvalósítható("Feasible and Practical Testing").
  • The comma in a fejlesztői, tesztek sikeresen zárhatóak.

These are the customer’s own wording. “Fixing” them makes the paragraph diverge from every previously delivered TjK.

This paragraph IS the pass/fail statement

Its last sentence asserts “A fejlesztői környezetben végrehajtott tesztek mind sikeresek voltak, nem volt hibás eredmény.”, and the paragraph declares the delivery telepítésre ajánlott (“recommended for installation”) into the partner’s PROD.

If any test case failed, this paragraph MUST be rewritten. Do not ship the “mind sikeresek voltak” wording over a red result — it is a formal statement to the bank, not boilerplate. newdoc rebases the text unchanged, so nothing in the tooling will catch a red result for you.

Programmatic append

Working script: /Users/levander/coding/facekom/.claude/scripts/tjk/append_release_sections.py (the earlier append_sections_example.py name is gone). Two modes — newdoc to rebase a base document onto a new partner+release, then plain append to add this release’s sections from JSON. Driven by [[tesztjegyzokonyv-generation-flow#phase-5—render-the-two-step-build|/fk-tjk Phase 5]].

Method:

  1. Build <w:p> elements with the styles above.
  2. Splice them in immediately before <w:sectPr> in word/document.xml.
  3. Rewrite the zip entry-for-entry (do not let a zip library re-compress or reorder — a .docx is order-sensitive in practice and Word is unforgiving).
  4. Self-check the result: valid zip, parseable document.xml, every section heading present, no section duplicated (a ticket id already in the draft is an error, not an append), and no FKITDEV- in any heading. --selfcheck alone verifies the tooling without touching a document. The input draft is never mutated — output is always a new file.

The script is JSON-driven — you should not need to write python. Block kinds inside a section’s fejlesztes / teszteset / elvartMukodes arrays:

Block kindRenders as
pone Normal paragraph (\n becomes a real <w:br/>)
bulletslist items (numId=1, ilvl=0, ind left=720 hanging=360)
codeone monospace paragraph per line (Roboto Mono, color 37474f, sz 21) + trailing blank
evidencekeeps the literal <képernyőképek, tesztelés eredményének bizonyítása> cue for the tester

On error, fix the JSON and re-run — never hand-edit the .docx: a hand edit is invisible to the self-checks and is lost on the next run. Same “swap exactly one entry, verify afterwards” discipline as render_tjk.py in tesztjegyzokonyv-generation-flow. A worked JSON-to-prose example: raiffeisen-1.9.11.100-tjk-sections.

Styles / fonts present

Title, Subtitle, Heading1–Heading6, Normal, TableNormal. Embedded fonts: Roboto and Roboto Mono (regular/bold/italic/boldItalic each). The document is a Google Docs export — all w:rsid* attributes are 00000000 and w14:paraId values are sequential. Useful tell: if rsids are non-zero you are looking at a real-Word document and a different lineage.

Authoring a new one

  1. Copy the most recent partner TjK; bump Release 1.9.11.<NN> in the Subtitle and in Bevezetés ¶1.
  2. Update the device / browser / version / date block. Keep the closing recommendation verbatim (unless a case failed).
  3. Delete the previous release’s ticket sections.
  4. Add one section per ticket in release changelog order, using the partner-side ticket id.
  5. Paste evidence. Never invent it.
  6. Refresh the TOC, export to PDF, attach to the partner release ticket.

Gotchas observed in the 1.9.11.100 draft

Real defects found in the 2026-08-10 Raiffeisen draft — check for these

  • Body paragraphs mis-styled as Heading3/Heading2 inside SLARAFIPI-59 - Girinfo feldolgozás issue → they pollute the TOC. Set them to Normal.
  • Two empty Heading2 paragraphs before that section → delete.
  • SLARAFIPI-62 - Logikai adategyezés dr issue javítása — both subsections empty.
  • issuu typo in the SLARAFIPI-59 heading (should be issue).

The first two are the generalisable class: a mis-styled body paragraph is invisible in the body but loud in the TOC, so proof-read the refreshed TOC, not just the pages.

Graph View

Backlinks