Close nine armchair-decidable open questions across four docs
None of these needed hardware, a benchmark, or a design pass — they
were the kind of decision that gets stuck in "obvious answer, nobody
wrote it down." Landing the recommendations, keeping the true
verification/design-pass items open.
SHELL.md — all three closed:
- root login shell: bash (recovery isn't the moment for surprises;
nu remains in /etc/shells for chsh).
- history backend: sqlite (better search; atuin path stays open).
- atuin default: defer (adjacent to CONTINUITY, wants its own pass).
CONTINUITY.md — two closed, two kept (verification tasks):
- Syncthing discovery: defaults for v1; expose later if requests.
- First-boot flow: appears once, then alloy tail/sync are the paths.
- Kept: MagicDNS + systemd-resolved verification, Headscale
login-server persistence verification.
IMAGE.md — three closed, two kept:
- Containerfile: multi-stage only where a non-Fedora Rust binary
needs shipping (currently just rust-build for wl-screenrec);
no preemptive stages.
- Tag scheme: :latest + :42 + :42-YYYYMMDD, wired at distribution.
- Kept: Fedora vs COPR audit, bootc-image-builder ISO verification.
CONSOLE.md — two closed, two kept:
- Command-log pane: always on (pedagogy needs it visible).
- Naming: single entry point `alloy config <path>`; no `alloy edit`
alias.
- Kept: schema format design pass, KDL roundtrip verification.
- Co-Authored-By
- Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4 files changed,
+9 insertions,
-9 deletions
| 132 |
132 |
|
|
| 133 |
133 |
|
- [ ] Schema format finalization — the sketch above is a working proposal; needs a design pass with a real target config (probably rio) to shake out gaps.
|
| 134 |
134 |
|
- [ ] KDL editing story — `kdl` crate ecosystem in Rust is less mature than `toml_edit`. Verify roundtrip-safe editing is achievable before committing to the "one editor, both formats" pitch. If not, KDL configs get the text-edit fallback until it is.
|
| 135 |
|
- |
- [ ] Command-log pane visibility — always on, toggleable, or hidden by default? Argument for always-on: the pedagogical claim ("teaches its own primitives") only lands if the log is visible. Argument for hidden: reduces UI noise for repeat users.
|
| 136 |
|
- |
- [ ] Naming: `alloy config <path>` opens the editor. Should `alloy edit <path>` alias it, or is one entry point enough? One is probably right (fewer names to remember), but the mental model "config = editor" may feel awkward for KDL files that aren't strictly "configuration."
|
|
135 |
+ |
- [x] **Command-log pane: always on.** The pedagogical claim ("teaches its own primitives") only lands if the log is visible. Users who dislike it can add a hide toggle later; the shipped default should teach.
|
|
136 |
+ |
- [x] **Naming: one entry point — `alloy config <path>`.** No `alloy edit` alias. Fewer names to remember; the "config = editor" mental model holds for KDL files too — they're structured, machine-editable formats, which is what `alloy config` addresses.
|
| 88 |
88 |
|
## Open questions
|
| 89 |
89 |
|
|
| 90 |
90 |
|
- [ ] MagicDNS interaction with Fedora's `systemd-resolved` — verify no config conflict on a fresh Silverblue install with Tailscale enrolled.
|
| 91 |
|
- |
- [ ] Syncthing's `discosrv` and `relaysrv` — leave at defaults (public infrastructure) or expose configuration in `alloy sync` for users who self-host? Defaults are fine for v1; expose later if requests appear.
|
|
91 |
+ |
- [x] **Syncthing's `discosrv` and `relaysrv`: defaults for v1.** Public infrastructure is fine for the enroll-and-it-works model. Expose configuration in `alloy sync` only if requests appear from users self-hosting the discovery / relay side.
|
| 92 |
92 |
|
- [ ] Headscale login-server field in `alloy tail` enrollment: preserve across `tailscale down` / `tailscale up` cycles automatically, or require re-entry? Automatic is the correct default; verify Tailscale client behavior supports it cleanly.
|
| 93 |
|
- |
- [ ] Whether the first-boot screen should ever appear again if the user skips both. Recommendation: no — it appears once. `alloy tail` and `alloy sync` are the paths after that.
|
|
93 |
+ |
- [x] **First-boot screen appears once.** If the user skips both Tailscale and Syncthing, `alloy tail` and `alloy sync` are the enrollment paths after that; the first-boot flow does not re-appear.
|
| 92 |
92 |
|
|
| 93 |
93 |
|
- [ ] Verify which Alloy packages are in Fedora main vs. need COPRs. Candidates that may need COPRs: `satty`, `wl-screenrec` (depending on Fedora version). Audit at v0 packaging time.
|
| 94 |
94 |
|
- [ ] `bootc-image-builder` for ISO generation. First-time-user path is `bootc install` from a live environment; the ISO is what makes that a smooth experience. Verify the ISO builder handles Alloy's specific package set.
|
| 95 |
|
- |
- [ ] Single-stage vs. multi-stage Containerfile. Single-stage until rebuild time hurts.
|
|
95 |
+ |
- [x] **Containerfile stage policy: multi-stage only where a non-Fedora Rust binary needs to ship.** Currently that's one stage (`rust-build` for wl-screenrec); everything else comes from RPM in the runtime stage. Do not add stages preemptively.
|
| 96 |
96 |
|
- [x] sr.ht account: **`~maxmj`** for v0. LLC-owned `~makecreative` remains the long-term target; migration if/when the project grows.
|
| 97 |
|
- |
- [ ] Whether to publish `:latest`, `:42`, and `:42-YYYYMMDD` tags. Recommend all three — `:latest` for casual users, `:42` for version-pinned users, `:42-YYYYMMDD` for reproducibility.
|
|
97 |
+ |
- [x] **Publish `:latest`, `:42`, and `:42-YYYYMMDD` tags.** `:latest` for casual users, `:42` for version-pinned users, `:42-YYYYMMDD` for reproducibility. Wired up when distribution starts.
|
| 63 |
63 |
|
|
| 64 |
64 |
|
## Open questions
|
| 65 |
65 |
|
|
| 66 |
|
- |
- [ ] Nu vs. bash for root-level shells (`root`'s login shell). Bash is safer for recovery scenarios; nu would be consistent. Recommend bash — recovery is the wrong time to hit a shell surprise. Confirm.
|
| 67 |
|
- |
- [ ] History file backend: `sqlite` (better search, atuin-compatible) vs. `plaintext` (simpler, human-readable). Recommend sqlite; atuin is a natural future adoption for cross-machine history.
|
| 68 |
|
- |
- [ ] Whether Alloy ships atuin integration by default (encrypted history sync via Syncthing or atuin's own server). Adjacent to CONTINUITY.md's theme. Defer.
|
|
66 |
+ |
- [x] **Root login shell: bash.** Recovery is the wrong time to hit a shell surprise. Nu is in `/etc/shells` and reachable via `chsh -s /usr/bin/nu` for users who want consistency.
|
|
67 |
+ |
- [x] **History file backend: sqlite.** Better interactive search; atuin (if adopted later) reads sqlite natively, so no migration on the future path.
|
|
68 |
+ |
- [x] **atuin default: defer.** Encrypted history sync is a real feature but sits adjacent to CONTINUITY.md's Tailscale/Syncthing story and wants its own design pass. Users install atuin themselves in the meantime.
|