Codify ADR amendment convention in AGENTS.md and pre-commit checks to prevent in-place modification of accepted decisions
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 55/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- markdown, python
- Área
- documentation, tooling
Línea de trabajo
Start with the 'Rules for creating or modifying specification documents' section in AGENTS.md, where the proposed ADR amendment rule would go, and with the existing linters in scripts/lint.py and .pre-commit-config.yaml. Read docs/decisions/0001-requirements-storage-format.md to see the amendment format and what counts as a historical section. Done means the AGENTS.md rule is added and an offline check fails when an accepted ADR's existing lines are deleted or changed, while amendment blocks still pass. The check's exact rules for what counts as a historical section are not settled in the issue, so confirm them with maintainers first.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What happened
On PR #250 (https://github.com/redhat-et/ProtoBot/pull/250), commit 6e2ed1b modified docs/decisions/0001-requirements-storage-format.md by rewriting the accepted decision prose in place (lines 152–156) instead of appending a dated amendment section. Across automated review runs (including run 37943172659 on 6e2ed1b), the review agent reported zero findings on the ADR diff, raising only a generic [protected-path] finding on .github/workflows/ci-workflow.yaml. During subsequent human review, Lukas Kellerstein identified this in review comment A8 (https://github.com/redhat-et/ProtoBot/pull/250#pullrequestreview-2947118128): "Accepted ADR text rewritten in place: Mutated historical accepted ADR text rather than following the repo convention of appending a dated amendment section." Author John Strunk had to manually restore the historical decision text and append an **[Amended October 2026]** block in commit dc2d157.
What could go better
AGENTS.md explicitly lists docs/decisions/ as part of the specification document hierarchy and establishes detailed rules for creating and modifying specification documents, including registered artifact governance via ears-manager artifact put and sibling terminology consistency. However, AGENTS.md does not define rules for Architecture Decision Records, nor does it codify the project convention that accepted ADRs are immutable historical records that can only be refined by appending dated amendments (**[Amended Month Year]**). Furthermore, scripts/lint.py and .pre-commit-config.yaml contain linters for Markdown, YAML, and Go, but no deterministic check verifying that existing sections in accepted ADR files remain untouched. Because this convention was undocumented in agent instructions and unenforced by linters, neither the authoring workflow nor the review agent caught the mutation, requiring human reviewer intervention.
Proposed change
- In
AGENTS.md, add a numbered rule under 'Rules for creating or modifying specification documents':
"Accepted Architecture Decision Records (docs/decisions/) are immutable historical records. Never rewrite or replace accepted decision text in place. When subsequent design evolution amends or refines an accepted ADR, append a dated amendment block (**[Amended Month Year]**) describing the change, its rationale, and references to updated architecture documents. Review agents must verify that changes to accepted ADRs follow this amendment convention rather than modifying accepted sections in place." - In
scripts/lint.py, implement an offline pre-commit check verifying that git diffs touching files underdocs/decisions/with status 'Accepted' do not delete or modify lines in historical sections preceding the amendment blocks.
Validation criteria
The next 5 PRs (agent-generated or human-authored) touching docs/decisions/ adhere to the amendment convention without requiring human review comments or rework cycles, and review agents flag any in-place mutation to historical ADR decision sections as a finding.
Generated by retro agent from https://github.com/redhat-et/ProtoBot/pull/250
- Lenguaje dominante
- Go
- Estrellas
- 6
- Forks
- 8
- Merge medio
- 1 d 4 h
- PR fusionados (30 d)
- 90
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de redhat-et/ProtoBot
-
Enforce change-set base freshness and project.yaml metadata hand-edit checks in review-pr skillPosiblemente ocupada @fullsend-ai-coder la tomó hoy. Abiertocomponent:specification-toolkit documentation ready-for-triage ready-to-code
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
redhat-et/ProtoBot#294 · 3 comentarios · 2 reacciones ·
Los mantenedores suelen responder en 1 día
-
Add multi-remote fork topology and non-candidate ref test fixtures to ears-manager self-host suiteAbiertoblocked component:ears-manager ready-for-triage
Dificultad 4/5 3-5 días Aptitud para principiantes 53/100
redhat-et/ProtoBot#293 · 2 comentarios · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Enable issue-driven Fullsend Code/Fix runs to create ears-manager-compliant PRsPosiblemente ocupada @JohnStrunk la tomó hace 1 día. Abiertocomponent:ears-manager enhancement feature infra triaged
redhat-et/ProtoBot#292 · 10 comentarios · 2 reacciones · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Scope AGENTS.md specification-document sibling reading rule to avoid whole-repo doc reading on localized editsPosiblemente ocupada @cplegendre la tomó hace 3 días. Abiertodocumentation ready-for-triage ready-to-code
redhat-et/ProtoBot#283 · 2 comentarios · 2 reacciones · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Ensure all ProtoBot OpenCode usage and installs target v2Posiblemente ocupada @JohnStrunk la tomó hace 4 días. Abiertocomponent:drafting-table enhancement feature triaged
redhat-et/ProtoBot#272 · 8 comentarios · 1 reacción · 1 asignado ·
Los mantenedores suelen responder en 1 día
Todos los issues de redhat-et/ProtoBot
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
Los mantenedores suelen responder en 1 día
-
clawsweeper:fix-shape-clear clawsweeper:queueable-fix clawsweeper:source-repro impact:session-state issue-rating: 🦞 diamond lobster no-stale P2
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
openclaw/wacli#503 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 81/100
apache/rocketmq-dashboard#6895 ·
Los mantenedores suelen responder en 3 días
-
agent-butler-finding chore
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
jordansmall/spindrift#5466 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
open-telemetry/opentelemetry-go-compile-instrumentation#1507 ·
Los mantenedores suelen responder en 3 días