fix(upgrade): renew a copied Forgejo PR form #223

Merged
claudiomaradonna merged 1 commit from fix/upgrade-forgejo-form into main 2026-11-12 15:44:43 +01:00
Collaborator

Why

Agent Foundry is a set of rules and skills for coding agents that a
repository adopts and later upgrades from this source. On a Forgejo
repository, adoption copies the pull request form agents write from,
.agents/templates/pull-request.md, to
.forgejo/pull_request_template.md, which Forgejo's web UI offers a
person opening a pull request. An upgrade renewed the first file and
never the second, so after the source revised the form, as b04e778 did,
agents filled the new form and people the old one, further apart with
each upgrade.

A validator check that the two files match was set aside, since it
would refuse a repository that keeps a Forgejo form of its own. A
symbolic link in place of the copy was set aside, since Forgejo's
handling of a linked template is unchecked.

Closes #221

What changed

Before, an agent upgrading a repository left its Forgejo form as
adoption copied it. Now, when the form and the template match on the
repository's main branch, the agent copies the merged template over the
form; when they differ, it asks the user, so a form the repository
changed on purpose is never overwritten unasked. A repository without
the form stays without it.

A repository whose two files already drifted meets that question at its
next upgrade. The change is one paragraph in step 3 of UPGRADING.md.

How to verify

  1. Have Git and a clone of this repository, with git fetch origin.

  2. The problem. The source changed both files between two of its
    commits:

    git diff --name-status --no-renames 7182781 b04e778 -- \
      .agents/templates/pull-request.md .forgejo/pull_request_template.md
    

    prints both as M. Step 3 of UPGRADING.md merges the first into
    an adopting repository and leaves the root .forgejo/ in the source,
    and on main only the one-time migration names the form:

    git grep -c 'pull_request_template' origin/main -- UPGRADING.md
    

    prints origin/main:UPGRADING.md:1.

  3. The solution. The same search on the branch,

    git grep -c 'pull_request_template' \
      origin/fix/upgrade-forgejo-form -- UPGRADING.md
    

    prints origin/fix/upgrade-forgejo-form:UPGRADING.md:2, the second
    being the new paragraph of step 3, to read at lines 41 to 46.

The checks of docs/MAINTENANCE.md pass on the tip. No test reads the
steps of UPGRADING.md, so the change adds none.

Not tried: an agent upgrading a trial repository adopted at 7182781 to
this branch, which needs a session of its own outside the sandbox.

Considerations

The comparison is with the repository's own template rather than the
adopted commit's, which the issue proposed, so that a repository that
changed both files alike is still renewed.

## Why Agent Foundry is a set of rules and skills for coding agents that a repository adopts and later upgrades from this source. On a Forgejo repository, adoption copies the pull request form agents write from, `.agents/templates/pull-request.md`, to `.forgejo/pull_request_template.md`, which Forgejo's web UI offers a person opening a pull request. An upgrade renewed the first file and never the second, so after the source revised the form, as b04e778 did, agents filled the new form and people the old one, further apart with each upgrade. A validator check that the two files match was set aside, since it would refuse a repository that keeps a Forgejo form of its own. A symbolic link in place of the copy was set aside, since Forgejo's handling of a linked template is unchecked. Closes #221 ## What changed Before, an agent upgrading a repository left its Forgejo form as adoption copied it. Now, when the form and the template match on the repository's main branch, the agent copies the merged template over the form; when they differ, it asks the user, so a form the repository changed on purpose is never overwritten unasked. A repository without the form stays without it. A repository whose two files already drifted meets that question at its next upgrade. The change is one paragraph in step 3 of `UPGRADING.md`. ## How to verify 1. Have Git and a clone of this repository, with `git fetch origin`. 2. The problem. The source changed both files between two of its commits: ```bash git diff --name-status --no-renames 7182781 b04e778 -- \ .agents/templates/pull-request.md .forgejo/pull_request_template.md ``` prints both as `M`. Step 3 of `UPGRADING.md` merges the first into an adopting repository and leaves the root `.forgejo/` in the source, and on `main` only the one-time migration names the form: ```bash git grep -c 'pull_request_template' origin/main -- UPGRADING.md ``` prints `origin/main:UPGRADING.md:1`. 3. The solution. The same search on the branch, ```bash git grep -c 'pull_request_template' \ origin/fix/upgrade-forgejo-form -- UPGRADING.md ``` prints `origin/fix/upgrade-forgejo-form:UPGRADING.md:2`, the second being the new paragraph of step 3, to read at lines 41 to 46. The checks of `docs/MAINTENANCE.md` pass on the tip. No test reads the steps of `UPGRADING.md`, so the change adds none. Not tried: an agent upgrading a trial repository adopted at 7182781 to this branch, which needs a session of its own outside the sandbox. ## Considerations The comparison is with the repository's own template rather than the adopted commit's, which the issue proposed, so that a repository that changed both files alike is still renewed.
fix(upgrade): renew a copied Forgejo PR form
All checks were successful
Maintenance / checks (pull_request) Successful in 4m23s
Maintenance / checks (push) Successful in 3m58s
d274756204
Adoption copies the pull request template to .forgejo/ on a Forgejo
repository, and step 3 leaves the root .forgejo/ in the source, so
each upgrade renewed the template agents use and left the form people
get in the web UI. The step compares with the repository's own
template, so a form the repository changed on purpose reaches the user.

Refs: #221
claudiomaradonna deleted branch fix/upgrade-forgejo-form 2026-11-12 15:44:49 +01:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
claudiomaradonna/agent-foundry!223
No description provided.