feat(rules): add Objective-C-specific review rules

[Qiyuanqiii]

Description

Summary

• Replace the 22-line generic Objective-C checklist with language-specific review guidance.
• Establish a precision-first review contract that distinguishes blocking correctness findings from non-blocking style and modernization advice.
• Cover concrete Objective-C failure modes across ownership, runtime dispatch, Foundation, concurrency, observation, C interoperability, secure coding, and tests.
• Add explicit context checks and false-positive guardrails for ARC versus MRC, weak references, optional protocol methods, availability, KVO teardown, and trusted archives.
• Leave .m content sniffing, resolver precedence, and user-defined rule behavior unchanged.

Why This Change

PR #574 added content sniffing so .m files can be routed to either MATLAB or Objective-C rules. The routing works, but objc.md remained effectively identical to default.md; an Objective-C diff or full-file scan therefore received no guidance about defects specific to the language or Cocoa runtime.

This change makes the existing Objective-C route useful for repositories that do not define a project rule, while preserving the current system-layer fallback behavior.

Rule Coverage

Area	Representative defect patterns
Memory and lifetime	ARC/MRC ownership, retain cycles, block captures, weak-reference lifetime, timer teardown, property semantics
Runtime and API contracts	Initializer chains, optional protocols, selector ABI, category conflicts, method swizzling, deployment-target availability
Foundation and errors	Nil messaging, NSNull, collection exceptions, ranges and strings, format arguments, NSError **, exceptions
Concurrency and observation	GCD deadlocks, main-thread UI access, unstable lock identity, Core Data confinement, KVC/KVO, notification delivery
Interoperability and trust boundaries	Core Foundation bridging, C callback contexts and buffers, secure unarchiving, dynamic selectors
Test correctness	Objective-C object equality assertions, asynchronous completion, deallocation checks, exception-versus-error expectations

Precision and Classification

The preamble follows the same high-precision approach as matlab.md:

• Respect the active scope: review changed lines in diff-based review and the supplied file in full-file scan mode; report only defects with a concrete runtime consequence.
• Use repository context to verify ownership, build mode, API contracts, queue use, lifecycle, and deployment targets before reporting non-local behavior.
• Treat crashes, use-after-free, persistent leaks, data corruption, security failures, races, and deadlocks as blocking.
• Treat naming, modernization, style, and speculative performance advice as non-blocking.
• Avoid repeating compiler or static-analyzer diagnostics unless the change creates a demonstrable runtime failure.

Each section also includes scoped Do not report guidance where a common Objective-C pattern is valid under some build modes or lifecycle contracts.

Compatibility

• Only internal/config/rules/rule_docs/objc.md changes.
• The .m sniffer and system_rules.json mappings are unchanged.
• Project, global, and custom rules retain their existing precedence over the system layer.
• No command-line, configuration, public API, or persisted-data format changes are introduced.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that causes existing functionality to change)
• Refactoring (no functional changes)
• Documentation update
• CI / Build / Tooling

How Has This Been Tested?

Validation Environment

• OS: Windows 25H2 (OS build 26200.9168), amd64
• Go: go1.26.5 windows/amd64
• Base: cfbb62e (origin/main)

Automated Validation

• Final targeted race test passed: go test -race -count=1 ./internal/config/rules
• The full make test equivalent passed for every package returned by go list ./..., excluding /extensions/: go test -p 1 -v -race -count=1 ...
• Project coverage passed at 90.6%; internal/config/rules coverage was 91.7%
• All constituent make check commands passed: license check, English-only check, go mod tidy, gofmt -s -w ., and go vet across the same package set
• git diff --check passed, and the modified file is UTF-8 without BOM and uses LF line endings
• Repository-required OCR review completed with full manifest coverage: 1 item selected, 1 completed, 0 failed, and all 5 reported comments manually validated

GNU Make is unavailable on the validation host, so the Makefile commands were run directly. The initial full race run exhausted host memory during parallel compilation; the same package set then passed with package parallelism limited to one. Race detection, cache bypass, and test scope remained unchanged.

The repository-required OCR review completed successfully with --audience agent --effort high against the full origin/main..HEAD Objective-C document change. It selected and completed the single changed item without coverage failures and reported five comments. Each comment was validated before editing. The OCR findings led to mode-independent defect wording, clearer weak-capture and format-string rules, and an explicit typed-decoding requirement for NSSecureCoding. The subsequent terminology review aligned category collisions with Apple's documented undefined-behavior contract, standardized the Core Foundation Create Rule and Get Rule names, separated callback function-pointer compatibility from object-context bridging, and corrected stale KVC wording.

DeepSeek rejected the optional comment-filter request. Thinking mode does not support the tool_choice parameter required by that request. This non-fatal provider limitation did not affect the completed core review or manifest coverage, and all five unfiltered comments were reviewed manually.

Checklist

• My changes follow the project's documentation structure and review-rule style
• I have performed a line-by-line self-review
• Existing integrity tests cover the embedded rule document; no executable behavior or new code path requires an additional unit test
• New and existing unit tests pass locally with the final content
• The relevant documentation is updated
• I have signed the CLA

Known Limitations

• ARC mode, per-file compiler flags, deployment targets, and lifecycle ownership may require repository context outside the reviewed file. The rule preamble directs the reviewer to verify that context and remain silent when it is unavailable.

Related Issues

Closes #1060.

[github-actions]

✅ OpenCodeReview: Review skipped: no items were selected.

[Qiyuanqiii]

Focused terminology and technical-writing self-review against the current head.

The problem statement in Why This Change is clear: Objective-C routing already works, but the routed rule remained a generic checklist and therefore lacked Objective-C-specific guidance. I could not, however, confirm that the revised text is fully terminology-clean yet. The inline comments identify three technical wording issues that can affect reviewer behavior and two smaller English usage issues.

PR-description follow-ups:

• This Markdown file is embedded and loaded as a runtime review rule, so the change alters reviewer behavior. New feature (and likely feat(rules)) describes the impact more accurately than Documentation update / docs(rules).
• Move XCTest assertions out of the Interoperability and trust boundaries row into a separate Test correctness row.
• Prefer main-thread UI access, unstable lock identity, and deployment-target availability over the less specific UI isolation, unstable locks, and deployment availability.
• Rewrite the DeepSeek sentence as: “Thinking mode does not support the tool_choice parameter required by that request.” This removes the ambiguous antecedent in “its required tool_choice.”

Submitted as a commented self-review; the author cannot approve their own pull request.

[Qiyuanqiii]

Addressed the PR-level follow-ups alongside the inline fixes in 23c577b:

• Reclassified the change as a new feature and changed the PR title to feat(rules) to reflect the runtime effect of the embedded rule.
• Moved XCTest guidance into a separate Test correctness row.
• Replaced the broad terms with deployment-target availability, main-thread UI access, and unstable lock identity.
• Reworded the DeepSeek note to identify the unsupported tool_choice parameter without an ambiguous antecedent.

The five inline comments have individual replies with the corresponding changes.

[Qiyuanqiii]

I’ve finished my review; it is ready for you to look at now. If there are any issues, I will get up and handle them around noon.

[Qiyuanqiii]

Conflicts between my previously‑submitted PRs, namely #1009, #1010, #1015, #1021 and #1030, and the latest main branch have all been resolved. I think it’s time for me to get some sleep.

[lizhengfeng101]

LGTM

[Qiyuanqiii]

Thanks — I applied the suggestion first so that we can discuss the concrete wording. Could I confirm a few details about the intended contract?

1. The current code_comment schema says that existing_code should contain only newly added lines, not unchanged or deleted lines. Although the resolver can match unchanged file content, an unchanged line outside a GitHub diff hunk may still fail to post inline. Is the Objective-C rule intended to override that schema, or should unchanged lines remain supporting evidence while existing_code anchors the comment to relevant added code?

2. Should every reachable crash, leak, race, or deadlock always be classified as critical or high, or should severity still be calibrated to demonstrated reachability and impact? For example, some bounded leaks or narrowly reachable races may be medium, while critical might be reserved for exceptional impact.

3. The repository already has RelocateAcrossFiles for unique cross-file matches. Is “Do not quote code from a different file” intended to prohibit cross-file evidence entirely, or only to require that path and existing_code identify the same subject file?

4. Since the existing_code, path, category, and severity requirements apply to every language, would it be safer to keep this contract in the central prompt/tool schema and leave objc.md focused on Objective-C-specific behavior? That would reduce the chance of the language rule drifting from future schema or publisher changes.

I am happy to retain the applied wording if these are deliberate policy choices; I mainly want to ensure the rule, tool schema, resolver, and GitHub publisher describe the same behavior.

[lizhengfeng101]

Thanks — I applied the suggestion first so that we can discuss the concrete wording. Could I confirm a few details about the intended contract?

1. The current code_comment schema says that existing_code should contain only newly added lines, not unchanged or deleted lines. Although the resolver can match unchanged file content, an unchanged line outside a GitHub diff hunk may still fail to post inline. Is the Objective-C rule intended to override that schema, or should unchanged lines remain supporting evidence while existing_code anchors the comment to relevant added code?
2. Should every reachable crash, leak, race, or deadlock always be classified as critical or high, or should severity still be calibrated to demonstrated reachability and impact? For example, some bounded leaks or narrowly reachable races may be medium, while critical might be reserved for exceptional impact.
3. The repository already has RelocateAcrossFiles for unique cross-file matches. Is “Do not quote code from a different file” intended to prohibit cross-file evidence entirely, or only to require that path and existing_code identify the same subject file?
4. Since the existing_code, path, category, and severity requirements apply to every language, would it be safer to keep this contract in the central prompt/tool schema and leave objc.md focused on Objective-C-specific behavior? That would reduce the chance of the language rule drifting from future schema or publisher changes.

I am happy to retain the applied wording if these are deliberate policy choices; I mainly want to ensure the rule, tool schema, resolver, and GitHub publisher describe the same behavior.

I believe the rule definitions can be guided by the agent's capability boundaries, but they should not be tightly coupled to the agent's internal details; otherwise, this creates a reverse dependency where the agent relies on the rule definitions, which hinders future iteration.