Either way your commits are actually going to look the same from the firewalls perspective, so either one really doesn't matter.
If you've already configured an aggregate interface previously so you know that your switch and PAN are actually going to play nice together how you configure them, then I wouldn't have any issue saying to go ahead and include Ethernet1/12 as an aggregate member in the new aggregate ethernet interface.
If you haven't previously configured an aggregate interface between these switches and your firewall I would have the aggregate use Ethernet1/13 and Ethernet1/14 as members instead and transition things to the new AE interface once you've verified the aggregate actually comes up on the firewall and switch well. This just helps verify that the switch and the firewall are actually going to play nice prior to migrating the services over to them.
... View more
Debug reboot is for troubleshooting boot problems. In debug mode the boot process continues also in case of errors (like an important service cannot be started), where the normal boot would stop and the appliance would reboot again (until it reaches maintenance mode after 3 failed reboots). This makes it possible to write additional logs that are needed for troubleshooting existkng boot problems. For example if you start a PAN-OS 8 panorama on hyper-v ( which isn't supported) the boot up will fail because panorama tries to start a service that is specially written for ESX. In debug reboot mode panorama ignores this error and continues booting up without this ESX specific service.
... View more