They are eating their own dog food

The built-in build/release tasks of TFS Azure DevOps have manifests, too. And those manifests are right there in the database!

Specifically, the task.json files of the built-in tasks are sitting in the field MetadataDocument of table Task.tbl_TaskDefinitionVersion in database Tfs_Configuration (AzDevOps_Configuration, if your instance is recent). It's stored in deflated format, sometimes with the UTF-8 byte-order mark, sometimes without. It can be tracked to the task's display string via the Task.tbl_TaskDefinition. At the end of the day, the following SQL will return the manifests, with regard to task versioning:

select d.DisplayName, v.MajorVersion, v.MinorVersion, v.PatchVersion,
trim(char(239)+char(187)+char(191) from cast(decompress(MetadataDocument) as varchar(max))) as TaskJSON
from Tfs_Configuration.Task.tbl_TaskDefinition d
inner join Tfs_Configuration.Task.tbl_TaskDefinitionVersion v on d.InternalTaskId = v.InternalTaskId
order by DisplayName, v.MajorVersion, v.MinorVersion, v.PatchVersion

One thing this is good for, you can fish the Microsoft provided manifests for features that are supported but not documented. To this day, the best doc that we have for task.json files is the schema at https://github.com/microsoft/azure-pipelines-task-lib/blob/master/tasks.schema.json - and there are so many places where those manifests don't match the schema. Even leaving aside the case sensitivity of JSON schemata (they are supposed to be case sensitive), there are quite a few parameters to be exploited in your own tasks.

Among promising undocumented task features:

• On a task input, there can be a validation{expression, message} element
• Under execution, there is an option for Process - found on the Command Line v1 and on Batch Script v1 tasks
• Under category, Tool is also an option
• Under visibility, Preview is also an option

Here is an alternative schema that validates all built-in tasks (and all the gallery tasks that I have): tasks.schema.amended.json. Feel free to diff with the official schema.

And I've got a purely Transact-SQL JSON schema validator out of it. The gist is here. It's quite limited; it was only built with one particular schema in mind, and doesn't even validate 100% of that schema's constraints; the pattern element, which would make the validator match a JSON string against a regular expression, is not supported. Running regex pattern matching in MS SQL Server is possible with either CLR or OLE Automation, but either needs to be enabled by a sysadmin. Not good for a potentially reusable piece.

Implementing regex in pure TSQL is, naturally, possible, but I didn't feel like it.