ELEVEN OF THE TWELVE APPKIT CASES PASS NOW, up from six, and the suite goes from 24 to 28 exit-zero of 35 run. Verified under the nested compositor, never headless. THE FIFTH WAS UPSTREAM. test_NSColor_colorUsingColorSpaceNamedevice is fifty lines of commented-out intentions and then exit(1), and CMake does not mark it WILL_FAIL, so it fails in upstream CI exactly as it fails here. Nothing in it touches this AppKit. It sat on the divergence list for a day on the strength of a non-zero exit code, and the generator names it as a placeholder now. AN EXCEPTION THAT EXISTED BUT COULD NOT BE REACHED. The case that would not compile wanted NSColorListNotEditableException, and declaring it beside the class that raises it is wrong twice over: it collides with a real declaration, and the constant was never missing. AppKit/NSErrors.h declares thirty-six exception names and NSErrors.m defines them all, but the header was private and the umbrella never imported it, so all thirty-six were invisible to an application. One move for thirty-six constants. Public headers here come from an explicit header_map in buck/generated and not a glob, so a new one has to be listed there or the umbrella cannot find its own header. A STUB THAT ANSWERED. isEditable was NSUnimplementedMethod and returned NO for everything, while insertColor:key:atIndex: inserted into anything, so an application offering the system palette for editing was told nothing and the edit did not survive. Editability is a real ivar now, YES for a list an application makes and NO for the four the framework builds, and insertColor raises on a refusal. setColor:forKey: stays unguarded on purpose: that is how the framework fills its own lists and how the display backend seeds a catalogue colour it has just answered. TWO LISTS SHIPPED UNDER INVENTED NAMES. macOS ships Apple, Crayons, System and Web Safe Colors; this AppKit shipped Basic, System and Web. Basic IS Apple classic palette and Web is the HTML named colours, so both are renamed, Crayons is new, and colorListNamed for Apple answers for the first time. That mattered more than it looks: the not-editable case asks four lists to refuse an insert, and against a nil list every one of those would have passed while proving nothing. THE SYSTEM LIST IS NOW THE 51 KEYS macOS PUBLISHES and no others. Trimming the older names is safe because a colour class method goes to the DISPLAY for its value and not to this list; the list decides what a colour panel offers and nothing else. Nineteen of the 51 had NO NSColor class method at all, the whole modern system palette plus the five fill levels, and a missing one is an unrecognised selector, which raises, which an application catches, which shows up as a feature that silently does nothing. Three more had a method but no recipe and answered nil, which is worse than wrong: AppKit draws with no colour, so a table simply has no grid. All are in colors.rs now, with an Rgba recipe added because the five fill colours are defined by their alpha. The system palette values are the published ones, transcribed rather than measured off a running macOS, and the twelve Crayons greys are a regular ramp rather than the exact macOS steps. BOTH NSCursor CODER CASES round trip: keyed reads NSImage and NSHotSpot, non-keyed writes float x, float y, image, two signed chars and reads float, float, signed short, image. THE PROOF IS NOT THE EXIT CODES. run.sh caps each case at two lines and an AppKit case spends both on the backend saying hello, so the one case that prints on its happy path looked as silent as one that did nothing. With the cap raised it prints all five refusals by name, System then Apple then Crayons then Web Safe Colors, which is what makes the zeros mean anything. LOOKED AT: Swift Publisher document window is BYTE IDENTICAL to its capture from before the change, so none of this moved a pixel in an application. Seen in that capture and not caused here: its Simulate paper color well and the inspector swatch both draw solid black.