Refactor schedule components to use InformationBlockFact

[jfrench9]

Summary

This PR refactors the SchedulePanel and SchedulesContent components to adopt the InformationBlockFact component pattern from the @robosystems/client library, replacing the previous implementation. The @robosystems/client dependency is updated from its prior version to 0.3.9 to support this change.

Changes

Component Refactoring

• SchedulePanel.tsx (ledger/close/components): Updated to use InformationBlockFact for rendering schedule data, streamlining how individual facts/fields are displayed within the panel.
• SchedulesContent.tsx (ledger/schedules): Significant refactor (~78 lines changed) to integrate InformationBlockFact, replacing prior markup and layout logic with the standardized component from the shared library.

Dependency Updates

• @robosystems/client: Bumped to 0.3.9, which introduces or stabilizes the InformationBlockFact component used in this PR.
• package-lock.json: Regenerated to reflect the updated dependency tree (~1596 lines changed).

Key UI/UX Improvements

• Adopts a consistent InformationBlockFact pattern for displaying schedule information, ensuring visual and structural consistency across the ledger module.
• Aligns schedule panels and schedule content views with the shared design system provided by @robosystems/client.

Breaking Changes

• None expected. This is a refactor of internal component usage. However, if any consumers or tests rely on the specific DOM structure of SchedulePanel or SchedulesContent, they may need to be updated to reflect the new markup produced by InformationBlockFact.

Testing Notes for Reviewers

1. Ledger Close flow — Navigate to the ledger close view and verify that the SchedulePanel renders schedule facts/details correctly with proper formatting and layout.
2. Schedules page — Navigate to /ledger/schedules and confirm that the content displays all schedule information as expected, with no missing data or layout regressions.
3. Empty/edge states — Verify behavior when schedules have missing or null fields to ensure InformationBlockFact handles these gracefully.
4. Responsive layout — Check that the refactored components maintain proper layout at various viewport sizes, particularly since the component structure has changed.

Browser Compatibility Considerations

• No new browser APIs or CSS features are introduced; compatibility depends on the InformationBlockFact component from @robosystems/client@0.3.9, which should follow the same browser support matrix as the rest of the shared library.
• Recommend verifying in Chrome, Firefox, Safari, and Edge as part of standard QA.

---

🤖 Generated with Claude Code

Branch Info:

• Source: feature/information-block
• Target: main
• Type: feature

Co-Authored-By: Claude noreply@anthropic.com

[jfrench9]

@claude please review this PR

[claude]

Claude finished @jfrench9's task in 1m 28s —— View job

---

PR Review: Refactor schedule components to use InformationBlockFact

Tasks:

• Gather PR context
• Read changed component files
• Analyze diff vs origin/main
• Post review feedback

---

Overall this is a clean, well-executed migration. The old LedgerSchedule/LedgerScheduleFact types and the getScheduleFacts/listSchedules API calls are fully removed — no stale references remain anywhere in the codebase. The null guard for getInformationBlock returning null is correct, and the Map-based element name resolution is efficient. A few things worth discussing before merging:

---

Issues

1. mechanics type cast is fragile — content.tsx:61

const mechanics = block.artifact.mechanics as {
  kind?: string
  scheduleMetadata?: { method?: string }
  periodsWithEntries?: number
}

This casts an untyped artifact.mechanics field with no runtime validation. If the API shape changes (e.g., periodsWithEntries moves or scheduleMetadata is renamed) this silently returns wrong data — periodsWithEntries defaults to 0 and method defaults to null with no indication anything is wrong.

Consider extracting this into a typed guard or adding an assertion comment documenting which API contract version this depends on. At minimum, a console.warn when expected fields are absent would surface regressions.

Fix this →

---

2. taxonomyName mapped but never rendered — content.tsx:49,70

ScheduleRow includes taxonomyName: string | null, populated from block.taxonomyName, but it isn't displayed in the table or used anywhere in the component. Either render it (e.g., as a subtitle under the schedule name alongside method) or remove it from ScheduleRow to keep the data model honest.

Fix this →

---

3. periodStart nullability not guarded in formatMonth calls — SchedulePanel.tsx:174, content.tsx:392

In content.tsx:67, periodStart is handled as possibly null/undefined via f.periodStart ?? ''. But downstream, formatMonth(fact.periodStart) receives it as string — if InformationBlockFact.periodStart is typed as string | null | undefined, this will produce Invalid Date (rendering as "Invalid Date" or NaN) when periodStart is absent.

// Suggestion
{formatMonth(fact.periodStart ?? fact.periodEnd)}

Or guard the render:

{fact.periodStart ? formatMonth(fact.periodStart) : '—'}

Fix this →

---

Nits

ScheduleFactRow is duplicated across SchedulePanel.tsx:25 and content.tsx:43 — identical type definition in both files. Not a blocker given they're in separate feature directories, but worth consolidating in a shared types file if this type ends up used in a third place.

Table row key uses idx — SchedulePanel.tsx:168: key={${key}-${fact.elementId}-${idx}}. Index-based fallback is fine here since the list isn't reordered, but if fact.elementId is guaranteed unique within a period group, ${key}-${fact.elementId} alone is cleaner.

---

Summary

Correctness	✅ Migration is complete, no stale references
Type safety	⚠️ mechanics cast (#1) and periodStart nullability (#3)
Data model	⚠️ taxonomyName unused (#2)
Tests	No existing tests for these components

The two medium items (#1 and #3) are worth fixing before merge — #1 because it creates a silent failure surface, and #3 because null dates render visibly broken. #2 is a quick cleanup. Everything else looks good.
| Branch: feature/information-block