StefanandClaude Sonnet 5
ecc74cf3c6
Playwright Tests / test (push) Canceled after 0s
Lets a back-office user correct/define which invoice line belongs to which "set" and how deep it is nested, instead of relying only on the implicit "everything after a Set header until the next Set" grouping fds__prepInvoice derives. Sets may contain sets; every change applies immediately to the cached draft session and is reflected in the editor and PDF (ADR 0006/0008). Backend: - InvoiceSetStructure: pure parent-link forest (assign, change level, create, place/move-sibling, depth-first linearise + level recompute). - InvoiceDraftSetStructureDeltas: new inv/dpatch targets set.assign, set.level, set.create, set.move. - InvoiceSetPricing.Build is now order-preserving and nesting-aware (governed by the nearest converted ancestor); the set-item switch sums a header's transitive descendants so nested conversions never double-count. - FuchsPdf indents nested set members per level, mirroring the editor. Frontend: - New fis.inv_sets.js: "Set-Struktur bearbeiten" dialog — per-block table of all lines with drag & drop reorder (before/after/into), ▲▼ order and ◀▶ level buttons, fold/unfold per set (view-only), and a create bar for new Set/Text lines. Posts one delta per action; the dialog is a pure view of the server state (ADR 0006). - _Layout.cshtml / fis_main.js: cache-bust the dynamically imported per-module bundles (web/fis.<mdl>.<locale>.js/.css) with an asset version derived from the newest bundle write time, so a gulp rebuild is picked up without a stale cached module. Docs: ADR 0016, live-draft-editing concept, INVOICE_SET_PRICING.md, USER_GUIDE.md, ARCHITECTURE.md updated. Tests: InvoiceSetStructureTests (new) + additions to InvoiceDraftServiceTests/InvoiceSetPricingTests. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Concepts
This folder holds living design write-ups of how a subsystem currently
works: its moving parts, data flow, and how they fit together. Unlike
../Decisions, concept docs are not immutable
— keep them in sync with the implementation as it evolves.
What belongs here
"How does the notification pipeline work end to end" is a concept doc. "Why did we choose SignalR over polling for it" is a decision. A single feature area typically has one concept doc and may reference several decisions that shaped it.
File naming
kebab-case-topic.md (no numbering — concepts aren't sequential events).
Required YAML frontmatter
---
status: Active # Active | Deprecated
lastUpdated: 2026-07-03
applyTo: # glob(s) — files/areas this concept describes
- "Fuchs/Notifications/**"
relatedDecisions: # filenames in ../Decisions this concept implements
- "0001-domain-events-and-notification-triggers.md"
---
Agents must scan the YAML frontmatter of every file in this folder first
and only read the full body of concepts whose applyTo glob matches the
files they're about to touch, or whose subject is otherwise clearly relevant.
Body template
# Topic
## Summary
One paragraph: what this subsystem does and why it exists.
## How it works
The mechanics — components, data flow, sequencing. Diagrams (ASCII/mermaid)
welcome where they clarify.
## Key files
Bullet list of the primary files/classes involved.
## Related decisions
Links to the ADRs in `../Decisions` that shaped this design.
Rules
- Keep concepts current. When you materially change how a documented subsystem works, update its concept doc in the same change — don't let it drift from the code.
- Create a concept doc for new non-trivial subsystems. If you build something a future agent would need a paragraph of context to safely modify, write that paragraph here instead of making them re-derive it from the diff.
- Concepts describe current behavior. If something changes, edit the doc in place — don't append a changelog inside it (git history is the changelog).