most of the stuff is covered by T211197, only remaining things is:

• Feature flag can be superseded by a development query parameter

@pmiazga, @Jdlrobson - what do we want to do here? Add that to the current task? Leave this as a separate task and remove the rest of the acceptance criteria?

I'll repurpose this task to handle only Feature flag can be superseded by a development query parameter, as this is a bit more complicated.

Not sure how high a priority this is given opting in is so straight forward.

We could piggy back off mobileaction query string parameter which allows us to share a link to a page in beta. However how to handle those uris shared when the user is logged out?

I suspect we can get away without doing this and avoid ourselves some implementation headaches.

What would the value of having such a query parameter be?

If I understand this task right (the AMC mode has to be disabled on production for now - not visible on Special:MobileOptions page), this development query parameter has to supersede the MFAdvancedMobileContributions config flag (enable the AMC mode and enable AMC for currently logged-in user). It looks bit scary, as the beta mode is available on production, and the mobileaction only temporarily enables the beta mode for the current user.

If I understand this task right (the AMC mode has to be disabled on production for now - not visible on Special:MobileOptions page), this development query parameter has to supersede the MFAdvancedMobileContributions config flag (enable the AMC mode and enable AMC for currently logged-in user).

This is my understanding as well. I think it will be very useful for testing changes on wikis where the feature is otherwise disabled.

I'll chat to Olga in our next sync about how testing requirements.

@Jdlrobson - can we close this?

Do consider that this change might be useful for setting up automated browser tests targetting AMC mode available/unavailable, since the Node.js stack doesn't support a local LocalSettings.php file.

I think it's valuable to do this thing, but IMHO we shouldn't allow users to enable things, that are disabled via config. I see the point of having ?amc=true to force AMC mode to be on, but only when AMC mode is available. But then it makes it
bit useless when it comes to testing because the automated browser test can just go and enable the AMC mode by itself.

The only thing that comes to my mind is to have the AMC mode enabled by default in our test bench, and then having a flag to disable the AMC mode, sth like disable_amc=true, and this would make the AMC mode not available.
Thanks to that we don't create security loophole (allowing users to override config) and it will allow us to test both available and unavailable modes.