feat: add avatars to client-side grid and separate task ID from name

[ryanrozich]

Summary

This PR implements avatars for the client-side grid and separates the task ID from the task name for better clarity.

Fixes #26

Changes

• ✨ Updated data generator to use string IDs (e.g., 'UI-1234') instead of numeric IDs
• 🔀 Separated task ID into its own column, showing just the task name in the name column
• 👤 Enabled avatar renderer for both client-side and server-side grids (was only server-side before)
• 🎨 Added monospace font styling to ID column for better readability
• 📐 Adjusted column widths for optimal layout with the new avatar display

Visual Changes

The grid now displays:

• ID Column: Shows task IDs like "UI-1234", "API-1002" with monospace font
• Task Column: Shows only the task name without the ID prefix
• Assignee Column: Shows avatar (photo or initials) alongside the assignee name

Testing

• Verified avatars display correctly on client-side grid
• Confirmed ID and name separation works as expected
• Tested that server-side grid still works with avatars
• Checked responsive behavior with adjusted column widths

🤖 Generated with Claude Code

To fix the issue, we need to add a permissions block to the workflow. This block should specify the least privileges required for the workflow to function correctly. Based on the workflow's functionality, it interacts with issues and pull requests, so the permissions should include contents: read and issues: write.

The permissions block can be added at the root level of the workflow to apply to all jobs or within the specific job (sync-agent-status) to scope permissions to that job only. In this case, adding it at the job level is more precise.

---

To fix the issue, we need to ensure that backslashes in the triggerComment string are properly escaped before passing it to the execSync command. This can be achieved by adding a .replace(/\\/g, '\\\\') step before escaping double quotes. This ensures that all backslashes are doubled, preventing them from being interpreted as escape characters in the shell command.

The updated code will replace both backslashes and double quotes in the triggerComment string, ensuring it is safe to use in the shell command.

---

To fix the issue, we need to ensure that both double quotes and backslashes are escaped in the trackingBody string before it is passed to the execSync function. This can be achieved by using a regular expression with the global flag (g) to replace all occurrences of backslashes and double quotes. Alternatively, a well-tested library like shell-escape can be used to sanitize the input, but for simplicity, we will implement the fix using regular expressions.

The replacement block will modify the trackingBody.replace call to escape both backslashes and double quotes. Specifically, we will chain two replace calls: one to escape backslashes and another to escape double quotes.

---

To fix the issue, we need to ensure that both double quotes and backslashes are properly escaped in the issueBody string. This can be achieved by using a regular expression with the global flag (g) to replace all occurrences of backslashes (\) with double backslashes (\\) and then escaping double quotes ("). This ensures that the string is safe to use in the execSync command.

The fix involves modifying the issueBody.replace call on line 185 to include escaping for backslashes. Specifically, we will chain two replace calls: one for backslashes and one for double quotes.

---

To fix the issue, the updateBody.replace call should be updated to escape backslashes in addition to double quotes. This can be achieved by chaining another replace call to handle backslashes or by using a regular expression that escapes both characters in a single pass. A better approach is to use a well-tested library for escaping shell arguments, such as shell-escape, but since we are limited to the shown code, we will implement the fix manually.

The fix involves:

1. Escaping backslashes (\) by replacing them with double backslashes (\\).
2. Ensuring that double quotes (") are escaped as before.

The changes will be applied to the updateBody.replace call on line 225.

---

To fix the issue, we need to ensure that both double quotes (") and backslashes (\) are escaped in the body string before passing it to the gh issue edit command. This can be achieved by using a regular expression with the global flag (g) to replace all occurrences of backslashes with double backslashes and double quotes with escaped double quotes. Alternatively, a well-tested library like jsesc can be used for escaping strings, but for simplicity, we will implement the fix using regular expressions.

To fix the issue, we need to ensure that both double quotes (") and backslashes (\) are properly escaped in the comment string. This can be achieved by using a regular expression with the g (global) flag to replace all occurrences of backslashes with double backslashes (\\) and then replacing all double quotes with escaped double quotes (\"). This ensures that the string is safe for use in the gh pr comment command.

The fix involves modifying the comment.replace calls on lines 286 and 304 to handle backslashes in addition to double quotes.

---

To fix the issue, the comment.replace operation should be updated to escape both double quotes (") and backslashes (\). This can be achieved by using a regular expression with the g flag to replace all occurrences of backslashes with double backslashes (\\) and then escaping double quotes. This ensures that the comment string is properly sanitized before being passed to the gh pr comment command.

The fix involves modifying the comment.replace calls on lines 286 and 304 to include backslash escaping. No new dependencies are required, as JavaScript's built-in replace method with regular expressions is sufficient.

---

[ryanrozich]

Closing this PR as these changes are already included in v0.2.0-rc1. Thank you for the contribution!