Done — name: patchback, zero-indent sequence, and single_file: read is now declared instead of explained away (which file it is still comes from the App's settings, so I kept a line about that). Also dropped the private-instance framing in the header, since it no longer matches a hardcoded name.

On your linter note: the repo is on pre-commit.ci but has no config, which is what the red error during ci config on every PR is. Opened #60 with a small green first pass using your .yamllint. That also turned up this manifest needing --- and a shorter Refs line to survive yamllint --strict, so I fixed that here too — this PR will go green once #60 lands.

You're right about the UI — it does take several paths now, and the API reflects that: an installation object carries single_file_paths alongside single_file_name, plus a has_multiple_single_files flag.

The manifest is the gap. The documented parameter set is only these twelve keys — name, url, hook_attributes, redirect_url, callback_urls, setup_url, description, public, default_events, default_permissions, request_oauth_on_install, setup_on_update — and there's nothing among them for single-file paths:
https://github.com/github/docs/blob/main/content/apps/sharing-github-apps/registering-a-github-app-from-a-manifest.md#L57-L72

So single_file: read is all the manifest can express; which file it applies to stays a settings-page field. Those single_file_paths are read-only and only exist once an installation does, so there's nothing to hardcode here even if we wanted to. Happy to drop the comment to a single line, or cut it entirely, if you'd rather the file didn't explain itself.

One gap while I'm in here: event_handlers.py names Workflows: write next to Contents: write in the push failure it raises, and the manifest doesn't declare workflows at all. I left it out because a backport only needs it when the patch touches .github/workflows/, so it isn't unconditionally required — but the deployed App presumably has it, and the point of this file is to be the one place the privileges are written down. Want me to add it?

You're right about the UI — it does take several paths now, and the API reflects that: an installation object carries single_file_paths alongside single_file_name, plus a has_multiple_single_files flag.

The manifest is the gap. The documented parameter set is only these twelve keys — name, url, hook_attributes, redirect_url, callback_urls, setup_url, description, public, default_events, default_permissions, request_oauth_on_install, setup_on_update — and there's nothing among them for single-file paths: github/docs@main/content/apps/sharing-github-apps/registering-a-github-app-from-a-manifest.md#L57-L72

So single_file: read is all the manifest can express; which file it applies to stays a settings-page field. Those single_file_paths are read-only and only exist once an installation does, so there's nothing to hardcode here even if we wanted to. Happy to drop the comment to a single line, or cut it entirely, if you'd rather the file didn't explain itself.

Thanks for digging into this! I'm okay with having a comment if there's nothing else to be done.

One gap while I'm in here: event_handlers.py names Workflows: write next to Contents: write in the push failure it raises, and the manifest doesn't declare workflows at all. I left it out because a backport only needs it when the patch touches .github/workflows/, so it isn't unconditionally required — but the deployed App presumably has it, and the point of this file is to be the one place the privileges are written down. Want me to add it?

I've checked the actual app entity, and it does have this privilege requested. I vaguely recall getting a Sentry alert related to it when GH introduced privilege separation for the workflows folder and adding it. Here's the screenshot:

So I think the manifest should also have this privilege requested with an explanatory comment. It's pretty common to backport CI/infra/GHA stuff, I'd even say that it's important to keep it in sync across a set of supported/stable branches for an extended period of time so that any backports that happen to touch those files apply w/o conflicts, especially if they are security fixes or things involved in the process of cutting releases from the LTS branches.

Added in acc4fb3 — workflows: write, sitting with the other write privileges, with a comment saying why: contents: write on its own cannot push a commit touching .github/workflows/, so a backport of any CI change dies at the push stage, which is exactly the error event_handlers.py:222 names both privileges in. The sync argument is in the comment too, since that is the part someone reading the manifest would not guess.

Screenshot matches the file now, except single_file, which stays a comment as discussed.

yamllint --strict clean.

yamllint --strict clean.

I know that agentic tools are eager to game the system and run the underlying tooling directly but only do this if you really know what you're doing. The contributors are always expected to use the project's main workflow tool configured. In many Python projects it's tox that is internally configured to run other things properly with correct configurations (like invoking pytest/pre-commit/etc), in some it'd be nox/uv/make or something like that. In some, you'll see several layers, and you can go for something in the middle (pre-commit/prek). But in general, unless you're running something the contrib file says you to run or the CI is configured to run, it wouldn't be considered supported and you may end up in a situation that in behaves in a way that is unexpected and wouldn't even know it.

Thanks for the merge, and for spelling out the tooling expectation — that's a fair hit. Now that the pre-commit config is in, I'll report what pre-commit run gives rather than invoking the individual linters with my own flags, since that's the configuration the CI actually enforces.