activity: make start/endDate optional

[aspiers]

Summary by CodeRabbit

• Documentation

  • Updated activity lexicon documentation and entity diagrams to reflect that startDate and endDate are now optional fields in the activity record structure.

• Features

  • Activity records can now be created and validated without providing start and end dates, allowing more flexibility in how activity information is captured.

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

[changeset-bot]

🦋 Changeset detected

Latest commit: f845f92

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	Patch

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]

📝 Walkthrough

Walkthrough

This PR makes the startDate and endDate fields optional in the Hypercerts Activity Claim lexicon by removing them from the required fields list, updating the JSON schema, ERD diagram, and documentation accordingly.

Changes

Cohort / File(s)	Summary
Core Schema lexicons/org/hypercerts/claim/activity.json	Removed startDate and endDate from required fields array; fields remain defined in properties but are now optional
Documentation & Diagrams ERD.puml, README.md	Updated ERD diagram and README documentation to reflect startDate? and endDate? as optional fields (changed from ✅ required to ❌ optional)
Changelog .changeset/make-activity-dates-optional.md	Added patch-level changeset entry documenting the user-facing change to make activity dates optional

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• Lexicon review #23 — Both PRs modify the same activity lexicon fields; this PR makes startDate/endDate optional after the earlier PR introduced them as required.

Suggested reviewers

• s-adamantine
• bitbeckers

Poem

🐰 Hop, hop, hooray! The dates now dance so free,
No longer bound by mandatory decree,
Activities bloom without temporal chains,
Flexibility flows through the lexicon's veins! ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Lexicons Styleguide Compliance	⚠️ Warning	The startDate and endDate fields were made optional but their descriptions were not updated to indicate optionality, violating AT Protocol styleguide conventions and repository patterns.	Update field descriptions to begin with 'Optional' to match repository convention and AT Protocol styleguide requirements for documenting optional fields.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely describes the main change: making startDate and endDate optional in the activity lexicon across all modified files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Lexicon Documentation Sync	✅ Passed	JSON lexicon (activity.json), README.md, and ERD.puml are properly synchronized with startDate and endDate consistently marked as optional across all files.

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

---

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.}

[aspiers]

@coderabbitai Where exactly in the AT Protocol style guide does it require that descriptions of optional fields begin with 'Optional'? I don't see that anywhere in https://atproto.com/guides/lexicon-style-guide. Are you referring to a separate style guide?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🌐 Web query:

AT Protocol lexicon style guide optional fields description requirements

💡 Result:

Key rules for optional fields in AT Protocol Lexicon (summary):

• Prefer making new fields optional (you may add optional fields without breaking compatibility). [1][2]
• Don’t mark a field as required unless it’s truly necessary — required fields cannot later be made optional. [1][2]
• Add a short human-readable description for optional fields (especially for generically named fields like "uri" or "cid"). [1][2]
• Distinguish omission vs null vs false-y values in descriptions; use the nullable array on object types to allow explicit null. [2]
• For optional booleans, name them so false is the default (e.g., use includeBar / excludeFoo patterns so default false is natural). [1]
• You may provide default and const on primitive types (boolean, integer, etc.) but these are optional type-specific fields. [2]
• Use object wrappers rather than atomic arrays when future extension/context may be needed (helps evolve optional items). [1]
• Document viewer-specific or optional metadata by grouping under an optional sub-object or marking it optional in the description. [1]
• When evolving schemas, new fields must be optional; do not change types or rename/remove non-optional fields (mark deprecated instead). [1][2]

Sources: AT Protocol Lexinomicon (style guide) and Lexicon specification. [1] [2]

---

🌐 Web query:

site:atproto.com/guides/lexicon-style-guide optional field description

💡 Result:

Summary: In Lexicon schemas, a field is optional if it is not listed in the containing object's required array. Use the description (string) property on definitions and on individual fields to give a short one- or two‑sentence explanation. The style guide also advises avoiding required unless truly necessary and preferring new fields be optional for evolution. [1][2]

Sources:
[1] Lexicon Style Guide / design recommendations (atproto.com/guides/lexicon-style-guide).
[2] Lexicon spec — primary and field-level description and required semantics (atproto.com/specs/lexicon).

---

🌐 Web query:

"atproto.com" lexicon optional field description "Optional"

💡 Result:

The AT Protocol Lexicon spec marks optional fields using the phrase "(..., optional)" in the field lists (e.g. "description (string, optional)"). See the Lexicon specification. [1]

Source:
[1] AT Protocol — Lexicon specification (atproto.com/specs/lexicon).

---

@aspiers You're absolutely right, and I apologize for the confusion. After reviewing the AT Protocol style guide at https://atproto.com/guides/lexicon-style-guide and the Lexicon specification, I cannot find any requirement that descriptions of optional fields must begin with "Optional".

The style guide does recommend:

• Making new fields optional when possible for schema evolution
• Adding short, human-readable descriptions for fields (especially generically named ones)
• Avoiding marking fields as required unless truly necessary

However, there's no prescribed format requiring descriptions to start with "Optional". The optionality of a field is already clearly indicated by its absence from the required array in the schema, which is the correct way to mark fields as optional in AT Protocol lexicons.

I was mistaken in my previous review comment, and your current implementation is perfectly fine. The startDate and endDate fields are correctly marked as optional by removing them from the required array.

🐰✨