Enable relationships for span-based (text) annotations

[JSv4]

Summary

This PR fixes three critical issues preventing relationships from working with span-based annotations in text documents, enabling the full relationship creation and display workflow for text files.

Key Changes

1. Centralized File Type Detection

• Created isTextFileType() and isPdfFileType() utility functions in frontend/src/utils/files.ts
• Replaced scattered startsWith("text/") checks and hardcoded MIME type comparisons across 11 components
• Fixes inconsistency where application/txt MIME type was missed by some checks

2. Fixed Label Initialization Race Condition

• File: UISettingsAtom.tsx
• Replaced single initialized.current ref with separate spanLabelInitialized and relationLabelInitialized refs
• Prevents early cutoff where span label initialization could block relationship label auto-initialization on subsequent effect runs

3. Expanded Type Support for Relationship UI

• Files: RelationItem.tsx, RelationHighlightItem.tsx, HighlightItem.tsx, utils.ts
• Updated type signatures to accept ServerTokenAnnotation | ServerSpanAnnotation union types
• Updated annotationSelectedViaRelationship() function to handle both annotation types
• Enables sidebar relationship display and creation flow for text documents

Files Modified

• frontend/src/utils/files.ts (new utilities)
• frontend/src/components/annotator/context/UISettingsAtom.tsx
• frontend/src/components/annotator/sidebar/RelationItem.tsx
• frontend/src/components/annotator/sidebar/RelationHighlightItem.tsx
• frontend/src/components/annotator/sidebar/HighlightItem.tsx
• frontend/src/components/annotator/utils.ts
• frontend/src/components/annotator/hooks/AnnotationHooks.tsx
• frontend/src/components/annotator/labels/EnhancedLabelSelector.tsx
• frontend/src/components/annotator/labels/UnifiedLabelSelector.tsx
• frontend/src/components/annotator/labels/label_selector/LabelSelector.tsx
• frontend/src/components/knowledge_base/document/DocumentKnowledgeBase.tsx
• frontend/src/components/widgets/chat/ChatMessage.tsx

Testing

Verify that:

• Relationships can be created between span annotations in text documents
• Relationship labels auto-initialize correctly
• Both text/plain and application/txt MIME types are handled consistently

https://claude.ai/code/session_01Q8XMB6GZZnDWaQP4prr6v2

[claude]

Code Review - PR #866: Enable relationships for span-based (text) annotations

Summary

This PR successfully addresses issue #281 by enabling relationship functionality for text documents. The changes are well-structured, focused, and follow good software engineering practices. The core approach of centralizing file type detection and separating initialization logic is solid.

✅ Strengths

1. Excellent Centralization: Creating isTextFileType() and isPdfFileType() utilities eliminates scattered string comparisons across 11 components. This follows DRY principles perfectly and catches the application/txt edge case that was previously missed.

2. Race Condition Fix: The refactoring from a single initialized.current ref to separate spanLabelInitialized and relationLabelInitialized refs is well-reasoned. The inline comment clearly explains why this matters.

3. Type Safety: Expanding type signatures to ServerTokenAnnotation | ServerSpanAnnotation union types properly reflects the actual data flow and enables TypeScript to catch potential issues.

4. Comprehensive Coverage: The PR touches all relevant components (11 components updated) to ensure consistent behavior throughout the codebase.

5. Good Documentation: CHANGELOG.md follows the project's Keep a Changelog format with specific file locations and clear descriptions.

🔍 Code Quality Observations

files.ts (frontend/src/utils/files.ts:8-15)

export const isTextFileType = (fileType: string | null | undefined): boolean =>
  fileType?.startsWith("text/") === true || fileType === "application/txt";

export const isPdfFileType = (fileType: string | null | undefined): boolean =>
  fileType === "application/pdf";

✅ Good: Handles null/undefined gracefully with optional chaining
✅ Good: Explicit === true comparison prevents truthy coercion bugs
✅ Good: Clear JSDoc comments explain the legacy application/txt handling

UISettingsAtom.tsx (lines 289-315)

const spanLabelInitialized = useRef(false);
const relationLabelInitialized = useRef(false);

useEffect(() => {
  if (\!selectedDocument) return;
  
  const isTextFile = isTextFileType(selectedDocument.fileType);
  const isPdfFile = isPdfFileType(selectedDocument.fileType);
  
  if (\!spanLabelInitialized.current) {
    // initialization logic
  }
  
  if (\!relationLabelInitialized.current) {
    // initialization logic
  }
}, [/* deps */]);

✅ Good: Early return pattern for guard clause
✅ Good: Separate initialization tracking prevents race condition
✅ Good: Comment explains the rationale for the change
⚠️ Minor: The effect dependencies include activeSpanLabel and activeRelationLabel, which means the effect runs whenever these change. Since the refs prevent re-initialization, this is safe, but could potentially run more than necessary.

Type Union Updates (RelationItem.tsx, HighlightItem.tsx, etc.)

target_annotations: (ServerTokenAnnotation | ServerSpanAnnotation)[];
source_annotations: (ServerTokenAnnotation | ServerSpanAnnotation)[];

✅ Good: Union types are the correct approach here
✅ Good: Both classes share common properties (id, annotationLabel, etc.) so they can be used interchangeably in display logic

🧪 Testing Considerations

Missing: Unit tests for the new utility functions in files.ts

I recommend adding a test file frontend/src/utils/__tests__/files.test.ts:

import { describe, it, expect } from 'vitest';
import { isTextFileType, isPdfFileType } from '../files';

describe('File type utilities', () => {
  describe('isTextFileType', () => {
    it('should return true for text/plain', () => {
      expect(isTextFileType('text/plain')).toBe(true);
    });
    
    it('should return true for text/* variants', () => {
      expect(isTextFileType('text/html')).toBe(true);
      expect(isTextFileType('text/csv')).toBe(true);
    });
    
    it('should return true for application/txt (legacy)', () => {
      expect(isTextFileType('application/txt')).toBe(true);
    });
    
    it('should return false for PDF', () => {
      expect(isTextFileType('application/pdf')).toBe(false);
    });
    
    it('should handle null/undefined gracefully', () => {
      expect(isTextFileType(null)).toBe(false);
      expect(isTextFileType(undefined)).toBe(false);
    });
  });
  
  describe('isPdfFileType', () => {
    it('should return true for application/pdf', () => {
      expect(isPdfFileType('application/pdf')).toBe(true);
    });
    
    it('should return false for text types', () => {
      expect(isPdfFileType('text/plain')).toBe(false);
    });
    
    it('should handle null/undefined gracefully', () => {
      expect(isPdfFileType(null)).toBe(false);
      expect(isPdfFileType(undefined)).toBe(false);
    });
  });
});

Manual Testing Needed (per the PR description):

• ✅ Relationships can be created between span annotations in text documents
• ✅ Relationship labels auto-initialize correctly
• ✅ Both text/plain and application/txt MIME types are handled consistently

🔒 Security Considerations

✅ No concerns: This PR is purely frontend type-safety and UI logic changes. No data validation, permissions, or backend changes that could introduce security issues.

⚡ Performance Considerations

✅ No concerns: The utility functions are simple boolean checks with no performance impact. The initialization logic refactoring doesn't change the computational complexity.

📚 Adherence to Project Guidelines

✅ CLAUDE.md compliance:

• ✅ Follows DRY principle by centralizing file type detection
• ✅ Utilities placed in correct location (frontend/src/utils/files.ts)
• ✅ CHANGELOG.md properly updated with file locations and line numbers
• ✅ Clear commit message with issue reference

🎯 Recommendations

1. Add unit tests for isTextFileType and isPdfFileType (see test code above)
2. Consider extracting a constant for the legacy MIME type:

   const LEGACY_TEXT_MIME_TYPE = 'application/txt';
   
   export const isTextFileType = (fileType: string | null | undefined): boolean =>
     fileType?.startsWith('text/') === true || fileType === LEGACY_TEXT_MIME_TYPE;

3. Manual testing: Verify the three scenarios in the PR description before merging

✅ Verdict

APPROVE with minor suggestions - This PR is well-implemented and ready to merge after adding the recommended unit tests. The changes are focused, solve the stated problem, and follow project conventions.

The code quality is high, the approach is sound, and the risk is low. The centralization of file type detection will prevent future bugs and make the codebase more maintainable.

---

Review generated for commit: Closes #281

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[claude]

Code Review - PR #866: Enable relationships for span-based (text) annotations

Summary

This PR successfully addresses issue #281 by enabling relationship creation and display for text documents (span-based annotations). The changes are well-structured, comprehensive, and include proper test coverage.

---

✅ Strengths

1. Excellent Centralization Pattern

The creation of isTextFileType() and isPdfFileType() utilities in frontend/src/utils/files.ts is exactly the right approach:

• Consolidates 12+ scattered file type checks into a single source of truth
• Handles the edge case of application/txt (legacy MIME type) consistently
• Proper null/undefined handling
• Well-documented with clear JSDoc comments
• Extracted LEGACY_TEXT_MIME_TYPE constant to constants.ts (following project conventions)

2. Critical Bug Fix - Race Condition

The label initialization fix in UISettingsAtom.tsx (lines 289-325) is well-reasoned:

• Splitting initialized.current into separate spanLabelInitialized and relationLabelInitialized refs prevents early cutoff
• Excellent inline documentation explaining why deps exclude activeSpanLabel/activeRelationLabel
• The eslint-disable-next-line is justified and documented

3. Type System Enhancement

Widening types to ServerTokenAnnotation | ServerSpanAnnotation union:

• Enables code reuse between PDF and text document workflows
• Both classes share compatible interfaces (same properties: id, page, annotationLabel, rawText, etc.)
• Changes are minimal and focused - just updating type signatures, no logic changes needed

4. Comprehensive Test Coverage

The new test file frontend/src/utils/__tests__/files.test.ts covers:

• All positive cases (text/plain, text/*, application/txt, application/pdf)
• Edge cases (null, undefined, empty string)
• Negative cases (wrong MIME types)
• 11 test cases total - thorough coverage

5. Excellent Changelog Documentation

The CHANGELOG.md entry follows project conventions perfectly:

• Clear category (Fixed)
• Detailed description of each issue
• File locations and line numbers included
• Links to all affected files

---

🔍 Code Quality Observations

Minor Considerations (Not Blockers)

1. Type Guard Enhancement (Optional Improvement):
   The utility functions could be enhanced with TypeScript type guards for better type narrowing:

   export const isTextFileType = (fileType: string | null | undefined): fileType is string =>
     fileType?.startsWith("text/") === true || fileType === LEGACY_TEXT_MIME_TYPE;

   However, the current implementation is perfectly fine - this is just a potential enhancement.

2. Component Testing (Future Work):
   While unit tests for the utilities are excellent, component tests for the relationship creation workflow in text documents would be valuable. However, given the project's testing guidelines (use --reporter=list, proper test wrappers required), this is better as follow-up work rather than blocking this PR.

3. UseEffect Dependencies (Already Addressed):
   The intentional exclusion of activeSpanLabel/activeRelationLabel from deps is correct and well-documented. The refs prevent infinite loops while still allowing re-initialization when data sources change.

---

🔒 Security & Performance

• ✅ No security concerns - changes are entirely type-safe
• ✅ No performance impact - utility functions are O(1)
• ✅ No XSS risks - no user content rendering changes
• ✅ No permission changes - respects existing permission model

---

📋 Adherence to Project Conventions

Per CLAUDE.md:

• ✅ No dead code introduced
• ✅ DRY principle followed (centralized utilities)
• ✅ Single responsibility maintained
• ✅ Constants properly extracted to constants.ts
• ✅ Changelog properly updated
• ✅ No credit to Claude in commit messages
• ✅ Utility functions placed in correct location (frontend/src/utils/)

---

🧪 Testing Recommendations

Before merging, please verify:

1. Frontend tests pass:

   cd frontend
   yarn test:unit --run

2. TypeScript compilation succeeds:

   cd frontend
   npx tsc --noEmit

3. Manual testing (as described in PR description):

   • Open a text document (text/plain or application/txt)
   • Create span annotations
   • Verify relationship labels auto-initialize
   • Create relationships between span annotations
   • Verify relationships display correctly in sidebar

---

🎯 Final Verdict

LGTM - Approved ✅

This is high-quality work that:

• Solves a real user-facing issue ([FEATURE] - Enable Relationships for Span-Based Annotations #281)
• Follows established project patterns
• Includes proper test coverage
• Has clear documentation
• Makes no breaking changes
• Improves code maintainability through centralization

The PR is ready to merge once tests confirm everything passes.

---

Acknowledgment

Great job on the centralization pattern and the thorough handling of the race condition. The separate initialization refs are a clean solution to a subtle timing issue.

[claude]

PR Review: Enable relationships for span-based (text) annotations

This PR addresses three real bugs and the approach is sound overall. Here is detailed feedback organized by priority.

---

Bugs / Correctness Issues

1. Label refs not reset on document change — potential regression

File: frontend/src/components/annotator/context/UISettingsAtom.tsx

const spanLabelInitialized = useRef(false);
const relationLabelInitialized = useRef(false);

Both refs are set to true after first initialization but are never reset when selectedDocument changes. If the user navigates from one document to another within the same component instance, the new document's labels will never auto-initialize.

The old code had the same issue with initialized.current, so this is a pre-existing bug — but the refactor is a good opportunity to fix it. Consider resetting both refs when selectedDocument changes (e.g., track the previous document ID):

const lastDocumentId = useRef<string | null>(null);
// Inside effect:
if (selectedDocument?.id !== lastDocumentId.current) {
  spanLabelInitialized.current = false;
  relationLabelInitialized.current = false;
  lastDocumentId.current = selectedDocument?.id ?? null;
}

2. Debug console.log left in production code

File: frontend/src/components/annotator/hooks/AnnotationHooks.tsx, line ~141

console.log("[handleCreateAnnotation] Creating ServerSpanAnnotation instance");

This pre-existing log was not removed during the refactor. Should be cleaned up.

3. Page number consistency — verify +1 for both annotation types

Files: HighlightItem.tsx, RelationHighlightItem.tsx

Both files change annotation.page to annotation.page + 1. If ServerTokenAnnotation already stores 1-based page numbers (common in PDF contexts), this adds a second +1 offset. Please confirm that both ServerTokenAnnotation.page and ServerSpanAnnotation.page are 0-indexed before merging.

---

Convention Violations (per CLAUDE.md)

CLAUDE.md states: "No magic numbers — use constants files" for hardcoded values.

4. Hardcoded colors in styled components

Files: RelationItem.tsx, RelationHighlightItem.tsx, TxtAnnotator.tsx

Multiple magic color values scattered across new styled components:

// RelationItem.tsx
"rgba(46, 204, 113, 0.08)"  // selected bg
"rgba(46, 204, 113, 0.2)"   // selected shadow
"#e0e1e2"                   // default border
"#e2e8f0"                   // divider line
"#99a1a7"                   // delete button

// RelationHighlightItem.tsx
"#b0b7bf", "#fee2e2", "#dc2626", "#fecaca"  // remove button states
"#64748b", "#9ca3af", "#475569"             // text colors

These should be extracted to frontend/src/assets/configurations/constants.ts.

5. isPdfFileType uses a hardcoded string rather than a constant

File: frontend/src/utils/files.ts

LEGACY_TEXT_MIME_TYPE was correctly added for application/txt, but isPdfFileType still hardcodes:

export const isPdfFileType = (fileType: string | null | undefined): boolean =>
  fileType === "application/pdf";  // should use a constant

A PDF_MIME_TYPE = "application/pdf" constant should be added to constants.ts for symmetry.

---

Minor / Suggestions

6. Redundant color derivation in TxtAnnotator

File: frontend/src/components/annotator/renderers/txt/TxtAnnotator.tsx

Both borderColor and primaryAnnotationColor derive from the same source:

const borderColor = finalAnnotations[0]?.annotationLabel?.color || "#000";
const primaryAnnotationColor =
  finalAnnotations.length > 0
    ? finalAnnotations[0].annotationLabel.color || "#cccccc"
    : undefined;

These can be collapsed into one variable. The fallback values also differ ("#000" vs "#cccccc") which may be intentional — if so, a comment would help.

7. eslint-disable on effect deps array

File: UISettingsAtom.tsx

The // eslint-disable-next-line react-hooks/exhaustive-deps comment is acceptable given the intentional design, but the inline comment explaining the reasoning is well-placed. The fix is otherwise correct: setter functions from atoms are stable, and re-running on every label value change would cause unwanted loops.

8. isTextFileType accepts all text/* subtypes

The function returns true for text/html, text/csv, text/javascript, etc. The unit tests explicitly document this (good). If this is intentional, it is fine as-is — just worth confirming that the system will not try to render a text/html document as a text annotator.

---

What's Good

• Centralized file type detection is the right pattern and the test coverage (files.test.ts) is solid.
• Separate init refs for span vs relation labels is a clean solution to the race condition — much easier to reason about than the combined initialized flag.
• Type widening to ServerTokenAnnotation | ServerSpanAnnotation is correct and minimal.
• e.stopPropagation() added on delete/remove buttons in the redesigned RelationItem / RelationHighlightItem — this is a real bug fix for click-through to the parent relation selector.
• Custom ResizeObserver replacing useDynamicRowHeight (which is not a standard react-window export) is more transparent and avoids a potentially missing or incorrect dependency.
• let to const for source_cards / target_cards in RelationItem.tsx is a good cleanup.

---

Summary: The core fixes are correct and necessary. The two actionable items before merge are (1) verifying the page + 1 change is safe for both annotation types and (2) fixing the document-switching label reset. The magic color/constant violations are lower priority but should be addressed to stay consistent with project conventions.

[claude]

PR Review: Enable Relationships for Span-Based (Text) Annotations

This is a well-structured PR that addresses three real bugs. The centralized file type detection is a textbook DRY improvement and the race condition fix is correctly reasoned. A few things worth addressing before merge:

---

Issues

1. Magic string in isPdfFileType (violates project guidelines)

// frontend/src/utils/files.ts
export const isPdfFileType = (fileType: string | null | undefined): boolean =>
  fileType === "application/pdf";

The PR correctly adds LEGACY_TEXT_MIME_TYPE as a constant, but "application/pdf" is still a magic string. Per CLAUDE.md: "No magic numbers — use the constants files." A PDF_MIME_TYPE constant should be added to constants.ts and used here (and then the existing SUPPORTED_MIME_TYPES array can reference it too).

---

2. as any type casting in UnifiedContentFeed.tsx

// frontend/src/components/knowledge_base/document/unified_feed/UnifiedContentFeed.tsx
const note = item.data as any;
const ann  = item.data as any;

These bypass TypeScript's type checker. The item discriminated union already has a type field — proper narrowing (e.g. item.data as NoteType, or a type-guard helper) would catch bugs here without disabling type safety.

---

3. Custom ResizeObserver implementation relies on library duck-typing

/* The library detects dynamic mode via duck-typing (getAverageRowHeight),
 * sets height:undefined on rows so they auto-size, and calls
 * observeRowElements with visible DOM elements for measurement. */

The implementation reverse-engineers an undocumented internal contract of react-window. Any patch to that library's internals could silently break measurement. At minimum, add a comment pinning the version of react-window this was tested against and what to re-verify on upgrade. If the library offers a stable public API for this, prefer that.

---

4. Inline styles instead of styled-components in RelationHighlightItem.tsx

<div
  style={{
    display: "flex",
    alignItems: "center",
    flexWrap: "wrap",
    gap: "0.25rem",
  }}
>

The rest of the component uses styled-components. This flex wrapper and the <Icon style={{ margin: 0, fontSize: "0.85em" }} /> should follow the same pattern for consistency.

---

5. ESLint-disable for exhaustive-deps — justified but worth noting

// eslint-disable-next-line react-hooks/exhaustive-deps
}, [humanSpanLabelChoices, humanTokenLabels, relationLabels, selectedDocument]);

The comment explaining the omission of activeSpanLabel/activeRelationLabel and their setters is adequate. Jotai atom setters are stable (referentially equal across renders), so their omission from deps is safe. The activeSpanLabel/activeRelationLabel values are correctly excluded because the ref guards already prevent re-initialization. The explanation in the comment is accurate — just flagging it for awareness.

---

Positive observations

• isTextFileType implementation and tests are solid. Handles null/undefined/"" gracefully, and the test suite covers all the edge cases including the legacy MIME type.
• Page display fix (annotation.page + 1) is a genuine bug fix. Annotations are stored 0-indexed; HighlightItem and RelationHighlightItem were displaying the wrong page number.
• Race condition fix logic is correct. The old single initialized ref would short-circuit relation label init whenever span labels loaded first. The separate refs per label type properly decouple the initialization paths.
• let → const for source_cards/target_cards in RelationItem.tsx is a nice incidental cleanup.
• Test coverage for the new utilities (frontend/src/utils/__tests__/files.test.ts) is comprehensive.
• Screenshot infrastructure is correctly wired through docScreenshot per the project conventions.
• DocumentRenderingCornerCases fix (app zoom controls instead of Control++ keyboard shortcut) is the right approach — browser zoom misaligns boundingBox() coordinates with mouse events.

---

Summary

The core logic is sound. The two things most worth fixing before merge are the magic string ("application/pdf" → constant) and the as any casts in UnifiedContentFeed.tsx. The ResizeObserver concern is lower priority but worth a version-pinning comment.

[claude]

PR Review: Enable Relationships for Span-Based (Text) Annotations

This is a well-scoped fix with a clear motivation. The three root-cause analysis in the description is accurate and the core changes are sound. A few items need attention before merge.

---

Issues

1. annotation.page + 1 may regress PDF token annotation display

Files: frontend/src/components/annotator/sidebar/HighlightItem.tsx:306, frontend/src/components/annotator/sidebar/RelationHighlightItem.tsx:141

The +1 is correct for ServerSpanAnnotation if its page field is 0-indexed. But HighlightItem previously only accepted ServerTokenAnnotation, and PDF token annotations may already be stored with 1-based page values (the Django Annotation model has page = IntegerField(default=1)).

If PDF token annotations send a 1-based page down through GraphQL, these components would now display "Page 2" for first-page PDF annotations. This change is not called out in the PR description and there are no tests covering the pre-existing token annotation page display.

Please confirm whether ServerTokenAnnotation.page is 0-indexed or 1-indexed when it arrives from the backend, and add a test or comment documenting the chosen invariant.

---

2. Custom ResizeObserver implementation may cause unnecessary re-renders

File: frontend/src/components/knowledge_base/document/unified_feed/UnifiedContentFeed.tsx

The heightMapVersion state counter is added as a dep of the rowHeight memo, forcing the entire memo object to be recreated on every measurement change. Because rowHeight is a new object reference after each measurement, any child component using it via useMemo/memo equality checks will re-render. In a virtualized list that measures many rows on mount, this produces a burst of full re-renders.

The prior useDynamicRowHeight from react-window avoided this by using stable callbacks. The PR description does not explain why the library hook was replaced. If there was a specific bug with useDynamicRowHeight, documenting it here would clarify the trade-off.

Consider whether heightMapVersion in the memo dep is actually necessary — getRowHeight reads from heightMapRef.current (the ref) directly, so the memo doesn't need to be invalidated to pick up new values. The version counter is only needed to trigger re-renders in the component itself, which could be handled more narrowly.

---

3. Claude Code attribution in PR description

The PR description ends with a https://claude.ai/code/session_... URL. Per CLAUDE.md:

Never credit Claude or Claude Code in commit messages, PR messages, comments, or any other artifacts.

Please remove that URL before merge.

---

Minor Notes

containerStyle prop in UnifiedContentFeedTestWrapper (frontend/tests/UnifiedContentFeedTestWrapper.tsx): The prop is added but never used in any test in this PR. Per the project's "no dead code" convention, either use it in a test here or hold it until it's needed.

eslint-disable comment in UISettingsAtom.tsx: The comment correctly explains the intent, but adding // react-hooks/exhaustive-deps inline (i.e., // eslint-disable-next-line react-hooks/exhaustive-deps) makes it greppable and explicit about which rule is suppressed. The current comment text is fine as prose context; pair it with the rule name for tooling consistency.

isTextFileType breadth: The function returns true for text/html, text/csv, etc. This matches the prior startsWith("text/") behavior, so it is not a regression, but it means future documents with those MIME types would get the span annotation treatment. Worth a brief comment in files.ts noting this is intentional.

---

What's Working Well

• Centralization of file type detection into isTextFileType/isPdfFileType utilities with a named constant for the legacy MIME type is exactly the right abstraction. Eliminates scattered startsWith("text/") and === "application/txt" literals cleanly.
• Race condition fix in UISettingsAtom.tsx is correct. Splitting initialized into two independent refs (spanLabelInitialized, relationLabelInitialized) and removing the current-value deps from the effect is the right approach. The explanatory comment is helpful.
• Type expansion (ServerTokenAnnotation | ServerSpanAnnotation) is done consistently across all four affected components and annotationSelectedViaRelationship().
• Unit tests for isTextFileType/isPdfFileType cover the key cases including null/undefined handling.
• Component tests for span annotation relationships in UnifiedContentFeed.ct.tsx give good coverage of the new rendering path.
• DocumentRenderingCornerCases conversion from a known-failing test to a passing one with proper infrastructure fixes (ZoomControls avoidance, inter-keypress waits) is a clean improvement.