Good point.  I think we'll need new targetType entries, maybe DIFFUSE_SKY and SUNSS for the diffused and imaging legs of the instrument respectively. While we're making changes here, we shouldn't list the values of the enumeration in both the description of the DESIGN table and the definition of the targetType enum as they can get out of sync.

With the current proposal to drive SuNSS to the appropriate hardstop at the beginning of each exposure (or possibly pointing) the rotator angle will not be known until we start observing. I think that this can be handled by having a standard pfsDesign for SuNSS which is converted to pfsConfig once the angle is known. Ideally this only matters for SuNSS's imaging leg, but that depends on the uniformity of the diffused illumination. This relies on knowing the position angle sufficiently accurately which is not, I think, a problem. If we need a better measurement I suspect that we can get it from a short n channel integration summed in the wavelength direction.

There is one major difference from regular PFS operations, namely that we cannot specify the fiberId in the pfsDesign file because we don't control the rotator angle. I think this is OK; we'd set it to -1 (a number which will have to go into the datamodel; real IDs start at 1 so 0 would be an option, but -1 seems safer to me as it's obviously invalid) and the real fiberId would be written by the code that writes the pfsConfig. Who owns the code that does this transformation? I assume that it's usually done as part of cobra configuration.

As discussed on the #commissioning slack channel today: Update the targetType entries, to SUNSS_DIFFUSE_SKY and SUNSS_IMAGING

I did the minimal work, and generated a SuNSS pfsConfig file as a test but have not yet confirmed that it works.  However, I think that this was enough to close this ticket

N.b.  I went with SUNSS_DIFFUSE as all diffuse SuNSS fibres are sky fibres.