Claude: must-fix: On an existing (non-from-scratch) disk a new fixed-offset partition is pinned here (p->offset = p->fixed_offset) with no check that [fixed_offset, fixed_offset+new_size) is clear of existing on-disk partitions; context_scan_fixed_partitions() only validates fixed-vs-fixed overlap and the disk bounds. Two consequences:

1. Data loss. In context_write_partition_table() the destructive steps — context_wipe_and_discard() (blkid wipe + BLKDISCARD), context_copy_blocks(), context_mkfs() — all run at p->offset before context_mangle_partitions() calls fdisk_add_partition(), which is the only place an overlap is rejected. So when a fixed offset overlaps an existing partition, that partition is wiped/discarded/overwritten and only then is the GPT write refused — the data is already gone. This refutes the earlier dismissal that fdisk_add_partition() returning an error makes overlap safe. The below-first-usable-LBA case is worse: it only logs "adding it will likely fail, proceeding anyway" and proceeds into the same destructive path.

2. Overlap with auto-placed partitions. Only the leading free area is clipped by context->start = fixed_end_aligned; free areas built from an existing partition's trailing padding are not bounded by the fixed region, and fixed partitions never consume free-area budget, so a fixed offset landing inside such a gap is assigned the same range as an auto-placed partition.

Validate each fixed offset+size against existing partition extents (and refuse the below-first-usable-LBA case) before any wipe, and exclude the fixed region from every free area, not just the leading one.

Claude: suggestion: config_parse_offset_bytes() rejects only parsed == 0, but parse_size() accepts the literal 18446744073709551615 and returns exactly UINT64_MAX — which is the in-band "auto-placed" sentinel for p->fixed_offset (set in partition_new() and tested everywhere as == UINT64_MAX). Such an assignment is silently accepted and the partition is then treated as having no fixed offset at all, with no diagnostic and none of the downstream alignment/bounds checks ever running on it. Reject parsed == UINT64_MAX alongside the existing zero check so the sentinel value cannot be produced from input.

Claude: suggestion: For fixed-offset new partitions this branch unconditionally sets new_padding = 0, so any PaddingMinBytes=/PaddingMaxBytes= the user configured is silently discarded (auto-placed partitions honor them via partition_min_padding()), and context_scan_fixed_partitions() reserves only [fixed_offset, fixed_offset+size) with no room for padding. A fixed-offset partition with PaddingMinBytes= set is accepted but its padding is neither applied nor reserved. Either reject PaddingMinBytes=/PaddingMaxBytes= combined with FixedOffsetBytes= in partition_read_definition() (mirroring the Priority=/SupplementFor= guards), or honor and reserve the padding.

Claude: nit: sym_fdisk_get_first_lba(context->fdisk_context) * context->sector_size is computed twice in a row — in this if condition and again in the log_warning() arguments just below. Hoist it into a single local (e.g. uint64_t first_usable = …;) and reuse it, as the identical expression is evaluated once at the other call sites.