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

Submissions demo template: variables missing — investigate t-paliad-241 + extend #84

New Issue
Open
opened 2026-05-25 11:23:39 +00:00 by mAi · 0 comments
mAi commented 2026-05-25 11:23:39 +00:00
Collaborator
Copy Link

m's report (2026-05-25 13:12)

the document generator still has no variables in the template. Can we try that out? Can you do that? Add all the variables so we can try it out...

Context — what should already be there

t-paliad-241 (commit 1f7de99, completed via ritchie 2026-05-22) was supposed to ship a demo de.inf.lg.erwidg.docx template with the full {{...}} placeholder set covering every variable SubmissionVarsService resolves. m is reporting that on paliad.de, opening the Submissions editor still shows no variables.

Four possible causes — investigate in order:

  1. Template not actually deployed — the .docx file may not have been pushed to m/mWorkRepo at the expected path, OR the paliad.de container hasn't picked up a fresh fileRegistry binary, OR the Gitea proxy auth is failing for the per-firm template path.
  2. Template fallback chain regressed — the lookup may be silently falling back to the universal HL Patents Style .dotm (which has no placeholders), so the editor enumerates zero variables.
  3. fileRegistry wiring mismatch — internal/handlers/files.go registry key may not match the submission_code the editor passes in.
  4. Variables ARE in the file but the merge engine isn't enumerating them into the sidebar — possible if the .docx has the placeholders inside split runs (Word fragmentation) and the parser doesn't reassemble runs before scanning.

What to do (fixer)

Phase 1 — Diagnose

  1. Read commit 1f7de99 to see exactly what ritchie shipped. Check the .docx bytes in m/mWorkRepo (likely path: 6 - material/Templates/Word/Paliad/HLC/de.inf.lg.erwidg.docx — verify from the commit).
  2. Verify the file exists on Gitea via the same proxy path paliad.de uses at runtime.
  3. On paliad.de, open a CCR or inf project → Schriftsätze → Bearbeiten on de.inf.lg.erwidg. Inspect the editor sidebar (DOM). Variables present? None?
  4. If none: check the network call paliad.de makes to resolve the template — what URL, what status, what bytes.
  5. If the .docx loads but the sidebar is empty: extract the .docx (it's a zip), open word/document.xml, search for {{. Are the placeholders there as contiguous text or split across <w:r> runs?
  6. If they're split across runs: this is the Word run-fragmentation problem the original design flagged. Library options: lukasjarosch/go-docx handles it; the current code may not.

Phase 2 — Fix

The fix depends on which cause root applies:

  • Cause 1/2/3 (template not delivered or registry mismatch): correct the path / wiring; verify locally then on paliad.de.
  • Cause 4 (run fragmentation): switch the variable-extraction step to a run-aware parser. If lukasjarosch/go-docx is already a dep (per the original design proposal), use it for enumeration. If not, add it (this is a meaningful dependency — flag for m via head before adding) OR write a minimal run-stitching pass before regex scan.

Phase 3 — Extend

After the demo template is verifiably showing variables in the editor:

  • Audit SubmissionVarsService to confirm the FULL variable list (every key it produces). m's ask: "Add all the variables so we can try it out".
  • Author or extend the demo template so EVERY variable the service resolves is exercised somewhere in the document body (use a hidden boilerplate appendix if natural placement isn't obvious for low-traffic keys).
  • Re-commit to m/mWorkRepo at the same path. Verify rendered on paliad.de.

Files most likely touched

  • internal/handlers/files.go — fileRegistry / template lookup
  • internal/services/submission_render.go or submission_vars.go — variable extraction
  • internal/services/submission_templates.go — template fallback chain
  • frontend/src/submission-draft.tsx + client — sidebar render of variable list (if frontend is the bug surface)
  • m/mWorkRepo (separate repo): the .docx bytes

Hard rules

  • Don't modify the existing universal HL Patents Style .dotm — only the per-submission de.inf.lg.erwidg.docx.
  • If a new Go dependency is needed (e.g. lukasjarosch/go-docx), STOP and ask the head before adding it. Head will escalate to m.
  • go build ./... && go test ./internal/... && cd frontend && bun run build clean.
  • Branch: mai/<worker>/demo-template-variables-debug.

Out of scope

  • Authoring real lawyer-reviewed Klageerwiderung content (m's content responsibility).
  • Per-submission templates for codes other than de.inf.lg.erwidg — one is enough to demonstrate the system.
  • Conditional sections / toggleable passages (Slice C territory).

Reporting

mai report completed with branch + SHAs + the diagnosed root cause (Phases 1+2 findings) + the final variable inventory exercised by the template + verification path on paliad.de (open project → Schriftsätze → Bearbeiten on de.inf.lg.erwidg → sidebar lists every variable + preview shows them substituted with project data).

## m's report (2026-05-25 13:12) > the document generator still has no variables in the template. Can we try that out? Can you do that? Add all the variables so we can try it out... ## Context — what should already be there t-paliad-241 (commit `1f7de99`, completed via ritchie 2026-05-22) was supposed to ship a demo `de.inf.lg.erwidg.docx` template with the full `{{...}}` placeholder set covering every variable `SubmissionVarsService` resolves. m is reporting that on paliad.de, opening the Submissions editor still shows no variables. Four possible causes — investigate in order: 1. **Template not actually deployed** — the .docx file may not have been pushed to `m/mWorkRepo` at the expected path, OR the paliad.de container hasn't picked up a fresh fileRegistry binary, OR the Gitea proxy auth is failing for the per-firm template path. 2. **Template fallback chain regressed** — the lookup may be silently falling back to the universal HL Patents Style .dotm (which has no placeholders), so the editor enumerates zero variables. 3. **fileRegistry wiring mismatch** — `internal/handlers/files.go` registry key may not match the submission_code the editor passes in. 4. **Variables ARE in the file but the merge engine isn't enumerating them into the sidebar** — possible if the .docx has the placeholders inside split runs (Word fragmentation) and the parser doesn't reassemble runs before scanning. ## What to do (fixer) ### Phase 1 — Diagnose 1. Read commit `1f7de99` to see exactly what ritchie shipped. Check the .docx bytes in m/mWorkRepo (likely path: `6 - material/Templates/Word/Paliad/HLC/de.inf.lg.erwidg.docx` — verify from the commit). 2. Verify the file exists on Gitea via the same proxy path paliad.de uses at runtime. 3. On paliad.de, open a CCR or inf project → Schriftsätze → Bearbeiten on `de.inf.lg.erwidg`. Inspect the editor sidebar (DOM). Variables present? None? 4. If none: check the network call paliad.de makes to resolve the template — what URL, what status, what bytes. 5. If the .docx loads but the sidebar is empty: extract the .docx (it's a zip), open `word/document.xml`, search for `{{`. Are the placeholders there as contiguous text or split across `<w:r>` runs? 6. If they're split across runs: this is the Word run-fragmentation problem the original design flagged. Library options: `lukasjarosch/go-docx` handles it; the current code may not. ### Phase 2 — Fix The fix depends on which cause root applies: - **Cause 1/2/3** (template not delivered or registry mismatch): correct the path / wiring; verify locally then on paliad.de. - **Cause 4** (run fragmentation): switch the variable-extraction step to a run-aware parser. If `lukasjarosch/go-docx` is already a dep (per the original design proposal), use it for enumeration. If not, add it (this is a meaningful dependency — flag for m via head before adding) OR write a minimal run-stitching pass before regex scan. ### Phase 3 — Extend After the demo template is verifiably showing variables in the editor: - Audit `SubmissionVarsService` to confirm the FULL variable list (every key it produces). m's ask: "Add all the variables so we can try it out". - Author or extend the demo template so EVERY variable the service resolves is exercised somewhere in the document body (use a hidden boilerplate appendix if natural placement isn't obvious for low-traffic keys). - Re-commit to m/mWorkRepo at the same path. Verify rendered on paliad.de. ## Files most likely touched - `internal/handlers/files.go` — fileRegistry / template lookup - `internal/services/submission_render.go` or `submission_vars.go` — variable extraction - `internal/services/submission_templates.go` — template fallback chain - `frontend/src/submission-draft.tsx` + client — sidebar render of variable list (if frontend is the bug surface) - m/mWorkRepo (separate repo): the .docx bytes ## Hard rules - Don't modify the existing universal HL Patents Style .dotm — only the per-submission `de.inf.lg.erwidg.docx`. - If a new Go dependency is needed (e.g. `lukasjarosch/go-docx`), STOP and ask the head before adding it. Head will escalate to m. - `go build ./... && go test ./internal/... && cd frontend && bun run build` clean. - Branch: `mai/<worker>/demo-template-variables-debug`. ## Out of scope - Authoring real lawyer-reviewed Klageerwiderung content (m's content responsibility). - Per-submission templates for codes other than `de.inf.lg.erwidg` — one is enough to demonstrate the system. - Conditional sections / toggleable passages (Slice C territory). ## Reporting `mai report completed` with branch + SHAs + the diagnosed root cause (Phases 1+2 findings) + the final variable inventory exercised by the template + verification path on paliad.de (open project → Schriftsätze → Bearbeiten on `de.inf.lg.erwidg` → sidebar lists every variable + preview shows them substituted with project data).
mAi self-assigned this 2026-05-25 11:23:39 +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
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#84
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?