Assuming my last revision makes it through, just four issues remain... @epriestley - I've provided some details... Can you let me know what you want me to do for these last four?

src/applications/drydock/blueprint/DrydockWorkingCopyBlueprintImplementation.php:43: // TODO: (T603) Figure out the interaction between policies and Drydock

This particular bit of code loads a repository based on the 'repositoryID' attribute from a DrydockLease. I am not sure what the interaction should be - maybe if there exists an intersection of people who can edit the blueprint and see the repository? Sounds messy.

src/applications/maniphest/query/ManiphestTaskQuery.php:226: // TODO: (T603) It is possible for a user to find the PHID of a project

Full TODO is...

// TODO: (T603) It is possible for a user to find the PHID of a project
// they can't see, then query for tasks in that project and deduce the
// identity of unknown/invisible projects. Before we allow the user to
// execute a project-based PHID query, we should verify that they
// can see the project.

should there be some code added to willExecute that filters out any projectPHIDs the user can't see? (Basically do a policy query for the project phids specified and remove any that don't match?) Otherwise, how should this be implemented?

src/applications/maniphest/view/ManiphestTaskResultListView.php:63: // TODO: (T603) Eventually, we conceivably need to make each task draggable individually

This is a polish thing, where I think users can see some tasks but not edit them, but the UI lets them drag if they are logged in users. I have not investigated this, but presumably its an involved change to make the javascript aware of things on a per-item basis. My proposal is to file a new task, low priority to handle this. Alternatively, I can tackle this if you think its like an afternoon or less of work.

src/applications/repository/storage/PhabricatorRepositoryCommit.php:259: // TODO: (T603) Who should be able to edit a commit? For now, retain the existing policy and return PhabricatorPolicies::POLICY_USER

Whaddya say boss?

#1: For drydock, I'd switch it to a Query with an omnipotent user -- we can only reasonably do the checks when users create the blueprints, since systems like Drydock, Almanac, Harbormaster and Instances don't act as a real user when running background tasks. Like with Harbormaster, we'll just prevent you from creating things that affect stuff you can't act on in the first place. Drydock will have high default barriers to creation, anyway.

#2: For the task query thing, we should ideally run a ProjectQuery and make sure they can see all the projects they're about to run a TaskQuery for, then filter out the ones that they can't see and throw a PhabricatorEmptyQueryException if nothing is left after filtering.

#3:

My proposal is to file a new task, low priority to handle this.

Yep, agreed with your assessment and proposal.

#4:

Rule seems fine as-is for now, we can just remove the comment. In effect, POLICY_USER means "users who can see the repository" because that's built in to being able to see a commit, which seems like a workable rule. Editing commits basically does nothing anyway (tagging them and linking them to stuff). I haven't seen any users hitting issues with this.