Summary
forge captures the distribution/install requirement in Phase 1 but never fulfills it. Add a lightweight packaging capability that produces the easiest fitting artifact and publishes it to the GitHub Release, plus an advisory that tells the user what heavier options they may want to consider without forge implementing them.
The gap
- Phase 1 (
forge-spec) already asks "how this reaches users, and how version two reaches them afterward" and records a distribution/update story, and it already knows the usage type (CLI, desktop, web, phone).
- Phase 2 (
forge-env) and Phase 3 (forge-code) never consume that answer. The release step ends at git-cliff changelog, annotated tag, gh GitHub Release, and a MILESTONE note. No artifact is built.
So the requirement is captured and then dropped. This issue closes that gap while staying inside forge's existing "ends at a tagged GitHub release" boundary.
Scope (deliberately narrow)
forge produces the easy artifact and tells you what else to consider. It never silently does the hard, trust-sensitive parts (signing, notarization, app stores, package registries, auto-update). Those stay user-owned.
Two moves, both extensions of existing behavior (not a new phase)
- Advise at spec time (Phase 1). Turn the existing distribution question into a recommendation: the easiest fitting packaging mechanism, recommended, with heavier options named but explicitly handed to the user. Record the chosen mechanism in the SRS so Phase 3 can act on it.
- Produce the easy artifact at release time (Phase 3). Extend the existing GitHub Release step to build one simple artifact, smoke-test it (extract/run on a clean spot, in forge's "verify positively" spirit), and attach it to the release. Nothing more.
Easiest-means tier
- Versioned zip or tarball of the build output. Cross-platform, near-zero cost, sane default, always available.
- Self-extracting exe (7-Zip SFX). Double-click Windows unpacker. Easy, fits forge's current Windows/PowerShell reality.
- MSI (WiX). Optional upgrade when a true install experience matters (Add/Remove Programs, Start Menu). Real authoring learning curve, so NOT part of the easy default.
For CLI tools and libraries, a single-binary release asset or a registry publish is the natural easy path; forge should mention the registry option in the advisory but default to the GitHub release asset per the GitHub-centric intent.
Where it meshes, and where it does not
Meshes cleanly for CLI tools, libraries, and Windows desktop apps. Attaching a release asset is already covered by forge's always-strict "publishing a release" gate.
Does not mesh, and the advisory must name each rather than emit something meaningless:
- Web apps and services: no installable artifact; packaging there means deployment, which forge does not own. Advise and produce nothing.
- Cross-platform desktop: a Windows SFX/MSI helps only Windows users; mac/Linux (
.dmg, .deb, etc.) are user-guided. Internally consistent with Phase 2 being Windows-specific today, but state it plainly.
- Unsigned binaries: even a simple exe/MSI is unsigned by default and trips SmartScreen/Gatekeeper. Warn about this rather than silently shipping a flagged artifact. Signing stays user-owned.
Acceptance criteria (draft)
- Phase 1 records a concrete packaging mechanism decision (or an explicit "not applicable, hosted service") tied to the usage type, with heavier options listed as user-owned.
- Phase 3 release, when a simple artifact applies, builds it, smoke-tests it on a clean target, and attaches it to the GitHub Release; when it does not apply, it says why and attaches nothing.
- The unsigned-binary warning appears whenever an exe or MSI is produced.
- No new always-on dependency: the zip/tarball path uses tooling already present; SFX/MSI paths are provisioned only when that mechanism is chosen.
- README and the guide updated to reflect that forge now produces an easy artifact and advises on the rest.
Notes
Guiding principle to preserve: forge produces the easy artifact and tells you what else to consider; it never silently does the hard, trust-sensitive parts. This keeps the feature inside forge's existing character and gate model.
Summary
forge captures the distribution/install requirement in Phase 1 but never fulfills it. Add a lightweight packaging capability that produces the easiest fitting artifact and publishes it to the GitHub Release, plus an advisory that tells the user what heavier options they may want to consider without forge implementing them.
The gap
forge-spec) already asks "how this reaches users, and how version two reaches them afterward" and records a distribution/update story, and it already knows the usage type (CLI, desktop, web, phone).forge-env) and Phase 3 (forge-code) never consume that answer. The release step ends at git-cliff changelog, annotated tag,ghGitHub Release, and a MILESTONE note. No artifact is built.So the requirement is captured and then dropped. This issue closes that gap while staying inside forge's existing "ends at a tagged GitHub release" boundary.
Scope (deliberately narrow)
forge produces the easy artifact and tells you what else to consider. It never silently does the hard, trust-sensitive parts (signing, notarization, app stores, package registries, auto-update). Those stay user-owned.
Two moves, both extensions of existing behavior (not a new phase)
Easiest-means tier
For CLI tools and libraries, a single-binary release asset or a registry publish is the natural easy path; forge should mention the registry option in the advisory but default to the GitHub release asset per the GitHub-centric intent.
Where it meshes, and where it does not
Meshes cleanly for CLI tools, libraries, and Windows desktop apps. Attaching a release asset is already covered by forge's always-strict "publishing a release" gate.
Does not mesh, and the advisory must name each rather than emit something meaningless:
.dmg,.deb, etc.) are user-guided. Internally consistent with Phase 2 being Windows-specific today, but state it plainly.Acceptance criteria (draft)
Notes
Guiding principle to preserve: forge produces the easy artifact and tells you what else to consider; it never silently does the hard, trust-sensitive parts. This keeps the feature inside forge's existing character and gate model.