I thought I'd keep this thread separate, as I know little about the JSS, having mostly interacted with the MDM product. Here goes. To the best of my knowledge:
1. Casper has no concept of tracks, that I am aware of, 'baked-in' to the product. E.g., there is no testing, 'canary in the coal mine' group designation
2. Software needs to be specially treated before being made available, (I've been noticing confusion regarding HTTP/S availability vs. traditional fileshares,) but a guiding principle seems to be it at least must be a flat package and not blow things up
3. There is no metadata for all the other things Munki provides out-of-the-box, including blocking applications, which must therefore be wrapped with a script
4. There is no concept of managed updates, so you need to create a new smart group each time you'd like to scope/prepare an 'uploaded' patch to clients
5. All software must have a category assigned to it before it can be made available, and categories have no specifically defined utility when it comes to pkgs, being applicable in many contexts/across data types
6. Software installs get put in the root of the JSS distribution point/fileshare and cannot be stored/accessed in folders
7. Installs that would otherwise fail over-the-network need to be specifically designated to be cached in the fugazi room
8. 'configurations' and policies exist separately from groups of clients, which provide something in the way of nesting functionality

My entry point to integrate AutoPKG is to have the pkgs built by AutoPKG automatically
1. create a category in the JSS if it isn't present(working) based on product name
2. copy the pkg to the JSS dist point
3. update the API to make the JSS aware that the pkg is there
And eventually
4. do any heavy lifting to get the pkg live for a 'canary' track, as makes sense within the Casper model
5. get Casper imaging involved

Sorry if I seem glib and clueless(what a combination,) I'm really excited to deliver functionality that jives with the Casper model.
Allister