🤖 Generated by the Agentic Engineer
Evidence
#125 restored 13 repositories to a healthy sync state by removing an unresolvable mismatch, so reconciliation stopped attempting an update it could never complete. That fixed the symptom the fleet was showing.
It also isolated a sharper problem. Measured on the live cluster after that deploy, the two repositories still failing are the two with a genuine pending change — and their rejection is unchanged:
PATCH https://api.github.com/repos/devantler-tech/agent-plugins:
422 Commit signoff is enforced by the organization and cannot be disabled
Verified against the GitHub API (not status.atProvider, which is not trustworthy here): agent-plugins and agent-skills each declare 10–11 topics and have zero topics live. The declared change is real, the update is attempted, and it is rejected.
The setting the error names is not misdeclared. webCommitSignoffRequired is true in 20/20 specs and has been pinned in the shared patch since 2026-06-18.
Problem
If a correctly-declared value still produces this rejection, then the rejection does not depend on what we declare — and every update is rejected the same way, whatever it contains.
That reframes what #125 achieved. It restored the reporting: a repository with nothing to apply now correctly reads healthy instead of masking a permanent error. It did not restore the write path. On the evidence above, the current state is:
- a repository with no pending change reconciles cleanly — 16 of 20;
- a repository with any pending change fails — and will keep failing.
So declarative management currently works for everything except actually changing something. That is worth stating plainly, because a green fleet now reads as "under control", and the first person to edit a declared value will find otherwise. It also means the visibility question on #123 cannot be executed even once it is decided.
Confidence: the outward behaviour is measured and consistent. The mechanism is inferred — the request body is not visible from here, so "the provider sends the field in a form GitHub rejects" is the best-supported explanation rather than a proven one. Likeliest candidate is the provider emitting the field's zero value on update regardless of the configured value, which would match the error text exactly.
Suggested approach
- Capture what the provider actually sends — provider pod logs at debug, or a single reproduction against a scratch repository — and confirm whether the field is in the payload and with what value.
- If it is a provider defect, check it against
provider-upjet-github upstream and pin or patch accordingly; the deployed version is v0.19.1.
- Re-prove afterwards by moving one declared value end-to-end (topics on
agent-skills is the natural candidate — the change is already declared and pending).
Acceptance criteria
Rough size: M — investigation first, then most likely a provider version or configuration change.
Part of #123
Evidence
#125 restored 13 repositories to a healthy sync state by removing an unresolvable mismatch, so reconciliation stopped attempting an update it could never complete. That fixed the symptom the fleet was showing.
It also isolated a sharper problem. Measured on the live cluster after that deploy, the two repositories still failing are the two with a genuine pending change — and their rejection is unchanged:
Verified against the GitHub API (not
status.atProvider, which is not trustworthy here):agent-pluginsandagent-skillseach declare 10–11 topics and have zero topics live. The declared change is real, the update is attempted, and it is rejected.The setting the error names is not misdeclared.
webCommitSignoffRequiredistruein 20/20 specs and has been pinned in the shared patch since 2026-06-18.Problem
If a correctly-declared value still produces this rejection, then the rejection does not depend on what we declare — and every update is rejected the same way, whatever it contains.
That reframes what #125 achieved. It restored the reporting: a repository with nothing to apply now correctly reads healthy instead of masking a permanent error. It did not restore the write path. On the evidence above, the current state is:
So declarative management currently works for everything except actually changing something. That is worth stating plainly, because a green fleet now reads as "under control", and the first person to edit a declared value will find otherwise. It also means the visibility question on #123 cannot be executed even once it is decided.
Confidence: the outward behaviour is measured and consistent. The mechanism is inferred — the request body is not visible from here, so "the provider sends the field in a form GitHub rejects" is the best-supported explanation rather than a proven one. Likeliest candidate is the provider emitting the field's zero value on update regardless of the configured value, which would match the error text exactly.
Suggested approach
provider-upjet-githubupstream and pin or patch accordingly; the deployed version is v0.19.1.agent-skillsis the natural candidate — the change is already declared and pending).Acceptance criteria
agent-pluginsandagent-skillsreachSynced: Truewith their declared topics applied.Rough size: M — investigation first, then most likely a provider version or configuration change.
Part of #123