Enforce registered specification artifact change-set operations in ears-manager check
Maintainers usually reply within 1 day
@JohnStrunk is already working on this.
Since Oct 12, 2026.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 30/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- go
- Domain
- developer-experience, devtools
Research direction
Start in ears-manager/internal/cli/state.go, where checkState() runs checkProposedBaseFreshness, and see how snapshot.Config.Artifacts and the proposed change sets are loaded. The new check compares registered artifacts against the default branch and requires a proposed ArtifactOperation with a matching artifact ID. Tests belong in ears-manager/internal/cli/selfhost_test.go or specvalidation/. Done when the hand-edit case fails with exit code 4 and the artifact-put case passes with exit code 0.
Written by the indexing model from the issue text.
Description
What happened
On PR #246 (implementing Issue #244), the repository codified governance rules to ensure that registered specification artifacts (docs/vision.md, docs/architecture.md) are never edited by hand and must only be modified via ears-manager artifact put within an active proposed change set.
Because ears-manager check only validated that the working tree file SHA-256 matched the recorded digest in .protobot/project.yaml, it had no mechanism to verify whether a modified artifact was associated with an active change set. To compensate, PR #246 drafted an intricate, 50-line natural language verification procedure into AGENTS.md Rule 6 and .agents/skills/review-pr/SKILL.md.
This procedure mandated that LLM review agents manually:
- Resolve
artifacts[].idin.protobot/project.yamlfor modified or stale registered specification paths. - Require a change-set manifest under
.protobot/change-sets/. - Verify that
ears-manager change-set show(no--at) after checking out the PR head reportsproposediff the manifest path is absent from the default-branch tree. - If
show --at <pr-head>is used, verify path-absence from default-branch in addition toproposed(since unmerged PR commits report all change sets asproposedunder--at). - Verify an
artifact_operations[]entry with matchingartifact_id. - Bind
ears-manager checkto a required checkout or worktree of the PR head.
Drafting and refining this manual review procedure required 7 fix iterations (commits 002eb9c, 29b2214, a3b4d9a, ea5325e, c8f98ce, 48fcfcd, f0cd1b4) and 8 review runs because the code/fix and review agents repeatedly struggled to formalize subtle Git ancestry semantics, non-existent YAML fields (status: proposed), and CLI flags in English prose. Because AGENTS.md Rule 4 requires identical terminology restatements between requirement and consequence clauses, every incremental adjustment required updating the 25-line parenthesized clause twice verbatim.
What could go better
This incident illustrates the pitfall of using complex prompt engineering and natural-language rules to enforce deterministic specification invariants that belong in tooling.
- Rework rate and agent thrashing: Seven iterations were spent debating the exact English phrasing of CLI invocations, Git worktree checkouts, and manifest list filtering.
- Review cost and fragility on future PRs: Under the current design, every future PR modifying
docs/vision.mdordocs/architecture.mdforces LLM review agents to execute this 5-step manual inspection protocol, consuming tokens and risking false positives or missed hand edits. - CI blind spot: A PR modifying a registered specification artifact by hand and updating the digest in
.protobot/project.yamlby hand still passes the CISpecification store checkjob (ears-manager check) as long as the digest matches the file content, because CI does not executeAGENTS.mdRule 6.
This pattern directly parallels Issue #237 (resolved in PR #238), where change-set base_commit freshness was moved out of human/bot review and directly into ears-manager check (checkProposedBaseFreshness in ears-manager/internal/cli/state.go). The identical principle applies to registered artifact governance.
Confidence: High. ears-manager check already inspects artifacts and loads proposed change sets in checkState(). Verifying that modified registered artifacts correspond to proposed change set operations is straightforward and deterministic.
Proposed change
In redhat-et/ProtoBot:
-
Extend
ears-manager checkto validate registered artifact operations:
Inears-manager/internal/cli/state.go(orears-manager/internal/specvalidation/), add a verification function (e.g.checkRegisteredArtifactOperations) called duringcheckState()alongsidecheckProposedBaseFreshness:- Inspect registered artifacts defined in
snapshot.Config.Artifacts. - Compare each registered artifact against the project's target default branch (
defaultBranchHead(root, snapshot.Config.Repository)). If an artifact file's content or digest differs from the default branch, or if a new registered artifact path is added:- Require that at least one proposed change-set manifest in
snapshot.ChangeSets(whereproposed[document.Value.ID]is true) contains anArtifactOperationwhoseArtifactIDmatches the registered artifact'sid. - If no matching proposed
ArtifactOperationexists, emit a structured validation diagnostic (e.g.artifact.operation_missing, exit code 4) indicating that the registered artifact was modified without anears-manager artifact putoperation in an active change set.
- Require that at least one proposed change-set manifest in
- Inspect registered artifacts defined in
-
Simplify
AGENTS.mdRule 6 andreview-prskill:
Replace the monolithic 50-line manual verification procedure inAGENTS.mdRule 6 and.agents/skills/review-pr/SKILL.mdwith a clean instruction to run and verifyears-manager checkon the PR head worktree:- Rule 6 will simply state: When a PR creates or modifies a registered specification artifact, or when Rule 4 identifies staleness in one, verify that changes were applied through
ears-manager artifact putin an active change set and thatears-manager checkpasses on a checkout or worktree of the PR head withoutartifact.operation_missingorartifact.digest_mismatch.
- Rule 6 will simply state: When a PR creates or modifies a registered specification artifact, or when Rule 4 identifies staleness in one, verify that changes were applied through
Validation criteria
- Automated unit/integration tests in
ears-manager:
Add tests inears-manager/internal/cli/selfhost_test.goorspecvalidation/:- Test A (Hand-edit rejection): Modify
docs/architecture.mdand manually update its SHA-256 digest in.protobot/project.yamlon a test branch without adding anartifact_operationto an active change set. Verifyears-manager checkfails with exit code 4 and a diagnostic naming the artifact ID. - Test B (Valid operation pass): Update
docs/architecture.mdviaears-manager artifact putwithin an active proposed change set. Verifyears-manager checkpasses cleanly with exit code 0.
- Test A (Hand-edit rejection): Modify
- CI enforcement:
TheSpecification store checkCI job (specin.github/workflows/ci-workflow.yaml) catches hand-edited registered artifacts deterministically within seconds. - Review stability:
Across the next 5 PRs modifying registered specification artifacts, zero review iterations are spent debating or executing manual change-set manifest and Git tree inspection algorithms.
Generated by retro agent from https://github.com/redhat-et/ProtoBot/pull/246
- Dominant language
- Go
- Stars
- 6
- Forks
- 8
- Avg merge
- 1d 57m
- Merged PRs (30d)
- 83
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from redhat-et/ProtoBot
-
bug infra ready-for-triage triaged
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
redhat-et/ProtoBot#301 · 2 comments · 1 reaction ·
Maintainers usually reply within 1 day
-
Enforce change-set base freshness and project.yaml metadata hand-edit checks in review-pr skillPossibly taken @fullsend-ai-coder claimed this 3 days ago. Opencomponent:specification-toolkit documentation ready-for-triage ready-to-code
Difficulty 3/5 1-2 days Newbie friendliness 35/100
redhat-et/ProtoBot#294 · 3 comments · 2 reactions ·
Maintainers usually reply within 1 day
-
Add multi-remote fork topology and non-candidate ref test fixtures to ears-manager self-host suiteOpenblocked component:ears-manager ready-for-triage
Difficulty 4/5 3-5 days Newbie friendliness 53/100
redhat-et/ProtoBot#293 · 2 comments · 1 reaction ·
Maintainers usually reply within 1 day
-
Enable issue-driven Fullsend Code/Fix runs to create ears-manager-compliant PRsPossibly taken @JohnStrunk claimed this 4 days ago. Opencomponent:ears-manager enhancement feature infra triaged
redhat-et/ProtoBot#292 · 10 comments · 2 reactions · 1 assignee ·
Maintainers usually reply within 1 day
-
enhancement feature infra ready-for-triage triaged
Difficulty 3/5 1-2 days Newbie friendliness 55/100
redhat-et/ProtoBot#288 · 2 comments · 1 reaction ·
Maintainers usually reply within 1 day
All issues in redhat-et/ProtoBot
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 2 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
devlikeapro/waha#2322 ·
Maintainers usually reply within 2 days