docs(agents): revert to English-only pull requests

.github/pull_request_template.md

@@ -8,11 +8,9 @@ Every section below is required. Where one genuinely does not apply, write
 Title: the same Conventional Commit string as the primary commit, e.g.
   feat(us3): implement the auth-api operational contract
 
-Language: the TITLE is English (it becomes the squash-merge commit subject).
-The BODY is bilingual — write every section in English, then repeat it under a
-`## Español` heading. Same content, not a summary. See section 3.
-This applies to AI agents too: write both halves, do not leave one for someone
-else.
+Written in English — title, body, and review comments. No bilingual sections.
+See section 3 of the conventions. Discussing the change in another language is
+fine; writing it into the repository is not.
 -->
 
 ## What changes
@@ -65,8 +63,3 @@ else.
      - Report faithfully: if CI is red, say what is red. If a step was skipped,
        say it was skipped. -->
 
----
-
-## Español
-
-<!-- Repite arriba, en español. Mismo contenido, no un resumen. -->

AGENTS.md

@@ -27,7 +27,7 @@ It exposes Prometheus metrics, reports traces to Zipkin, and publishes create/de
 - Todo state is keyed by `req.user.username`; a new user receives three seeded items, and mutations are explicitly not concurrency-safe.
 - `/metrics` is registered before JWT middleware and is public; all `/todos` routes require a JWT bearer token.
 - The API has no update route, and only create/delete operations publish Redis messages containing the Zipkin trace ID.
-- Write pull-request bodies bilingually: every section in English, then repeated under a `## Español` heading with the same content, not a summary. Titles, commits, code comments, documentation, and specification text stay English-only. As an AI agent you write both halves yourself.
+- Write everything in English — branch names, commit messages, pull-request titles and bodies, review comments, code comments, documentation, and specification text. No bilingual sections. Changing this rule takes a recorded decision in `microservice-app-docs`, not a remark in conversation.
 - Open every pull request through `.github/pull_request_template.md` and follow `microservice-app-docs/docs/Pull request and task tracking conventions.md`: one concern per short-lived `<type>/<summary>` branch, a Conventional Commit title with a scope, and every template section filled. Constitution principle 13 makes this binding, not advisory.
 - Keep the Spec-Driven Development commit pair intact: `test(<scope>): specify ...` must be committed failing before `feat(<scope>): implement ...`. Never squash the pair; the failing-test commit is the evidence the cycle was followed.
 - Track every task. Name in the pull-request body the task IDs it advances, qualified by repository and spec, and update `tasks.md` in that same pull request rather than a follow-up. Mark a task `[X]` only after locating and inspecting its named artifact — never from a summary, a green check, a rendered manifest, or recollection. Annotate partial delivery instead of ticking it; work no register covers either gains a task or records in the PR body why none applies.