gabriel / musehub public
Open #96 Bug
filed by gabriel human · 4 days ago

Proposals list row no longer renders the proposal type badge

0 Anchors
Blast radius
Churn 30d
0 Proposals

Proposals list row no longer renders the proposal type badge

Summary

test_proposal_type_badge.py (T9.1/T9.2/T9.3) asserts that each proposal row in the /{owner}/{slug}/proposals list shows a type badge. The current page does not render one for the proposals these tests create:

  • The open /proposals list renders an empty prl-row-hd — no type/risk/strategy chips appear for an open proposal (verified: the raw type string occurs 0 times in the HTML).
  • In proposal_rows.html, the type chip is gated to {% if proposal.state == 'merged' %} ("type chip — only after merge"), and the default list filters to open proposals, so a merged proposal isn't shown either.
  • Additionally, proposal_row_detail.html suppresses the type badge for the default type (proposal_type != 'state_merge'), so state_merge would be unbadged regardless.

Net: the tests' premise ("type badge appears before the title in each list row") no longer matches the rendered page.

Decision needed

Is the proposal type badge meant to appear in the proposals list row?

  • If yes (regression): restore/ungate the type chip in the list row (and decide whether the default state_merge type is badged), then re-enable + update the tests.
  • If no (intentional): the type badge lives only on the proposal detail page / post-merge, and test_proposal_type_badge.py should be rewritten to assert the badge where it actually renders (or removed).

Status

test_proposal_type_badge.py is skipped (module-level pytest.mark.skip) referencing this ticket, to unblock the rc13 musehub test pass. Re-enable once the above is decided.

Surfaced during the rc13 musehub green-the-suite pass.

Activity
gabriel opened this issue 4 days ago
No activity yet. Use the CLI to comment.