Could precompute next date/version. And do it all together. Make DateString into a DateAndVersion class or something.
(Also, this is a severe optimization because we do this like, three times on a bad day--maybe we shouldn't precompute it.)

Move config.py references and Safe .panrc to use this framework.

This is getting unsustainably long to run. Can we do something else with it?

Depending on Some Ex-Intern's repository isn't the most security-safe practice. (I mean, what if I deleted it? I'm not going to delete it. But you can't depend on that.)

Here's how you move Pandorica over to an official public Palo Alto Networks repo.

• Move code to new Pandorica repo under Palo Alto Networks specific repo.
  If you clone the repo locally and add the empty PAN repo as a remote, you should just be able to push all my branches to the new empty PAN repo individually. This will preserve my commit history. (Unless you don't want my commits, in which case you could literally copy paste all my code into the empty repo and add it all as one commit, but then you'd need to recreate my branches and stuff.)
• Make run_pandorica on the Jenkins server pull the Jenkinsfile from the PAN repo instead of this repo. This means that future autoruns will use the new instructions instead of whatever happens to be on master in this repo.
• Make test_pandorica on the Jenkins server pull the Jenkinsfile (changing this should also change where the code is pulled from) from the PAN repo instead of this one. This means that the test will check the new repo for changes and test them.
• Make the test Jenkinsfile specify to set commit statuses on the new repo instead of this repo. (If you do the previous step but not this one, Jenkins may complain that the repo doesn't have the commit associated with the hash specified and can't set its commit status, since it's getting changes from the PAN repo but trying to set commit statuses in this repo. Or maybe it'll fail silently. I haven't tried this yet, so I don't know.)
• Move wiki.
  We need documentation.
• Move issues/PRs.
  Including this one.

Non-headless Chrome is turning out to be a pain in general. However, when I try to figure out how to find the device tab in headless mode, all I seem to find are abandoned Stack Overflow posts from about a year ago.
I'm open to suggestions.

• README.md

Anywhere else we should document things? (Probably.)

I'm not currently tagging generic domains, but I could be. Implement tagging all non-generic domains, then all generic domains until you run out of AutoFocus points. (You might eventually catch up?)

Tests are written--probably don't need rewriting since all my recent changes of code-breaking magnitude are on the scraper which we aren't testing. For Reasons. (I assume I had reasons.)

• Date of content update
• Version number of content update

For each domain we need to have the actual tag fields broken out so that we can create visualizations built using said fields. AF returns the actual fields as tag_name, public_tag_name, etc. and that is what should be in each doc.

Either reformat all your old dates to the new format, or reformat all your new dates to the old format, or just dump them all together and hope it works

This was brought up as possibly helpful, but it would involve a major overhaul of how we're storing all current data. I'm not going to start it during my last week, but I'm noting it as a possible area of future work.

Having issues downloading Chrome because of dependency issues; probably because this is the newest Chrome version but this is old Ubuntu.

• Try Chromium instead of Chrome since it's here already; download a proper driver manually
• Download a driver in the Dockerfile

• Elasticsearch backups
• Kibana backups
• see if this fixes the Kibana thing

I'm not sure why I wasn't using get before, but I should definitely be using get. Do this. UBQ is probably just way slower.

Use the wget branch, or whatever I called it.

Write a script to map old documents to new format.

Sometimes it fails, and I don't know why.

• Put things from my .panrc into the default file
• Delete unused parameters in the default file
• Document necessary params in the proper places

For archival purposes. Possibly just move the code as of poc-mod, that seems the most useful to everyone concerned.

Don't forget to:

• update release_scraper documentation
• rename release_scraper

Maybe don't delete poc-mod, since the things that Steven's using it for are closely related to Pandorica's core parsing functions.

They all have their own files. Refactor and run each separately. Especially nice if you can cram them all into a Jenkins pipeline.