feat: allow for multiple location refs in activity claims - #47
Conversation
📝 WalkthroughWalkthroughReplaces the singular Changes
Sequence Diagram(s)(omitted — change is a schema/documentation update without multi-component control-flow changes) Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested reviewers
Poem
Important Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional. ❌ Failed checks (1 error)
✅ Passed checks (3 passed)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
lexicons/org/hypercerts/claim/activity.json
🧰 Additional context used
📓 Path-based instructions (2)
lexicons/**/*.json
📄 CodeRabbit inference engine (Custom checks)
lexicons/**/*.json: When adding, modifying, or deleting files in lexicons//*.json, update README.md to reflect changes (document new lexicons, update modified properties, remove deleted lexicons from documentation)
When adding, modifying, or deleting files in lexicons//*.json, update ERD.puml if entity relationships changed (add new entities, modify relationships, remove deleted entities)
Verify that lexicon IDs in JSON files match what's documented in README.md
lexicons/**/*.json: After modifying lexicon JSON files, regenerate TypeScript types by runningnpm run gen-api
Lexicon JSON files should follow the ATProto lexicon schema v1 specification
Runnpm run checkbefore committing to validate lexicon syntax and ensure valid lexicon definitions
UpdateERD.pumlwhen modifying lexicon structures to reflect entity relationship changes
UpdateREADME.mddocumentation when adding or modifying lexicon definitions
Organize lexicon files by namespace following the directory structure pattern (e.g.,org/hypercerts/claim/*.json)
Files:
lexicons/org/hypercerts/claim/activity.json
!(types)/**/*.{js,ts,tsx,json,md}
📄 CodeRabbit inference engine (AGENTS.md)
Run
npm run formatwith Prettier before committing to ensure consistent code formatting
Files:
lexicons/org/hypercerts/claim/activity.json
🧠 Learnings (3)
📓 Common learnings
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2025-12-11T15:44:24.397Z
Learning: Applies to lexicons/**/*.json : When adding, modifying, or deleting files in lexicons/**/*.json, update README.md to reflect changes (document new lexicons, update modified properties, remove deleted lexicons from documentation)
📚 Learning: 2025-12-15T10:13:17.689Z
Learnt from: aspiers
Repo: hypercerts-org/hypercerts-lexicon PR: 34
File: lexicons/org/hypercerts/claim/evaluation.json:45-63
Timestamp: 2025-12-15T10:13:17.689Z
Learning: In the hypercerts-lexicon repository, CI automatically runs npm run gen-api and npm run check to regenerate TypeScript types and validate lexicon definitions. Do not include manual reminders to run these commands in code reviews, as CI handles consistency and validation for all lexicon JSON definitions under lexicons/.
Applied to files:
lexicons/org/hypercerts/claim/activity.json
📚 Learning: 2025-12-15T15:33:19.949Z
Learnt from: aspiers
Repo: hypercerts-org/hypercerts-lexicon PR: 37
File: lexicons/org/hypercerts/funding/receipt.json:1-71
Timestamp: 2025-12-15T15:33:19.949Z
Learning: In the hypercerts-lexicon repository, do not comment on Prettier/formatting issues in code reviews since they are reported by the lint workflow. Do not duplicate the lint output in reviews to reduce noise; focus review comments on functional/semantic issues and other non-formatting concerns.
Applied to files:
lexicons/org/hypercerts/claim/activity.json
🪛 GitHub Actions: Lint
lexicons/org/hypercerts/claim/activity.json
[error] 1-1: Prettier formatting check failed. Run 'prettier --write' to fix code style issues.
🪛 GitHub Actions: Validate release (PR)
lexicons/org/hypercerts/claim/activity.json
[error] 1-1: Prettier formatting check failed in 'lexicons/org/hypercerts/claim/activity.json'. Run 'prettier --write lexicons/org/hypercerts/claim/activity.json' to fix code style issues. (format:check)
| "location": { | ||
| "type": "ref", | ||
| "ref": "com.atproto.repo.strongRef", | ||
| "description": "A strong reference to the location where the activity was performed. The record referenced must conform with the lexicon app.certified.location." | ||
| "type": "array", | ||
| "description": "An array of strong references to the location where activity was performed. The record referenced must conform with the lexicon app.certified.location.", | ||
| "items": { | ||
| "type": "ref", | ||
| "ref": "com.atproto.repo.strongRef" | ||
| } | ||
| }, |
There was a problem hiding this comment.
Update README.md and ERD.puml to reflect the schema change.
The location property changed from a single reference to an array, altering the cardinality of the activity-to-location relationship. Per the coding guidelines, both README.md and ERD.puml should be updated:
- README.md: Document that
locationis now an array of strong references supporting multiple locations per activity. - ERD.puml: Update the entity relationship diagram to reflect the new 1-to-many cardinality between activity and location records.
Based on coding guidelines: "When adding, modifying, or deleting files in lexicons/**/*.json, update README.md to reflect changes (document new lexicons, update modified properties, remove deleted lexicons from documentation)" and "update ERD.puml if entity relationships changed."
🤖 Prompt for AI Agents
In lexicons/org/hypercerts/claim/activity.json around lines 71-78, the
"location" property was changed from a single strongRef to an array of
strongRefs; update README.md to document that activity.location is now an array
(supports multiple locations) and revise any examples or schema snippets to show
an array of com.atproto.repo.strongRef items, and update ERD.puml to change the
relationship between Activity and Location from 1-to-1 to 1-to-many (adjust
cardinality notation and any labels) so the docs and diagram reflect the new
cardinality.
Breaking change: single ref → array requires migration strategy.
Changing location from a single strong reference to an array is a breaking change. Existing activity records that contain a single location reference will become invalid against the new schema. Consider:
- Migration path: How will existing records be migrated? Will there be a script to wrap single refs in arrays?
- Backward compatibility: Should there be a transition period supporting both formats via a union type?
- Client impact: All clients reading/writing activity records must be updated simultaneously.
Alternative: Union type for backward compatibility
If backward compatibility during migration is needed, consider a union that accepts both single ref and array:
"location": {
- "type": "array",
- "description": "An array of strong references to the location where activity was performed. The record referenced must conform with the lexicon app.certified.location.",
- "items": {
- "type": "ref",
- "ref": "com.atproto.repo.strongRef"
- }
+ "type": "union",
+ "description": "A strong reference or array of strong references to the location(s) where activity was performed. The record referenced must conform with the lexicon app.certified.location.",
+ "refs": ["com.atproto.repo.strongRef", "#locationArray"]
}Then define locationArray in defs:
"locationArray": {
"type": "array",
"items": {
"type": "ref",
"ref": "com.atproto.repo.strongRef"
}
}This would allow both old (single ref) and new (array) formats during transition, with eventual deprecation of the single-ref variant.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In lexicons/org/hypercerts/claim/activity.json around lines 71-78, the schema
change from a single strongRef for "location" to an array is a breaking change;
update the schema and migration plan by either (1) providing a migration
script/utility to convert existing records by wrapping existing single refs into
single-element arrays and documenting the run procedure, or (2) implement a
backward-compatible union in the schema that accepts either a single ref or an
array (add a "locationArray" def for the array form and make "location" a union
of "ref" and "locationArray"), and communicate a deprecation timeline for the
single-ref variant so clients can be updated gradually.
holkexyz
left a comment
holkexyz
left a comment
There was a problem hiding this comment.
Yes, this makes sense to me. Adding Adam as a reviewer.
aspiers
left a comment
aspiers
left a comment
There was a problem hiding this comment.
@satyam-mishra-pce Please could you fix the linting errors and include doc updates as highlighted by CodeRabbit? Thanks!
🦋 Changeset detectedLatest commit: 0ae8ed0 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
4847309 to
db586a3
Compare
There was a problem hiding this comment.
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 (2)
ERD.puml (1)
56-71: ERD field should reflect array semantics (locations[]?, notlocations?).Right now the
activitydataclass suggests a singular optional field, but the lexicon change is an array. This will diverge from the schema and mislead readers. As per coding guidelines / learnings, ERD should match lexicon structures.Proposed fix
dataclass activity <<largeBold>> #B4E5D0 { !if (SHOW_FIELDS == "true") @@ contributions[]? - locations? + locations[]? rights? project? createdAt !endif }README.md (1)
289-302: README:locationsrow is inconsistent (Type saysref, description says array).This should document
locationsas an optionalarray(of strong refs), otherwise readers will implement the wrong shape. As per coding guidelines, README properties must match the lexicon schema.Proposed fix
-| `locations` | `ref` | ❌ | An array of strong references to the locations where the work for done hypercert was located | References must conform to `app.certified.location` | +| `locations` | `array` | ❌ | Strong references to the location(s) where the activity took place | References must conform to `app.certified.location` |
🧹 Nitpick comments (1)
ERD.puml (1)
305-309: Relationship rename looks right; consider adding multiplicity to make “many locations” obvious.
activity::locations --> locationaligns with the rename. Nice-to-have: annotate cardinality (e.g.,0..*) so the multi-ref intent is clear even when fields are hidden.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
ERD.pumlREADME.md
🧰 Additional context used
📓 Path-based instructions (3)
ERD.puml
📄 CodeRabbit inference engine (Custom checks)
ERD.puml: Ensure that all entities referenced in ERD.puml correspond to lexicons defined in lexicons//*.json
Ensure all relationships shown in ERD.puml are valid based on the JSON lexicon schemas in lexicons//*.json
Verify that entity names in ERD.puml match lexicon IDs (e.g., 'activity' entity should correspond to org.hypercerts.claim.activity lexicon)
Files:
ERD.puml
!(types)/**/*.{js,ts,tsx,json,md}
📄 CodeRabbit inference engine (AGENTS.md)
Run
npm run formatwith Prettier before committing to ensure consistent code formatting
Files:
ERD.pumlREADME.md
README.md
📄 CodeRabbit inference engine (Custom checks)
README.md: Ensure that all lexicons documented in README.md exist as JSON files in the lexicons/ directory
Ensure all properties documented in README.md match the actual JSON schema definitions in lexicons/**/*.json
Files:
README.md
🧠 Learnings (13)
📚 Learning: 2025-12-11T15:44:24.397Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2025-12-11T15:44:24.397Z
Learning: Applies to lexicons/**/*.json : When adding, modifying, or deleting files in lexicons/**/*.json, update ERD.puml if entity relationships changed (add new entities, modify relationships, remove deleted entities)
Applied to files:
ERD.puml
📚 Learning: 2025-12-15T17:53:11.871Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-15T17:53:11.871Z
Learning: Applies to lexicons/**/*.json : Update `ERD.puml` when modifying lexicon structures to reflect entity relationship changes
Applied to files:
ERD.pumlREADME.md
📚 Learning: 2025-12-11T15:44:24.397Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2025-12-11T15:44:24.397Z
Learning: Applies to ERD.puml : Verify that entity names in ERD.puml match lexicon IDs (e.g., 'activity' entity should correspond to org.hypercerts.claim.activity lexicon)
Applied to files:
ERD.puml
📚 Learning: 2025-12-11T15:44:24.397Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2025-12-11T15:44:24.397Z
Learning: Applies to lexicons/**/*.json : When adding, modifying, or deleting files in lexicons/**/*.json, update README.md to reflect changes (document new lexicons, update modified properties, remove deleted lexicons from documentation)
Applied to files:
README.md
📚 Learning: 2025-12-15T17:53:11.871Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-15T17:53:11.871Z
Learning: Applies to lexicons/**/*.json : Update `README.md` documentation when adding or modifying lexicon definitions
Applied to files:
README.md
📚 Learning: 2025-12-11T15:44:24.397Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2025-12-11T15:44:24.397Z
Learning: Applies to lexicons/**/*.json : Verify that lexicon IDs in JSON files match what's documented in README.md
Applied to files:
README.md
📚 Learning: 2025-12-11T15:44:24.397Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2025-12-11T15:44:24.397Z
Learning: Applies to README.md : Ensure all properties documented in README.md match the actual JSON schema definitions in lexicons/**/*.json
Applied to files:
README.md
📚 Learning: 2025-12-15T17:53:11.871Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-15T17:53:11.871Z
Learning: Applies to lexicons/**/*.json : Organize lexicon files by namespace following the directory structure pattern (e.g., `org/hypercerts/claim/*.json`)
Applied to files:
README.md
📚 Learning: 2025-12-11T15:44:24.397Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2025-12-11T15:44:24.397Z
Learning: Applies to README.md : Ensure that all lexicons documented in README.md exist as JSON files in the lexicons/ directory
Applied to files:
README.md
📚 Learning: 2025-12-15T17:53:11.871Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-15T17:53:11.871Z
Learning: Applies to lexicons/**/*.json : Run `npm run check` before committing to validate lexicon syntax and ensure valid lexicon definitions
Applied to files:
README.md
📚 Learning: 2025-12-15T10:13:27.945Z
Learnt from: aspiers
Repo: hypercerts-org/hypercerts-lexicon PR: 34
File: lexicons/org/hypercerts/claim/evaluation.json:45-63
Timestamp: 2025-12-15T10:13:27.945Z
Learning: For the hypercerts-lexicon repository, CI automatically runs `npm run gen-api` and `npm run check` to regenerate TypeScript types and validate lexicon definitions, so manual reminders about running these commands are not needed in code reviews.
Applied to files:
README.md
📚 Learning: 2025-12-11T15:44:24.397Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2025-12-11T15:44:24.397Z
Learning: Applies to ERD.puml : Ensure that all entities referenced in ERD.puml correspond to lexicons defined in lexicons/**/*.json
Applied to files:
README.md
📚 Learning: 2025-12-15T16:39:23.964Z
Learnt from: aspiers
Repo: hypercerts-org/hypercerts-lexicon PR: 39
File: README.md:17-17
Timestamp: 2025-12-15T16:39:23.964Z
Learning: In the hypercerts-lexicon repository, standardize on the hyphenless spelling 'onchain' across Markdown documentation (e.g., README.md and other md files) to match the industry standard. Update any occurrences of 'on-chain' to 'onchain' and ensure consistency throughout all documentation.
Applied to files:
README.md
cfb98d4 to
37b27ec
Compare
Every organization would have some sites (aka location records) in their organization. They should be able to choose multiple of these sites or location records, at the time of creation of an activity claim. Until now, we thought the following solution is best: Fetch the sites in the organization → Merge into a single feature collection → Regenerate a single geojson → Upload as location lexicon. But it poses some problems: - This creates an additional “location” record in the repository. Apps might be using this lexicon to display all the sites in an organization, and an additional record with the same data would just add redundancy. - Location lexicon has some required properties, like `createdAt`, `srs`, `lpVersion`, etc… which might be important for the sites if they exist individually. Creating a new location lexicon would REQUIRE those properties, and would also lead to loss of information holded by the individual sites. Other unrequired fields, such as “name” that exist for individual location records would also be lost. - Most importantly, the new aggregated location record just created, would not be able to reference to the other stuff that the individual location records did. For example, if there is a relationship defined between a project and a location record, it would be lost if we just create a new location record with the same geojson data. - Changes in the location record, such as “name” of the site.. won’t be synced once the claim activity is created. Therefore, we propose a solution where the `location` property in the `activity` record holds an array of multiple `location` refs. This would solve all the problems listed so far.. and doesn’t seem to have any downsides.
We don't use bun in this repo. This was accidentally added a while ago.
37b27ec to
0ae8ed0
Compare
|
@satyam-mishra-pce To keep the git history clean I extracted the bunb.lock deletion into a separate commit, and squashed all the other changes into one commit, since they are all part of the same logical change. |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @README.md:
- Line 300: Update the documentation row for the `locations` field: change the
Type column from `ref` to `array`, and replace the current description with the
schema-accurate text such as "An array of strong references to the location
where activity was performed. The record referenced must conform with the
lexicon app.certified.location." Ensure the README entry for `locations` matches
the JSON schema semantics (array of refs) and the references constraint.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
bun.lockbis excluded by!**/bun.lockb
📒 Files selected for processing (4)
.changeset/sparkly-doors-bet.mdERD.pumlREADME.mdlexicons/org/hypercerts/claim/activity.json
🚧 Files skipped from review as they are similar to previous changes (2)
- .changeset/sparkly-doors-bet.md
- lexicons/org/hypercerts/claim/activity.json
🧰 Additional context used
📓 Path-based instructions (3)
ERD.puml
📄 CodeRabbit inference engine (Custom checks)
ERD.puml: Ensure that all entities referenced in ERD.puml correspond to lexicons defined in lexicons//*.json
Ensure all relationships shown in ERD.puml are valid based on the JSON lexicon schemas in lexicons//*.json
Verify that entity names in ERD.puml match lexicon IDs (e.g., 'activity' entity should correspond to org.hypercerts.claim.activity lexicon)
Files:
ERD.puml
!(types)/**/*.{js,ts,tsx,json,md}
📄 CodeRabbit inference engine (AGENTS.md)
Run
npm run formatwith Prettier before committing to ensure consistent code formatting
Files:
ERD.pumlREADME.md
README.md
📄 CodeRabbit inference engine (Custom checks)
README.md: Ensure that all lexicons documented in README.md exist as JSON files in the lexicons/ directory
Ensure all properties documented in README.md match the actual JSON schema definitions in lexicons/**/*.json
Files:
README.md
🧠 Learnings (12)
📚 Learning: 2025-12-11T15:44:24.397Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2025-12-11T15:44:24.397Z
Learning: Applies to lexicons/**/*.json : When adding, modifying, or deleting files in lexicons/**/*.json, update ERD.puml if entity relationships changed (add new entities, modify relationships, remove deleted entities)
Applied to files:
ERD.puml
📚 Learning: 2025-12-15T17:53:11.871Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-15T17:53:11.871Z
Learning: Applies to lexicons/**/*.json : Update `ERD.puml` when modifying lexicon structures to reflect entity relationship changes
Applied to files:
ERD.pumlREADME.md
📚 Learning: 2025-12-11T15:44:24.397Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2025-12-11T15:44:24.397Z
Learning: Applies to ERD.puml : Verify that entity names in ERD.puml match lexicon IDs (e.g., 'activity' entity should correspond to org.hypercerts.claim.activity lexicon)
Applied to files:
ERD.pumlREADME.md
📚 Learning: 2025-12-11T15:44:24.397Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2025-12-11T15:44:24.397Z
Learning: Applies to lexicons/**/*.json : Verify that lexicon IDs in JSON files match what's documented in README.md
Applied to files:
README.md
📚 Learning: 2025-12-11T15:44:24.397Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2025-12-11T15:44:24.397Z
Learning: Applies to lexicons/**/*.json : When adding, modifying, or deleting files in lexicons/**/*.json, update README.md to reflect changes (document new lexicons, update modified properties, remove deleted lexicons from documentation)
Applied to files:
README.md
📚 Learning: 2025-12-11T15:44:24.397Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2025-12-11T15:44:24.397Z
Learning: Applies to README.md : Ensure all properties documented in README.md match the actual JSON schema definitions in lexicons/**/*.json
Applied to files:
README.md
📚 Learning: 2025-12-15T17:53:11.871Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-15T17:53:11.871Z
Learning: Applies to lexicons/**/*.json : Update `README.md` documentation when adding or modifying lexicon definitions
Applied to files:
README.md
📚 Learning: 2025-12-15T17:53:11.871Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-15T17:53:11.871Z
Learning: Applies to lexicons/**/*.json : Organize lexicon files by namespace following the directory structure pattern (e.g., `org/hypercerts/claim/*.json`)
Applied to files:
README.md
📚 Learning: 2025-12-11T15:44:24.397Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2025-12-11T15:44:24.397Z
Learning: Applies to README.md : Ensure that all lexicons documented in README.md exist as JSON files in the lexicons/ directory
Applied to files:
README.md
📚 Learning: 2025-12-15T17:53:11.871Z
Learnt from: CR
Repo: hypercerts-org/hypercerts-lexicon PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-15T17:53:11.871Z
Learning: Applies to lexicons/**/*.json : Run `npm run check` before committing to validate lexicon syntax and ensure valid lexicon definitions
Applied to files:
README.md
📚 Learning: 2025-12-15T10:13:27.945Z
Learnt from: aspiers
Repo: hypercerts-org/hypercerts-lexicon PR: 34
File: lexicons/org/hypercerts/claim/evaluation.json:45-63
Timestamp: 2025-12-15T10:13:27.945Z
Learning: For the hypercerts-lexicon repository, CI automatically runs `npm run gen-api` and `npm run check` to regenerate TypeScript types and validate lexicon definitions, so manual reminders about running these commands are not needed in code reviews.
Applied to files:
README.md
📚 Learning: 2025-12-15T16:39:23.964Z
Learnt from: aspiers
Repo: hypercerts-org/hypercerts-lexicon PR: 39
File: README.md:17-17
Timestamp: 2025-12-15T16:39:23.964Z
Learning: In the hypercerts-lexicon repository, standardize on the hyphenless spelling 'onchain' across Markdown documentation (e.g., README.md and other md files) to match the industry standard. Update any occurrences of 'on-chain' to 'onchain' and ensure consistency throughout all documentation.
Applied to files:
README.md
🪛 LanguageTool
README.md
[style] ~302-~302: This phrase is redundant. Consider writing “created”.
Context: ...declared timestamp when this record was originally created | ...
(ORIGINALLY_CREATED)
🔇 Additional comments (1)
ERD.puml (1)
66-66: LGTM!The field rename from
location?tolocations[]?and the updated relationshipactivity::locations --> locationcorrectly reflect the schema change to support multiple location references. The array notation[]and optional marker?are consistent with the lexicon definition.Also applies to: 307-307
| | `endDate` | `string` | ✅ | When the work ended | | | ||
| | `contributions` | `array` | ❌ | A strong reference to the contributions done to create the impact in the hypercerts | References must conform to `org.hypercerts.claim.contribution` | | ||
| | `rights` | `ref` | ❌ | A strong reference to the rights that this hypercert has | References must conform to `org.hypercerts.claim.rights` | | ||
| | `locations` | `ref` | ❌ | An array of strong references to the locations where the work for done hypercert was located | References must conform to `app.certified.location` | |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat lexicons/org/hypercerts/claim/activity.json | jq '.defs.main.record.properties.locations'Repository: hypercerts-org/hypercerts-lexicon
Length of output: 347
Type column should be array, not ref, and the description must match the actual JSON schema.
The Type column currently shows ref, but the JSON schema defines locations as type: "array" with items of type ref. Additionally, the description in README doesn't match the actual schema. The schema states: "An array of strong references to the location where activity was performed. The record referenced must conform with the lexicon app.certified.location."
Proposed fix
-| `locations` | `ref` | ❌ | An array of strong references to the locations where the work for done hypercert was located | References must conform to `app.certified.location` |
+| `locations` | `array` | ❌ | An array of strong references to the location where activity was performed. The record referenced must conform with the lexicon app.certified.location. | |🤖 Prompt for AI Agents
In @README.md at line 300, Update the documentation row for the `locations`
field: change the Type column from `ref` to `array`, and replace the current
description with the schema-accurate text such as "An array of strong references
to the location where activity was performed. The record referenced must conform
with the lexicon app.certified.location." Ensure the README entry for
`locations` matches the JSON schema semantics (array of refs) and the references
constraint.
Thanks. I'll remember in future to squash commits that fall under one logical change. |
|
@satyam-mishra-pce commented on Jan 15, 2026, 4:18 PM GMT+11:
Great thanks, that will make reviewing a lot easier! And also keep the git history easier to follow in the long term. |
3 participants
Every organization would have some sites (aka location records) in their organization. They should be able to choose multiple of these sites or location records, at the time of creation of an activity claim.
Until now, we thought the following solution is best:
Fetch the sites in the organization → Merge into a single feature collection → Regenerate a single geojson → Upload as location lexicon.
But it poses some problems:
createdAt,srs,lpVersion, etc… which might be important for the sites if they exist individually. Creating a new location lexicon would REQUIRE those properties, and would also lead to loss of information holded by the individual sites. Other unrequired fields, such as “name” that exist for individual location records would also be lost.Therefore, we propose a solution where the
locationproperty in theactivityrecord holds an array of multiplelocationrefs. This would solve all the problems listed so far.. and doesn’t seem to have any downsides.Summary by CodeRabbit
New Features
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.