Skip to content

Actions: SatoshiPortal/bullbitcoin-mobile

Actions

Claude Code

Actions

Loading...
Loading

Show workflow options

Create status badge

Loading
claude.yml
2,208 workflow runs
2,208 workflow runs

Filter by Event

⌥ + click/return to exclude

Filter by Status

⌥ + click/return to exclude

Filter by Branch

⌥ + click/return to exclude

Filter by Actor

⌥ + click/return to exclude
Origin shouldn’t be required in the facade Label since it is an optional field. Claude Code #333: Issue comment #1812 (comment) created by ethicnology
21s
21s
Add page.dart into UI folder outside of presentation folder. We might create other screens and label related widgets that could be put in UI too then and pure UI is something that can be embedded in other features without problems, while the presentation folder should be more about the controllers (BLoC/Cubit) which I think shouldn't be used from other features. Claude Code #332: Issue comment #1810 (comment) created by ethicnology
18s
18s
The delete label usecase should use the entity id imo instead of bip329 terms. It gives a cleaner api. Claude Code #331: Issue comment #1805 (comment) created by kumulynja
17s
17s
FetchDistinctLabelsUsecase is not very understandable. Is it even possible that two labels on the same target are the same if the constraints are correctly set in the db? And if this is for filtering for showing it in the UI, I don’t think this use case should even exist here. In that case, the presentation layer should do the filtering and decide which label of which target to show or to show that this label is set on both address as utxo for example. But this is not something to have a separate usecase for I feel. Claude Code #330: Issue comment #1807 (comment) created by kumulynja
14s
14s
FetchLabelByReferenceUsecase feels like a pure BIP329 usecase, better to have a getLabelById usecase now that we have id's. Or at least have both and if the callers that need this have the id it would be better if they fetch by id if possible. Claude Code #329: Issue comment #1808 (comment) created by ethicnology
15s
15s
FetchDistinctLabelsUsecase is not very understandable. Is it even possible that two labels on the same target are the same if the constraints are correctly set in the db? And if this is for filtering for showing it in the UI, I don’t think this use case should even exist here. In that case, the presentation layer should do the filtering and decide which label of which target to show or to show that this label is set on both address as utxo for example. But this is not something to have a separate usecase for I feel. Claude Code #328: Issue comment #1807 (comment) created by ethicnology
15s
15s
Remove LabelExchangeOrderUsecase and create a labels migration Claude Code #327: Issue comment #1794 (comment) created by kumulynja
15s
15s
The delete label usecase should use the entity id imo instead of bip329 terms. It gives a cleaner api. Claude Code #326: Issue comment #1805 (comment) created by ethicnology
22s
22s
StoreLabelModel naming is a bit confusing since models are usually more related to frameworks in the Clean Architecture context, or models usually have behaviour (extra functions) as well, but here we just want plain data to cross the application layer border, so I wouldn’t call it a model. Shall we define to call it ApplicationLabel so the boundary is explicit in the naming and we don’t use Model or DTO or any other term that we don't like? Claude Code #325: Issue comment #1804 (comment) created by ethicnology
18s
18s
The LabelEntity is too linked to bip329 specs still, it is also unclear if it is a system label or not. This is a custom concept for our app, since it is the business that wants us to label things automatically. So this should reflect in the domain and be more explicit instead of needing to parse the label itself (which isn’t even clear from looking at the domain if that’s the way to know). Introducing a Provenance concept would help. Claude Code #324: Issue comment #1799 (comment) created by ethicnology
18s
18s
Also, the id was added, but it is not used anywhere, so this addition doesn't add what it should be adding at the moment, everything is still by reference. We need the facade and use cases to use id, not the bip329 reference, otherwise there is still no way to edit a label cleanly and easily. Claude Code #323: Issue comment #1801 (comment) created by ethicnology
15s
15s
id should not be optional, but required, in the entity Claude Code #322: Issue comment #1800 (comment) created by ethicnology
15s
15s
Exchange virtual iban Claude Code #321: Pull request #1797 created by kumulynja
16s
16s
Remove LabelExchangeOrderUsecase and create a labels migration Claude Code #320: Issue comment #1794 (comment) created by ethicnology
20s
20s
Exchange virtual iban Claude Code #319: Pull request #1797 created by kumulynja
23s
23s
Exchange virtual iban Claude Code #318: Pull request #1797 created by kumulynja
23s
23s
Exchange virtual iban Claude Code #317: Pull request #1797 created by kumulynja
17s
17s
Exchange virtual iban Claude Code #316: Pull request #1797 created by kumulynja
20s
20s
Exchange virtual iban Claude Code #315: Pull request #1797 created by kumulynja
17s
17s
Exchange virtual iban Claude Code #314: Pull request #1797 created by kumulynja
19s
19s
Exchange virtual iban Claude Code #313: Pull request #1797 created by kumulynja
21s
21s
Exchange virtual iban Claude Code #312: Pull request #1797 created by kumulynja
19s
19s
Exchange virtual iban Claude Code #311: Issue comment #1797 (comment) created by mocodesmo
16s
16s
Remove LabelExchangeOrderUsecase and create a labels migration Claude Code #310: Issue comment #1794 (comment) created by kumulynja
20s
20s
BREAKING CHANGE: refactor labels with the new architecture Claude Code #309: Pull request #1784 created by kumulynja
21s
21s
ProTip! You can narrow down the results and go further in time using created:<2026-01-20 or the other filters available.