Latest Results
Status categories layout (#3221)
<!-- CURSOR_AGENT_PR_BODY_BEGIN -->
# Pull Request Template
Thanks for taking the time to fill out this pull request!
## Issue Reference
Please link to any related issues
- [ ] This PR fixes/closes #[issue number]
## Changes
Please describe the changes proposed in this pull request
This PR introduces a new Kanban-style layout for the BEP proposals page,
allowing users to organize and view proposals by their status.
Key changes include:
- **Kanban View:** A new view organizes BEP proposals into 6 columns
based on their status (Draft, Proposed, Accepted, Implemented, Rejected,
Superseded).
- **View Toggle:** Added a toggle to switch between the original list
view and the new kanban view, with Kanban set as the default.
- **`BepKanbanCard` Component:** A new compact card component for
displaying BEP details within the kanban columns.
- **Responsive Layout:** The kanban board is responsive, adapting column
count based on screen size (1 column on mobile, up to 6 on extra-large
screens).
- **Page Width Adjustment:** The main page container width has been
increased to better accommodate the full kanban board.
The search functionality remains consistent across both views.
## Testing
Please describe how you tested these changes
- [ ] Unit tests added/updated
- [x] Manual testing performed (Verified UI changes, view toggle,
responsiveness, and search functionality)
- [x] Tested in [environment] (Local development environment)
- [x] TypeScript compilation successful
## Screenshots
If applicable, add screenshots to help explain your changes
[Add screenshots here...]
## PR Checklist
Please ensure you've completed these items
- [ ] I have read and followed the contributing guidelines
- [ ] My code follows the style guidelines of this project
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
## Additional Notes
Add any other context about the PR here
The primary goal of this change is to improve the discoverability and
understanding of BEP statuses by providing a more visual and organized
layout.
---
[Slack
Thread](https://gloo-global.slack.com/archives/C09F3QMJE9G/p1772840793378909?thread_ts=1772840793.378909&cid=C09F3QMJE9G)
<p><a
href="https://cursor.com/agents/bc-443cd9e6-3697-5fe9-9a13-34b8a594d58b"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source
media="(prefers-color-scheme: light)"
srcset="https://cursor.com/assets/images/open-in-web-light.png"><img
alt="Open in Web" width="114" height="28"
src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a> <a
href="https://cursor.com/background-agent?bcId=bc-443cd9e6-3697-5fe9-9a13-34b8a594d58b"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source
media="(prefers-color-scheme: light)"
srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img
alt="Open in Cursor" width="131" height="28"
src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> </p>
<!-- CURSOR_AGENT_PR_BODY_END -->
Co-authored-by: Cursor Agent <cursoragent@cursor.com>
Co-authored-by: hellovai <hellovai@users.noreply.github.com> Recursive SpannedTypeExpr for precise type-error diagnostics
Before this change, type expressions were stored as a single TypeExpr plus
one span, so diagnostics (e.g. "unresolved type") pointed at the whole
annotation. Now every sub-expression has its own span, so we can highlight
only the part that's wrong.
Examples of impact:
- Union with one bad member: For `x: int | sring | bool`, we now underline
only `sring` (e.g. 14..20) with "unresolved type: `sring`" instead of
the whole `int | sring | bool`.
- Bad return type: For `function f() -> DoesNotExist { ... }`, the error is
on `DoesNotExist` (e.g. 16..28), not the entire `-> DoesNotExist`.
- Missing return: For a function declared `-> int` with no return, the
"missing return" diagnostic is on the return type annotation `: int`
(e.g. 16..19), not the block body, so it's clear which function is wrong.
- Parameter type: For `fn f(x: Nonexistent)`, the diagnostic targets the
`Nonexistent` token (e.g. 11..25), not the whole parameter.
What changed:
- AST: SpannedTypeExpr is recursive (SpannedTypeExprKind with spanned
children). Add to_type_expr() for span-free TypeExpr.
- CST→AST: Type lowering produces SpannedTypeExpr with per-node
trimmed_text_range(); lower_cst uses it directly.
- HIR: SignatureSourceMap stores full SpannedTypeExpr trees for params,
return, and throws.
- TIR: Add lower_spanned_type_expr(), report (TirTypeError, span) per node;
use for return/param/field/alias. Report "missing return" on return-type
span via return_type_span.
- LSP: check uses lower_spanned_type_expr for precise spans.
- Syntax: UnionMemberParts::text_range(), TypeExpr::trimmed_text_range().
- Tests and tools_onionskin updated; UnresolvedType message uses backticks.
Made-with: Cursor Active Branches
#32200%
#3206-53%
#3215-33%
© 2026 CodSpeed Technology