Calendar entry titles render primary field as editable cell, matching Board

[brylie]

Summary

Resolves the UX call raised in #105: Calendar entries (scheduled and unscheduled) now show the Collection's resolved primary field as a directly-editable PropertyValueCell, mirroring Board's existing card-title behavior, instead of always rendering static text.

• Calendar's entries already supported inline editing for the date property, so this extends an established interaction pattern to the title rather than introducing a new one.
• Mirrors Board's titleEditableViaCell collision handling (issue Board/Calendar: primary field and groupBy can point at the same field, showing redundant controls #104): when the primary field is also the date property driving groupBy, the title falls back to the existing plain, non-editable label instead of showing a second, redundant editable control for the same value (the date PropertyValueCell already covers it).
• Updated docs/specifications/collection-views.md §4 and §7 to document the decision and the shared collision-handling behavior across Board and Calendar.
• Added Calendar component tests covering: editing a scheduled entry's title inline, editing an unscheduled entry's title inline, and the groupBy-collision fallback rendering a single editable control.

Closes #105

Test plan

• npm run test — 1282 tests pass
• npm run lint
• npm run check
• Full pre-push suite (lint, check, coverage, build, e2e) passed locally

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Calendar entries now display the primary field as an inline editable value.
  • Inline editing is available for both scheduled and unscheduled entries.

• Bug Fixes

  • Prevented duplicate editing controls when the primary field is also used for date grouping.
  • Titles remain read-only labels when they represent the calendar’s grouping field.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Essentials

Run ID: 95c9a333-96b7-4c51-b344-9919bfea6824

📥 Commits

Reviewing files that changed from the base of the PR and between 895dc4b and 7d5ca5b.

📒 Files selected for processing (3)

• docs/specifications/collection-views.md
• src/lib/components/CalendarCollectionView.svelte
• src/lib/components/CalendarCollectionView.svelte.test.ts

Included review availability: 3 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 4 reviews per hour.

---

📝 Walkthrough

Walkthrough

Calendar entries now render the resolved primary field as an editable PropertyValueCell. Calendar keeps the title static when the primary field is the grouped date field. Tests cover scheduled, unscheduled, editable, persisted, and fallback cases.

Changes

Calendar primary-field editing

Layer / File(s)	Summary
Calendar rendering and collision handling src/lib/components/CalendarCollectionView.svelte, docs/specifications/collection-views.md	Scheduled and unscheduled entries render the primary field as an editable cell unless it matches the grouping date. The specification documents this behavior and the corresponding Board collision rules.
Calendar editing and fallback tests src/lib/components/CalendarCollectionView.svelte.test.ts	Tests verify inline editing, persistence, updated display values, and static titles when the primary field is the grouped date.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant CalendarCollectionView
  participant PropertyValueCell
  participant CollectionRecord
  CalendarCollectionView->>PropertyValueCell: render the primary field when it differs from the grouping date
  PropertyValueCell->>CollectionRecord: persist the edited primary-field value
  CollectionRecord-->>CalendarCollectionView: provide the updated record value

Loading

Merge Risk: ⚪ Minimal · up to 7d5ca

The Calendar title-editing behavior, collision fallback, documentation, and targeted tests align with the stated change.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: Calendar entry titles now render the resolved primary field as an editable cell, consistent with Board behavior.
Linked Issues check	✅ Passed	Issue #105 requires a deliberate, documented, and tested choice for Calendar title editability. The PR chooses editable primary-field titles for scheduled and unscheduled entries through `PropertyValu…
Out of Scope Changes check	✅ Passed	The reviewed changes are limited to Calendar title rendering, related Calendar tests, and collection-view documentation for issue #105. The changes do not alter Board behavior or introduce an unrelate…
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 1…

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/github-issue-105-b66bca

---

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

[qodo-code-review]

PR Summary by Qodo

Make Calendar primary-field titles inline editable

✨ Enhancement 🧪 Tests 📝 Documentation 🕐 20-40 Minutes

AI Description

• Make scheduled and unscheduled Calendar titles editable through resolved primary-field cells.
• Keep colliding date-primary titles static to avoid duplicate editors.
• Add regression tests and document parity with Board behavior.

Diagram

graph TD
  A["Calendar Entry"] --> B["Resolve Primary"] --> C{"Date collision?"}
  C -- No --> D["Editable Title"] --> E["Persist Cell"]
  C -- Yes --> F["Static Title"]

Loading

High-Level Assessment

The PR's approach is appropriate: it reuses Calendar's existing PropertyValueCell and setCell behavior while matching Board's established collision rule. A shared Board/Calendar title-rendering abstraction was considered, but the small amount of view-specific rendering and different collision dimensions would add abstraction without meaningful reuse.

Files changed (3) +124 / -7

Enhancement (1) +33 / -2

CalendarCollectionView.svelteRender Calendar primary fields as editable title cells +33/-2

Render Calendar primary fields as editable title cells

• Renders the resolved primary field through PropertyValueCell for both scheduled and unscheduled entries. Adds a groupBy collision guard that retains a static title when the primary field is already editable through the date cell.

src/lib/components/CalendarCollectionView.svelte

Tests (1) +89 / -3

CalendarCollectionView.svelte.test.tsCover Calendar title editing and date collisions +89/-3

Cover Calendar title editing and date collisions

• Adds tests for inline primary-title editing on scheduled and unscheduled entries and verifies persistence to record properties. Also confirms a primary date field produces only one editable control and updates existing title assertions for input rendering.

src/lib/components/CalendarCollectionView.svelte.test.ts

Documentation (1) +2 / -2

collection-views.mdDocument editable Calendar titles and collision handling +2/-2

Document editable Calendar titles and collision handling

• Updates the Calendar specification to define resolved primary fields as compact editable title cells. Clarifies that Board and Calendar both fall back to static labels when the title field collides with a grouping control.

docs/specifications/collection-views.md

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (1)

1. Screen readers cannot name title fields 📜 Skill insight ☑ Accessibility

Description

PropertyValueCell renders its text, number, date, checkbox, and select controls without a label or
ARIA naming attribute, while the new scheduled and unscheduled Calendar title call sites pass only
property, value, and oninput. Whenever an entry's primary field is editable, screen-reader
users encounter an unnamed control and cannot determine that it edits the entry title, even though
the field label remains available in component data.

Code

src/lib/components/CalendarCollectionView.svelte[R394-397]

+												<PropertyValueCell
+													property={titleProperty}
+													value={row.properties?.[titleProperty.key]}
+													oninput={(value) => setCell(row, titleProperty, value)}

Relevance

●●● Strong

Recent accessibility precedents accept adding accessible names to PropertyValueCell controls and
interactive buttons.

PR-#69
PR-#246

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Compliance rule 2948763 requires changed interactive controls to have visible text, aria-label, or
aria-labelledby. Both newly added Calendar title editors render PropertyValueCell without
labeling input, and the component generates text, number, date, checkbox, and select controls
without any of those naming mechanisms, proving that none of the possible primary-field controls
receives an accessible name.

src/lib/components/CalendarCollectionView.svelte[392-399]
src/lib/components/CalendarCollectionView.svelte[457-464]
src/lib/components/PropertyValueCell.svelte[26-73]
src/lib/components/CalendarCollectionView.svelte[392-403]
src/lib/components/CalendarCollectionView.svelte[457-468]
Skill: ux-designer

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The newly editable scheduled and unscheduled Calendar title fields render through `PropertyValueCell`, whose generated form controls have no accessible name, so assistive technology cannot identify their purpose.

## Fix Focus Areas
- src/lib/components/CalendarCollectionView.svelte[392-399]
- src/lib/components/CalendarCollectionView.svelte[457-464]
- src/lib/components/PropertyValueCell.svelte[5-73]

## Recommended Fix
Give every form control emitted by `PropertyValueCell` an accessible name derived from `property.label`, or add an accessible-label prop, apply it to every generated form control, and pass a descriptive primary-field title label from both scheduled and unscheduled Calendar title call sites. Ensure the text, number, date, checkbox, and select variants are all covered.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Compliance rules (platform): 43 rules

✅ Skills: ux-designer, quality-assurance

Review mode: ⚖️ Balanced: This modifies runtime Calendar rendering and inline-edit behavior with collision handling across scheduled and unscheduled paths, creating genuine but localized correctness risk best handled by a complete single-pass review.

Tip of the day

💡 Did you know, you can hide the parts of a finding you never read, like the evidence or the agent prompt

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-code-review]

1. Screen readers cannot name title fields 📜 Skill insight ☑ Accessibility

PropertyValueCell renders its text, number, date, checkbox, and select controls without a label or
ARIA naming attribute, while the new scheduled and unscheduled Calendar title call sites pass only
property, value, and oninput. Whenever an entry's primary field is editable, screen-reader
users encounter an unnamed control and cannot determine that it edits the entry title, even though
the field label remains available in component data.

Agent Prompt

## Issue description
The newly editable scheduled and unscheduled Calendar title fields render through `PropertyValueCell`, whose generated form controls have no accessible name, so assistive technology cannot identify their purpose.

## Fix Focus Areas
- src/lib/components/CalendarCollectionView.svelte[392-399]
- src/lib/components/CalendarCollectionView.svelte[457-464]
- src/lib/components/PropertyValueCell.svelte[5-73]

## Recommended Fix
Give every form control emitted by `PropertyValueCell` an accessible name derived from `property.label`, or add an accessible-label prop, apply it to every generated form control, and pass a descriptive primary-field title label from both scheduled and unscheduled Calendar title call sites. Ensure the text, number, date, checkbox, and select variants are all covered.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools