Files
Fuchs_Intranet/Fuchs/Docs/Decisions
StefanandClaude Sonnet 5 406c6f2860 Fix invoice-image code-review findings: aspect ratio, whitelist config, stale refs
- MigraDocExtensions: fix a bug where capping an oversized explicit
  width+height image re-derived the other dimension from the image's
  native pixel ratio instead of scaling both sides uniformly, silently
  distorting a deliberately non-native-ratio (e.g. stretched) image.
- InvoiceService: derive the mfr-portal image whitelist prefix from the
  existing Fds:MFR_host config setting (via MFRClientConfig.RestRoot)
  instead of a second hardcoded literal, so it can't drift from the
  actual configured host; parse <img> sources with HtmlAgilityPack
  (already used by the PDF's own HTML converter) instead of a regex, so
  a decoy attribute like data-src can't be picked up in place of the
  real src; dedup fetch URLs with a HashSet instead of O(n^2) List
  scanning; reuse FuchsPdf.MigraDocFilenameFromByteArray instead of
  re-spelling the "base64:" prefix.
- Fix a stale log message and comment left over from the
  GenerateInvoicePdf -> GenerateInvoicePdfAsync rename, and update
  INVOICE_LIFECYCLE.md's references to the old sync method name.
- Add tests for the config-derived whitelist, a decoy-attribute src,
  and the 20-image-per-invoice fetch cap boundary.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-10 21:03:09 +02:00
..

Decisions

This folder holds Architecture Decision Records (ADRs) — short, immutable records of a specific technical choice, why it was made, and what it implies going forward.

What belongs here

A decision, not a how-to. If it answers "why do we do X this way, and what else did we consider," it's a decision. If it explains "how subsystem X currently works," that belongs in ../Concepts instead (and a decision often triggers a concept doc to be created/updated).

File naming

NNNN-kebab-case-title.md, four-digit zero-padded, sequential across the whole folder (0001-..., 0002-...). Never reuse or renumber.

Required YAML frontmatter

Every decision file starts with:

---
status: Accepted        # Proposed | Accepted | Superseded
date: 2026-07-03         # date the decision was accepted
applyTo:                 # glob(s) — files/areas this decision governs
  - "Fuchs/Notifications/**"
supersededBy: ""         # filename of the decision that replaced this one, if any
---

Agents (Claude, Copilot, Codex) must scan the YAML frontmatter of every file in this folder first (cheap — no need to read the body) and only read the full body of decisions whose applyTo glob matches the files they're about to touch, or whose subject is otherwise clearly relevant to the task. This keeps decision-following cheap even as the folder grows.

Body template

# NNNN — Title

## Context
What problem/situation forced a choice.

## Decision
What was decided, stated plainly.

## Consequences
What this implies for future code — constraints, follow-ups, trade-offs
accepted knowingly.

## Alternatives considered
Options that were rejected and why (optional but preferred).

Rules

  • Decisions are immutable once Accepted. Do not edit the Decision/ Consequences of an existing file to reverse it. Instead, write a new decision, set its applyTo/subject accordingly, and set the old file's status: Superseded + supersededBy: NNNN-new-file.md.
  • Follow existing decisions. Before implementing anything in an area covered by an Accepted decision, read it and conform to it. If you believe a decision is wrong, raise it with the user rather than silently deviating.
  • Capture new decisions as they happen. Whenever the user (or the code you're writing) settles a non-obvious architectural or cross-cutting choice — not a routine implementation detail — add a decision here in the same change, and create/update the matching concept doc in ../Concepts.