add weights to items of a collection and delete activityWeights in ac…

[holkexyz]

…tivity claim

Summary by CodeRabbit

• Breaking Changes

  • Collection entries now use an object with a required item identifier and an optional per-item weight (replaces prior flat references).
  • Contributor role no longer includes the previous per-activity weight field, affecting contributor data shape.
  • Evaluation schema properties have been streamlined and adjusted.

• New Features

  • Collections can nest other collections recursively.
  • Optional per-item weights enable expressing relative importance within collections.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[changeset-bot]

🦋 Changeset detected

Latest commit: c3f9ca2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@hypercerts-org/lexicon	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coderabbitai]

Caution

Review failed

The pull request is closed.

📝 Walkthrough

Walkthrough

Replaces collection item arrays of strongRefs with item objects that include itemIdentifier and optional itemWeight; removes activityWeight from contributorRole in the activity lexicon. Adds a new changeset documenting the item-weight refactor and migration guidance.

Changes

Cohort / File(s)	Summary
Changesets \.changeset/refactor-collection-items-array.md, \.changeset/add-collection-item-weights.md	Removed an old changeset and added a new one documenting collection item weights, migration guidance, and removal of activityWeight.
Activity Schema lexicons/org/hypercerts/claim/activity.json	Deleted activityWeight from defs/contributorRole (removed the nested { activity, weight } object).
Collection Schema lexicons/org/hypercerts/claim/collection.json, SCHEMAS.md	Changed main.items from com.atproto.repo.strongRef to reference a new #item object; added public item Def with required itemIdentifier (strongRef) and optional itemWeight (string); updated descriptions to note optional weights and recursive nesting.

Sequence Diagram(s)

(omitted — changes are schema/refactor-only and do not introduce multi-component control flow)

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• adding project schema (and keeping collections consistent) #33 — Directly overlaps changes to collection item representation and activity weight handling.
• Project as collection sidecar #78 — Prior edits to org.hypercerts.claim.collection items and related refactor decisions.
• Lexicon review #23 — Overlapping edits to activity and collection lexicons around item/weight structures.

Suggested reviewers

• s-adamantine
• bitbeckers

Poem

🐇 I hopped through schemas, light and spry,
Swapped flat refs for items that tie.
Weights tucked softly, small and neat,
Collections nest with quiet beat.
A tiny hop — lexicon complete!

---

Important

Pre-merge checks failed

Please resolve all errors before merging. Addressing warnings is optional.

❌ Failed checks (1 error, 1 warning)

Check name	Status	Explanation	Resolution
Lexicon Documentation Sync	❌ Error	Documentation files are out of sync with lexicon changes. SCHEMAS.md still documents activityWeight and outdated collection items structure.	Regenerate SCHEMAS.md from lexicon definitions to capture changes and update README.md examples to reflect new collection items structure with optional weights.
Lexicons Styleguide Compliance	⚠️ Warning	The pull request introduces a new item definition in collection.json that violates the ATProto lexicon styleguide by lacking a description at the object definition level.	Add a description field to the item object definition in collection.json explaining what the item represents and its contained properties.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main changes: adding item weights to collections and removing activity weights, which directly aligns with the primary modifications across the changeset files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

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]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

lexicons/org/hypercerts/claim/collection.json (1)

50-80: Add item object documentation to SCHEMAS.md

SCHEMAS.md documents the collection's items field but lacks the nested item object structure. Add a section documenting the item object properties (itemIdentifier as required strongRef, itemWeight as optional string) to clarify the new array structure. ERD.puml could also be enhanced to show the itemWeight field for completeness.

The changeset file properly documents the breaking change.

🤖 Fix all issues with AI agents

In @.changeset/refactor-collection-items-array.md:
- Around line 5-16: Update the changeset to also document the breaking change
that removes activityWeights from the activity claim: state that the
`org.hypercerts.claim.activity` schema no longer includes the `activityWeights`
field (remove references to it), and add migration guidance instructing
consumers to migrate existing `activityWeights` data (e.g., convert it to the
new per-item `itemWeight` in collections or drop/transform values as
appropriate), referencing the new `org.hypercerts.claim.collection#item`
structure and `itemIdentifier`/`itemWeight` keys so integrators know how to map
old activityWeights to the new format.

🧹 Nitpick comments (1)

lexicons/org/hypercerts/claim/collection.json (1)

75-78: Consider validating itemWeight as a positive numeric string.

Right now any string is accepted. If you want schema-level validation, add a regex pattern (and optionally minLength) to prevent empty/negative values.

♻️ Example schema tightening

         "itemWeight": {
           "type": "string",
+          "minLength": 1,
+          "pattern": "^(?:0|[1-9]\\d*)(?:\\.\\d+)?$",
           "description": "Optional weight for this item (positive numeric value stored as string). Weights do not need to sum to a specific total; normalization can be performed by the consuming application as needed."
         }

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

lexicons/org/hypercerts/claim/collection.json (1)

1-81: Update README.md and ERD.puml documentation to reflect the new item object structure with weights.

The README.md examples (lines 194–280) show outdated code where items is an array of direct references with uri and cid fields. The actual schema now requires items to be an array of item objects, each with:

• itemIdentifier (strongRef to activity or collection)
• itemWeight (optional string for weighting items)

Additionally, itemWeight is not documented anywhere in README.md, and ERD.puml does not reflect the item object wrapper around these fields. Update both files to match the current schema definition in collection.json.

🧹 Nitpick comments (1)

lexicons/org/hypercerts/claim/collection.json (1)

66-79: Consider adding a pattern constraint for itemWeight validation.

The description states itemWeight should be a "positive numeric value stored as string", but there's no pattern constraint to enforce this. Without validation, invalid values like "abc" or "-5" could be stored.

♻️ Suggested pattern constraint

         "itemWeight": {
           "type": "string",
-          "description": "Optional weight for this item (positive numeric value stored as string). Weights do not need to sum to a specific total; normalization can be performed by the consuming application as needed."
+          "description": "Optional weight for this item (positive numeric value stored as string). Weights do not need to sum to a specific total; normalization can be performed by the consuming application as needed.",
+          "pattern": "^(0|[1-9][0-9]*)(\\.[0-9]+)?$"
         }

If validation is intentionally left to consuming applications, this can be ignored.