Product decisions needed for v1 #13

New issue

deadstyle · 2026-10-01T21:55:17-05:00

deadstyle commented

2026-10-01 21:55:17 -05:00

Problem

A handful of product decisions affect how v1 behaves. Engineering can build sensible defaults for all of them, but they're the PM's calls. Recording them here keeps them from being decided by accident in code.

Decisions needed

Each lists the options and their user-visible consequences, plus a recommendation.

j at the bottom of a box. (a) stop, like lazygit; (b) carry on into the next box. Recommend (a): predictable, and tab/1–5 already move between boxes.
Should the focused box grow? (a) yes, as in the mockup; (b) fixed sizes. Recommend (a): more rows where your attention is.
Refresh. (a) manual r only; (b) also refresh in the background every N minutes. Recommend (b) with N=5, off for GitHub until rate-limit handling exists.
Merge strategy. (a) always the repo's default from the forge; (b) a config override per host. Recommend (a) for v1.
Batched Renovate PRs in "Updates by dependency". One weekly PR can carry ten Go packages. (a) the PR appears under each package, and merging from any of them merges the whole batch (the dialog says so); (b) batches appear as their own rows ("Go non-major ×3 repos"), and only single-package PRs are grouped by package. Recommend (b): it matches how our preset actually opens PRs. Either way, the merge confirmation lists every package each PR carries, so nothing merges unseen (plan review, #17).
Boxes. Is [1]–[5] (PRs, Issues, Actions, Renovate, Releases) right, or should Branches or Milestones replace one?

Context

docs/design.md → Open questions. Answers get folded into docs/design.md, and into the affected tickets if they've already been filed.

Added: install and updates

After declining an update. (a) ask again on every launch; (b) offer "skip this version" so it stays quiet until the next release. Recommend (b), with the prompt as Update now? [Y/n/s(kip this version)].
How often to check. (a) every launch, as requested; (b) at most once a day, cached, so offline starts stay instant. Recommend (b). The prompt still appears on the first launch after a release.

Added: plan review (#17)

After a bulk merge where some PRs fail. (a) A results list in the dialog: each PR marked merged, refused ("changed since you confirmed", conflicts) or failed; the failed ones stay marked so m retries just those, after lazyforge re-checks them; (b) stop at the first failure and leave the rest unmerged; (c) a one-line status-bar summary only ("8 merged, 2 failed"). Recommend (a): one flaky CI run shouldn't block eleven good merges, and you can see exactly what happened and retry with one key.
What "every repo on the host" means for ★ Renovate. (a) every repo you can access, which on a big instance includes other people's public repos; (b) repos you own or are a member of (including your orgs); (c) a list you pick in Settings. Recommend (b): it matches where Renovate PRs you'd merge actually live, and it stays small. (c) can come later as an exclusion list. Whatever is chosen, the view shows "scanned X of Y" while loading, and bulk merge says when coverage is incomplete.
★ Renovate [4] Failing / running CI in v1. v1 defers boxes [4] and [5] for regular repos, but the ★ view's [4] is listed too. (a) ship it in v1, built from the CI status already shown on PR rows (no Actions API needed): Renovate PRs whose CI is failing or running; (b) defer it with the regular-repo [4]/[5]. Recommend (a): it's cheap, independent of the Actions API, and it's the list you check before a bulk merge.
R re-run and the Actions box when the forge can't provide them. R is in the keymap but not the v1 action list, and the Actions API on our Forgejo is still being checked (#1). (a) v1 has no R; [3] Actions shows runs only if the API provides them, otherwise it's hidden and CI state still shows on PR rows; o opens the run in the browser; (b) R in v1 where the API supports it. *Recommend (a), revisited once #1 reports: it keeps v1 independent of an API we haven't confirmed.*13. What counts as "the same update" in Updates by dependency. The design keys on package + from + to. In practice repos start from different versions: actions/checkout is v3 → v7 in one repo and v4 → v7 in another (#2). (a) group by package + target version: one row "actions/checkout → v7 · 2 repos", and the row shows the from-versions; (b) keep from in the key: two rows, one per starting version. Recommend (a): the thing you're deciding is "move everything to v7", and splitting by starting version doubles the rows without changing the decision.

## Problem A handful of product decisions affect how v1 behaves. Engineering can build sensible defaults for all of them, but they're the PM's calls. Recording them here keeps them from being decided by accident in code. ## Decisions needed Each lists the options and their user-visible consequences, plus a recommendation. 1. **`j` at the bottom of a box.** (a) stop, like lazygit; (b) carry on into the next box. *Recommend (a): predictable, and `tab`/`1`–`5` already move between boxes.* 2. **Should the focused box grow?** (a) yes, as in the mockup; (b) fixed sizes. *Recommend (a): more rows where your attention is.* 3. **Refresh.** (a) manual `r` only; (b) also refresh in the background every N minutes. *Recommend (b) with N=5, off for GitHub until rate-limit handling exists.* 4. **Merge strategy.** (a) always the repo's default from the forge; (b) a config override per host. *Recommend (a) for v1.* 5. **Batched Renovate PRs in "Updates by dependency".** One weekly PR can carry ten Go packages. (a) the PR appears under each package, and merging from any of them merges the whole batch (the dialog says so); (b) batches appear as their own rows ("Go non-major ×3 repos"), and only single-package PRs are grouped by package. *Recommend (b): it matches how our preset actually opens PRs.* Either way, the merge confirmation lists every package each PR carries, so nothing merges unseen (plan review, #17). 6. **Boxes.** Is `[1]`–`[5]` (PRs, Issues, Actions, Renovate, Releases) right, or should Branches or Milestones replace one? ## Context `docs/design.md` → Open questions. Answers get folded into `docs/design.md`, and into the affected tickets if they've already been filed. ## Added: install and updates 7. **After declining an update.** (a) ask again on every launch; (b) offer "skip this version" so it stays quiet until the next release. *Recommend (b), with the prompt as `Update now? [Y/n/s(kip this version)]`.* 8. **How often to check.** (a) every launch, as requested; (b) at most once a day, cached, so offline starts stay instant. *Recommend (b). The prompt still appears on the first launch after a release.* ## Added: plan review (#17) 9. **After a bulk merge where some PRs fail.** (a) A results list in the dialog: each PR marked merged, refused ("changed since you confirmed", conflicts) or failed; the failed ones stay marked so `m` retries just those, after lazyforge re-checks them; (b) stop at the first failure and leave the rest unmerged; (c) a one-line status-bar summary only ("8 merged, 2 failed"). *Recommend (a): one flaky CI run shouldn't block eleven good merges, and you can see exactly what happened and retry with one key.* 10. **What "every repo on the host" means for ★ Renovate.** (a) every repo you can access, which on a big instance includes other people's public repos; (b) repos you own or are a member of (including your orgs); (c) a list you pick in Settings. *Recommend (b): it matches where Renovate PRs you'd merge actually live, and it stays small. (c) can come later as an exclusion list.* Whatever is chosen, the view shows "scanned X of Y" while loading, and bulk merge says when coverage is incomplete. 11. **★ Renovate `[4]` Failing / running CI in v1.** v1 defers boxes `[4]` and `[5]` for regular repos, but the ★ view's `[4]` is listed too. (a) ship it in v1, built from the CI status already shown on PR rows (no Actions API needed): Renovate PRs whose CI is failing or running; (b) defer it with the regular-repo `[4]`/`[5]`. *Recommend (a): it's cheap, independent of the Actions API, and it's the list you check before a bulk merge.* 12. **`R` re-run and the Actions box when the forge can't provide them.** `R` is in the keymap but not the v1 action list, and the Actions API on our Forgejo is still being checked (#1). (a) v1 has no `R`; `[3]` Actions shows runs only if the API provides them, otherwise it's hidden and CI state still shows on PR rows; `o` opens the run in the browser; (b) `R` in v1 where the API supports it. *Recommend (a), revisited once #1 reports: it keeps v1 independent of an API we haven't confirmed.*13. **What counts as "the same update" in Updates by dependency.** The design keys on package + from + to. In practice repos start from different versions: `actions/checkout` is v3 → v7 in one repo and v4 → v7 in another (#2). (a) group by package + target version: one row "actions/checkout → v7 · 2 repos", and the row shows the from-versions; (b) keep from in the key: two rows, one per starting version. *Recommend (a): the thing you're deciding is "move everything to v7", and splitting by starting version doubles the rows without changing the decision.*

deadstyle added the

feature

label

Rows
Columns