redhat-et / redhat-et/ProtoBot

Implement change-set comparison and deterministic impact analysis

Open
#112 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

blocked component:ears-manager
Dominant language
Go
Stars
5
Forks
6
Avg merge
23h 24m
Merged PRs (30d)
66

Description

Plan ID

EM-05

Purpose

Complete the change-set analysis needed for reviewable specification changes and downstream materialization.

Scope

  • Implement change-set list, show, update, and compare operations.
  • Report stable-ID changes, exact duplicates, declared conflicts, supersession, and dependency cycles.
  • Implement deterministic impact candidate generation from interface/scope intersections and explicit relationships.
  • Record applicable/not-applicable dispositions, rationale, and mechanical/semantic origin.
  • Enforce approved change-set immutability and base-commit rules.
  • Produce structured output suitable for pull-request summaries.

Dependencies

Depends on EM-04. The caller-facing result contract is defined by #30.

Acceptance criteria

  • Repeated analysis of the same fixture produces byte-identical output.
  • Candidate generation prefers false positives to missed explicit obligations.
  • Missing dispositions prevent approval when candidates exist.
  • Approved manifests cannot be modified.
  • Golden fixtures cover additions, revisions, retirements, conflicts, supersession, cycles, and scope intersections.

Out of scope

Semantic requirement review remains with the agent and human. WMS materialization belongs to later issues.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read EM-04 and issue #30 first to establish the dependency and caller-facing result contract, then locate the existing change-set and impact-analysis entry points in the Go repository. Use golden fixtures covering additions, revisions, retirements, conflicts, supersession, cycles, and scope intersections; done means repeated analysis is byte-identical and all listed acceptance criteria hold.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.