feat(classifier): add R31 abstract modifier added rule

[Aakif-Kohari]

Summary

Adds classification rule R31: Abstract Modifier Added.

• src/classifier/rules/R31_abstract_modifier_added.ts — new rule, flags when a concrete method gains the abstract modifier (concrete → abstract only; the reverse direction is safe and not flagged).
• src/classifier/rules/index.ts — exports the new rule.
• tests/rules/function-rules.test.ts — 4 new test cases (true positive, safe reverse direction, both-concrete, undefined/undefined edge case).
• tests/e2e/ast-e2e.test.ts — 1 new E2E case through the full WASM parse → classify pipeline.
• README.md, CONTRIBUTING.md — rule count bumped to 29.
• client/src/components/Terminal.tsx, client/src/components/docs/DocsSidebar.tsx, client/src/content/docs/cli-rules.tsx, client/src/content/docs/rules-data.ts — docs site updated with the new rule entry.

No new dependencies. isAbstract was already populated by every language translator (TypeScript, Python, Go, Java, Rust) — this PR only adds the missing rule that consumes it.

I have solved this Issue under ECSoC26.

Closes #29

Testing

• npm test passes (all existing + 5 new tests)
• npm run lint passes
• npm run build succeeds
• Manual npx dg check verified on a throwaway abstract-conversion diff — fires correctly on concrete→abstract, silent on abstract→concrete

Breaking changes

None to the tool itself — this only adds new detection coverage.

[vercel]

@Aakif-Kohari is attempting to deploy a commit to the Aryan Gupta's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Aryan0628]

Note: Tracking "Abstract → Concrete" as an Advisory Change

PR 32 correctly identifies when a method goes from concrete → abstract and flags it as a breaking change. However, it currently ignores the reverse direction (abstract → concrete) entirely by returning null, meaning the change is completely silent in our reports.

The Issue
While abstract → concrete is a safe, backwards-compatible change, it is still a notable API behavioral change. Developers downstream might want to know that a default implementation is now provided so they can optionally delete their boilerplate overrides.

The Approach
Since Diff-Guardian's architecture natively supports safe and warning severities, we don't need a new rule. We just need to update the logic in R31_abstract_modifier_added.ts to actively return an advisory result for the reverse direction instead of falling through to null.

After making this minor change, i will merge your PR.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
diffguardian	Ready	Preview, Comment	Jul 13, 2026 4:25am

[Aakif-Kohari]

@Aryan0628 Good catch, agreed - makes sense to surface it rather than drop it silently. Updated R31_abstract_modifier_added.ts to return a safe-severity advisory result on the abstract → concrete direction, with a message pointing out that existing overrides are now optional. Updated the doc comment and swapped the now-inaccurate "must return null" test for one asserting the new advisory result. Pushed as a separate commit so the original logic and this follow-up stay easy to review independently.