[Android Software/Hacking General [Developers Only]] Lanchon:
i wont be able to look at this for about a week. but...

- look into i9100 config, there ull find everything explained. then base your config on a simpler config, such as i9300 i seem to remember?

- a heap is a set of movable partition (deemed movable by you) that are CONTIGUOUS on the disk surface, possibly separated among themselves only by unallocated space if at all. note that partition NUMBERS within a heap need not be ascending or contiguous, but usually are.

- partitions that cant be moved (bricking) or are dangerous to move or for which there are no good reasons to move must not be members of a heap.

- a device can have many heaps defined on it, but usually there is no need for more than one. each heap has unmovable start and end sectors on disk. heaps cannot share free space among themselves: each one is a separate world.

- each heap has start and end sectors defined, and the possibly unordered sequence of partition numbers that are its members, declared in disk surface order.

from your message here:

fota should be raw. it could be made ext4 to make it resizable, but given its little size, it is probably best left alone. the smallest size for an ext4 partition is 8MB, so youd save only 2MB for the complexity. so dont. raw means it can be moved but its content are an obscure blob that repit will never alter (including its size).

recovery should be raw if movable. given that the device will be in an semi bricked state if relocation of recovery is interrupted, recovery should actually not be part of a heap at all.

so it is best to leave recovery and fota alone and out of the heap. the only reason to make them part of the heap would be finding out that there is a lot of unused and unpartitioned space after fota in the disk surface. youd have to weight the danger in moving recovery against the benefit of the gained space. none of my published setups move recovery. for heap end, you typically define a sector number. but for this case, you could use repit's finding of physical disk end, which can vary from device to device according to the flash component the phone OEM was able to source at the time of manufacture.

so looks like your heap should be partitions 14 to 17, with hard-defined heap start and end sectors. or you can tell repit to start the heap after partition 13 and end it before partition 18, which i seem to remember is what i usually did for most devices.

persist should be raw (and thus keep). moreover: i remember i think i created a way for a partition to not be configurable. persist should be that: it should default to raw and users must not be able to change its type or content. it only participates in the heap to let the cache donate space to system and data (which requires moving persist).

the other 3 partitions should be relatively obvious. they should be configurable, with defaults to their factory filesystem types, unchanged sized, and kept content. its easy for someone who wants to get rid of the cache to add -cache=min++wipe or whatever it was, i dont really remember at the moment.

if you need further help, maybe its best if u PM me your whatsapp so i send u audio messages, as i cant really spend time typing these days