Concept-scoped rejection memory

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Triage a night-theme request after finding a closed dark-mode issue. Teaching record A rejected dual-theme maintenance cost; record B closed because the feature already existed. Closed alone does not distinguish these meanings.

Mechanism

Match concepts rather than keywords, then read reasons and scope. For substantive rejection, cite the decision/rationale and check whether current context and the maintainer still support it. For built features link implementation; retain temporary deferrals as deferrals. Reuse a rejection only for the same concept under a still-valid decision.

Bad example

Night theme resembles the closed dark-mode issue, so reject it immediately. Also put record B, closed because already implemented, into the permanent rejection list.

Good example

Inspect A/B reasons before classifying night theme. Cite A's cost-based rejection and check whether the maintainer still holds it. Link B's implementation rather than recording rejection. Distinguish deferral and rejection, allowing changed context or materially different requests through normal triage. Deliver a recommendation only; do not close issues.

Why the change matters

Closure does not encode the decision’s meaning. Separating rejection, implementation and deferral reuses prior reasoning without turning a delivered feature into false rejection evidence.

Observable expectation

An illustrative triage record cites A’s cost rationale/current review and B’s implementation. A distinct night-readability problem preserves its differences.

Trace decisions rather than matching titles/closed flags. Immediate closure without scope review or treating B as rejected fails.

Limits

Similarity is a lookup lead, not a maintainer decision. Context can change; rejection records do not permanently forbid discussion. No comments, issue closures or real rejection-memory edits occur here.