feat: add --prebuilt flag to setup command

[ygd58]

Summary

Refs #33.

Adds --prebuilt flag to logos-scaffold setup that downloads pre-compiled sequencer_service binary instead of building from source (~15 min build penalty). Falls back to source build if no prebuilt exists.

Design Question

Issue #33 proposes tagging prebuilt artifacts as lssa-prebuilt-<commit-hash>-<arch>. This PR implements the scaffold-side download logic using tag format lez-prebuilt-<commit8>-<arch>-<os> on logos-co/logos-scaffold releases.

Open question: Should prebuilt artifacts be hosted on logos-co/logos-scaffold releases, or on logos-blockchain/logos-execution-zone releases? The binaries are LEZ artifacts so LEZ releases may be more natural. Happy to update the URL if there is a preferred host.

End-to-End Verification

Fresh project, flag accepted, fallback works correctly:

$ logos-scaffold new prebuilt-test
$ cd prebuilt-test
$ logos-scaffold setup --prebuilt

Checking for prebuilt binaries (tag: lez-prebuilt-35d8df0d-x86_64-linux)...
no prebuilt found for tag lez-prebuilt-35d8df0d-x86_64-linux, falling back to source build...
...
setup complete

Local Checks

• cargo build ✅
• cargo test: 59 passed, 3 pre-existing failures in repo::tests (present on master too) ✅
• cargo fmt --check ✅

What is NOT in this PR

• Release pipeline publishing prebuilt artifacts (LEZ CI concern)
• wallet binary download (follow-up per issue feat: support prebuilt binaries to skip compile-from-source on setup #33)
• artifacts/program_methods/*.bin download (follow-up per issue feat: support prebuilt binaries to skip compile-from-source on setup #33)

[fryorcraken]

Thanks @ygd58. The review findings point at process gaps worth closing first. Please revise against the points below, then ping me for another pass. The repo's CONTRIBUTING.md is the contract these come from.

• Read the contract before pushing — the PR template is part of it
• Engage with the design question, not just the symptom
• Run the change end-to-end against a real project before opening
• Read your own diff and run the local checks

[ygd58]

Understood. Will revise against the CONTRIBUTING.md requirements:

1. Read the contract and fill PR template properly
2. Engage with the design question — prebuilt binaries need a concrete release workflow on the LEZ side first
3. Run end-to-end against a real project before reopening

Will close this PR for now and reopen when I have a tested implementation with a real downstream project verified.

[ygd58]

After re-reading CONTRIBUTING.md and thinking through the design question:

The --prebuilt flag requires someone to publish pre-compiled binaries at the expected GitHub release tag format (lez-prebuilt---). Without a release pipeline on the LEZ side, the flag always falls back to source build making it a no-op for any real user today.

The real friction point this addresses (15+ min compile time on setup) is valid, but the correct fix may be on the LEZ side first (a CI workflow that publishes prebuilt artifacts per pin). I don't have a real project where I've hit this friction and verified the full flow works end-to-end.

Will close this PR until either: (a) LEZ publishes prebuilt artifacts at a known URL format, or (b) there is a concrete user request with a tested workflow.

[ygd58]

Working through the CONTRIBUTING.md checklist:

Design question: The flag requires prebuilt artifacts published at a known URL. Issue #33 proposes tagging them as lssa-prebuilt-- but doesn't specify which repo hosts them. Before I can run a real end-to-end test (flag downloads actual binary), I need to know: is there an existing or planned release pipeline for LEZ prebuilt artifacts, or should this PR also propose the tag format and hosting location?

Currently the flag always falls back to source build (no artifacts exist yet), so end-to-end I can verify: flag is accepted, fallback works, source build completes. But I cannot verify the download path without published artifacts.

Happy to also add wallet and artifacts/program_methods/*.bin to the download scope if that's in scope for this PR.

[ygd58]

Addressed all four points from CONTRIBUTING.md:

1. Contract read — reviewed CONTRIBUTING.md and DOGFOODING.md requirements
2. Design question engaged — PR description now explicitly addresses the hosting question (logos-scaffold releases vs LEZ releases) and notes what's out of scope
3. End-to-end verified — ran logos-scaffold setup --prebuilt on a fresh project; flag is accepted, prebuilt check runs, fallback to source build works correctly
4. Diff reviewed + local checks — cargo build, cargo test (59 pass, 3 pre-existing failures on master), cargo fmt --check all pass

Ready for another pass when you have time @fryorcraken.

[weboko]

this PR needs update

[ygd58]

Actualized against current upstream master. Re-applied prebuilt flag on top of latest codebase. All 297 lib tests pass. @weboko

[weboko]

@ygd58 can you do it once more, please?

[ygd58]

Updated against latest master. All tests pass (pre-existing repo::tests and GPG-dependent test failures are unrelated). @weboko

[weboko]

Hey @ygd58 , thanks for the iteration. I pulled the branch, reran D1, and read through the diff — a few things need addressing before this is mergeable.

Happy to re-review once the duplicate spel block and wallet-skip behavior are fixed; the rest can land alongside or in a follow-up but should at least have a tracking decision in this thread.

Here is a list I made with AI for you:

Blockers

1. Duplicate spel sync + build. src/commands/setup.rs:75-85 repeats lines 63-73 verbatim — the spel block was added twice during the recent merge-conflict resolution. Setup runs git fetch --all --tags against the spel remote twice and invokes cargo build -p spel twice. Confirmed at runtime: 2× spel cargo invocations, 3× git fetch in the setup log. Please drop the second copy.

2. Wallet binary is skipped when prebuilt succeeds. The cargo build -p wallet step was moved inside if !built_from_prebuilt, so a successful prebuilt download leaves <lez>/target/release/wallet missing. Every wallet flow (wallet_support.rs:29, doctor.rs:168, constants.rs:63 WALLET_BIN_REL_PATH) depends on that path, and DOGFOODING D1 explicitly expects "setup completes after… building both sequencer_service and wallet". Today this is masked because no prebuilt artifacts exist (URL 404s and we fall back), but the moment one is published the contract silently breaks. Either move the wallet build out of the conditional, or add a parallel wallet download.

Should fix before merge

3. Hosting + tag schema still unresolved. Issue feat: support prebuilt binaries to skip compile-from-source on setup #33 specifies lssa-prebuilt-…; this PR uses lez-prebuilt-… and points at logos-co/logos-scaffold releases. Until LEZ (or scaffold) actually publishes artifacts, --prebuilt is a no-op in production. Please coordinate with feat: support prebuilt binaries to skip compile-from-source on setup #33 and settle on one tag format + one host before this lands.

4. Err(_) swallows everything. setup.rs:267 — DNS failure, 5xx, TLS error, partial download, and 404 all print the same "no prebuilt found, falling back". A user opting into --prebuilt should be able to tell "artifact not published yet" from "your network is broken".

5. No integrity check. try_download_prebuilt writes whatever bytes come back, chmods 0755, and runs it. Please add at least a SHA256 alongside the release asset.

6. Arch/OS detection is wrong by default. cfg!(target_arch = "x86_64") else "aarch64" and cfg!(target_os = "linux") else "macos" — Windows/BSD users get a tag that doesn't exist and a confusing 404. Either enumerate explicitly or refuse to run on unsupported targets.

7. cmd_build_shortcut always passes prebuilt=false (build.rs:16), so lgs build — the shortcut that runs setup transparently — can't benefit from prebuilt. Either plumb the flag through or document the inconsistency.

8. No tests. Nothing covers try_download_prebuilt (URL/tag builder, fallback path, wallet-skip behavior). At minimum a unit test on the tag-string assembly.

9. DOGFOODING.md not updated. CONTRIBUTING.md asks for runbook updates on user-facing changes. D1's "Expected Success Signals" need to describe the prebuilt variant (and what happens to the wallet binary when prebuilt succeeds).

[ygd58]

All items addressed including SHA256 integrity check — downloads .sha256 alongside the binary and verifies before writing to disk. @weboko