feat: expert category tagging

[arandomogg]

Summary

• Add category_id u32 field to ExpertRecord in types, storage, contract, and lib
• add_expert and update_profile now accept category_id parameter
• batch_update_profiles tuple extended to include category_id
• category_id preserved across ban/unban operations
• New test test_category_id_persisted_and_updated covers full lifecycle

Closes #41

Test plan

• All 30 existing tests pass with updated signatures
• New test verifies category_id persistence through add, update, ban, unban

Summary by CodeRabbit

• New Features
  • Expert profiles now support category assignment through a new category ID parameter during verification and profile updates
  • Batch operations for profile updates now include category metadata for each expert record
  • Category information persists with profile data through all profile operations

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR adds a category_id field to expert records, enabling experts to be categorizable by numerical tags. All functions in the contract, storage, and public API layers are updated to accept and persist this new field, with comprehensive test coverage including persistence verification across various operations.

Changes

Cohort / File(s)	Summary
Data Model contracts/identity-registry-contract/src/types.rs	Added category_id: u32 field to ExpertRecord struct to support expert categorization.
Storage Layer contracts/identity-registry-contract/src/storage.rs	Updated set_expert_record signature to accept category_id: u32 parameter and persist it in stored records; default initialization set to 0 for missing entries.
Contract Logic contracts/identity-registry-contract/src/contract.rs	Updated verify_expert, update_profile, and batch_update_profiles to accept and forward category_id to storage; batch operations now expect tuples (Address, String, u32, u32) with category_id as final element.
Public API contracts/identity-registry-contract/src/lib.rs	Extended add_expert, update_profile, and batch_update_profiles wrapper methods with category_id: u32 parameter; forwarded to corresponding contract::* functions.
Tests contracts/identity-registry-contract/src/test.rs	Updated all expert creation and profile update test calls to include category_id argument; added new test_category_id_persisted_and_updated to verify category_id persistence across add, update, ban, and unban operations.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• feat(admin): implement expert verification whitelist gatekeeper #9: Modifies verify_expert logic in contract.rs (adds admin-gated verification) and may conflict with the category_id signature changes.
• feat(identity-registry): implement Expert Directory enumeration (#25) #28: Modifies verify_expert in contract.rs (adds index storage calls) and requires coordination with category_id parameter threading.
• Implement "Expert Metadata" (Profile Data)  #21: Changes core expert metadata persistence patterns in types.rs and storage functions, similar data model extension approach.

Suggested reviewers

• Bosun-Josh121

Poem

🐰 A carrot-sized category comes to play,
Threading through contracts, save the day!
Experts tagged with numbers bright,
Storage keeps them snug and tight!
From API down to the database gate,
Our little rabbit counts them straight! 🥕

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	The description covers the key changes but does not follow the required template format with checkboxes, type of change selection, or evidence section.	Use the template structure with checkboxes for applied items, select type of change, and include evidence (test results or logs).

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'feat: expert category tagging' accurately and concisely summarizes the primary change: adding category tagging functionality to the expert system.
Linked Issues check	✅ Passed	All objectives from issue #41 are met: category_id field added to ExpertRecord, verify_expert and update_profile accept category_id, lib.rs signatures updated, and tests verify category persistence across operations.
Out of Scope Changes check	✅ Passed	All changes are directly related to implementing expert category tagging as specified in issue #41; no unrelated modifications were introduced.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

contracts/identity-registry-contract/src/contract.rs (1)

224-257: Consider adding documentation for the tuple field order.

The tuple (Address, String, u32, u32) represents (expert, uri, status, category_id). While the code is correct, the field order isn't immediately obvious to callers.

📝 Suggested documentation improvement

 /// Batch update expert profiles (Admin only)
 /// Allows admins to update multiple expert metadata URIs in a single transaction
+/// Each tuple is (expert_address, new_uri, status_u32, category_id)
 pub fn batch_update_profiles(
     env: &Env,
     updates: Vec<(Address, String, u32, u32)>,
 ) -> Result<(), RegistryError> {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@contracts/identity-registry-contract/src/contract.rs` around lines 224 - 257,
The tuple parameter in batch_update_profiles is ambiguous to callers—document
the expected field order (Address, String, u32, u32) as (expert, uri, status,
category_id) by adding a doc comment above the batch_update_profiles function
(or replace the tuple with a named type like ProfileUpdate or a type alias) so
callers clearly understand the parameter ordering; reference the function name
batch_update_profiles and the tuple used in its signature so reviewers can
locate and update the API docs or refactor to a named struct for clarity.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@contracts/identity-registry-contract/src/contract.rs`:
- Around line 224-257: The tuple parameter in batch_update_profiles is ambiguous
to callers—document the expected field order (Address, String, u32, u32) as
(expert, uri, status, category_id) by adding a doc comment above the
batch_update_profiles function (or replace the tuple with a named type like
ProfileUpdate or a type alias) so callers clearly understand the parameter
ordering; reference the function name batch_update_profiles and the tuple used
in its signature so reviewers can locate and update the API docs or refactor to
a named struct for clarity.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 4dfa7123-361e-447c-b9da-847c141b06fc

📥 Commits

Reviewing files that changed from the base of the PR and between 2482d34 and ba46f93.

📒 Files selected for processing (5)

• contracts/identity-registry-contract/src/contract.rs
• contracts/identity-registry-contract/src/lib.rs
• contracts/identity-registry-contract/src/storage.rs
• contracts/identity-registry-contract/src/test.rs
• contracts/identity-registry-contract/src/types.rs