This is nice feature and I'm using D12165 as patch and it's cool. It seems like good connection between arc tasks and arc todo now that in both of those You can use --project

I don't want to add flags one by one for this. This approach is time-consuming and not very powerful. To provide one specific example, supporting custom fields via hard-coded flags in the arc client is not practical without some level of generalization.

Instead, I want to drive these CLI query workflows through ApplicationSearch. Examples would be:

# Run the "Assigned" builtin query.
$ arc list --query assigned 

# Run the "All Tasks" builtin query.
$ arc list --query all

# Run an ad-hoc parameterized query (open tasks in your projects not tagged "bug").
$ arc list --query 'projects=viewerprojects(),not(bug)&statuses=open()'

This would give us:

• a single, consistent, full-power query language across the web UI, conduit, the CLI, dashboard panels and HTTP parameters;
• automatic support for new fields, new orders, custom fields, new constraints, new typeahead functions, etc., across all UIs;
• integration between the web UI and Conduit/CLI (so you write queries with the web interface, then run them from other contexts).

To do this, we need to take these steps:

Let ApplicationSearch know about search fields. Currently, ApplicationSearch doesn't read query parameters in a structured, introspectable way. That is, given a SearchEngine $engine object, there's no method you can call to ask it which parameters it accepts: you have to pass in a bundle of parameters and hope for the best. The parameter spec is informally encoded in the construction of the HTML form which submits queries. ApplicationSearch needs to be restructured so that each SearchEngine emits some sort of parameter spec and buildSavedQueryFromRequest() just reads this spec.

Drive Conduit through ApplicationSearch. Conduit query methods should be driven by ApplicationSearch; it should be primarily responsible for reading parameters from the request, invoking the query, and retrieving results. In particular, saved ApplicationSearch queries should be queryable via API, and all ApplicationSearch capabilities should immediately be available in Conduit. The unique code in Conduit query calls should mostly be code for rendering objects into a wire format.

Use new API methods in arc tasks and arc list. Once the API exposes ApplicationSearch, we can rewrite arc tasks and arc list to be a thin layer of glue on top of the underlying API method. The unique code in these workflows should mostly be code for rendering objects in wire format (from Conduit) into text format (for display on the CLI).

This is a significant amount of work, largely because we have to convert a ton of existing SearchEngine and ConduitAPIMethod classes. Roughly:

1. Drive ApplicationSearch through a field spec: 6 hours.
2. Drive Conduit through ApplicationSearch: 8 hours.
3. Drive arc tasks and arc list through modernized Conduit: 1 hour.

This work also probably can not take place in 15 contiguous hours, because step (2) causes huge API compatibility breaks. I do currently favor doing a major API break, but I'd like to do it at the same time we break everything we need to break for T5873, which I don't have a solid plan for yet.

• From elsewhere, we should make it an explicit error to specify both "before" and "after". The behavior when both are specified is meaningless. This should generally be better documented.

The new *.edit and *.search endpoints are now available in Paste and Maniphest, so arc paste, arc todo, and arc tasks can switch over. I'm not necessarily planning to do this immediately -- at a minimum, I'm going to let them stabilize a bit first.

arc list can't switch until Differential moves to EditEngine, which is probably some ways away.