Content
View differences
Updated by Alexander Coles about 2 months ago
**Goals:**
* Evaluate how much of the existing Boards codebase we can re-use, re-use – with the objective of shipping **shipping user-facing features faster. For much faster**: in this spike, the concrete target is case, a narrow but eventually shippable React subset rudimentary UI for status mapping (see #71104). <mention class="mention" data-id="71104" data-type="work_package" data-text="#71104">#71104</mention> )
* Continue **Continue evaluating Claude and other agents Claude** for development tasks, with a particular emphasis on:
* on well-tested, production-quality code
* getting to know the Figma Angular CLI MCP for code generation Angular tasks.
* Learn **Learn Primer React, React** - and evaluate how it interoperates interops with Primer ViewComponents. Also evaluate Primer's View Component implementation. Also, how we might hedge toward be able to "hedge" and take advantage of the React library given PVC's effective effective. deprecation. _This should feed into discussions at the D-Team offsite._
**Scope for this spike:**
* Keep the initial shippable subset intentionally narrow: support `free` boards and `action` boards with `attribute == "status"` in the React implementation. offsite!_
* Keep unsupported board types such as version, assignee, subproject, and subtasks on the existing Angular path for now.
* Focus on proving that the React path can be made safe, testable, and incrementally shippable by reusing existing board semantics for filters, ordering, status transitions, and existing smoke-test coverage.
* Defer broader board-type parity to follow-up work once the support boundary and shared abstractions are in place. <br>
**Constraints:** **Constraints**:
* Spend minimal human dev hours on this until we get stakeholder consensus on future frontend architecture and framework choices.
* Keep a Turbo Boards rewrite on the table.
* Use existing UI components, albeit the React implementations thereof.
* Make the spike Be good enough to be shippable eventually; do not (eventually) - don't create something completely throw-away.
**Non-goals throw-away (i.e. not "vibe coded") _This may be considered an anti-pattern for this spike:**
* Port all board types to React.
* Resolve the long-term frontend architecture decision for Boards.
* Replace the existing Angular implementation for unsupported board types. spikes, but there are already a couple open GitHub Pull Requests that show React integration that can be considered throw-away._
* Evaluate how much of the existing Boards codebase we can re-use,
* Continue
*
* getting to know the Figma
* Learn
**Scope for this spike:**
* Keep the initial shippable subset intentionally narrow: support `free` boards and `action` boards with `attribute == "status"` in the React implementation.
* Keep unsupported board types such as version, assignee, subproject, and subtasks on the existing Angular path for now.
* Focus on proving that the React path can be made safe, testable, and incrementally shippable by reusing existing board semantics for filters, ordering, status transitions, and existing smoke-test coverage.
* Defer broader board-type parity to follow-up work once the support boundary and shared abstractions are in place.
**Constraints:**
* Spend minimal human dev hours on this until we get stakeholder consensus on future frontend architecture and framework choices.
* Keep a Turbo Boards rewrite on the table.
* Use existing UI components, albeit the React implementations thereof.
* Make the spike
**Non-goals
* Port all board types to React.
* Resolve the long-term frontend architecture decision for Boards.
* Replace the existing Angular implementation for unsupported board types.