Clarify SEP-58 scope to common workflow (#1964)

Author: leighmcculloch

ecosystem/sep-0058.md

@@ -6,8 +6,8 @@ Title: Contract Build Reproducibility for Verification
 Author: Leigh McCulloch <@leighmcculloch>
 Status: Draft
 Created: 2026-05-01
-Updated: 2026-06-16
-Version: 0.4.0
+Updated: 2026-06-18
+Version: 0.5.0
 Discussion: https://github.com/orgs/stellar/discussions/1923
 ```
 
@@ -243,6 +243,9 @@ lives.
 
 - This SEP defines a vocabulary, and a mechanism, not a complete
   implementation.
+- The vocabulary targets the common build workflow, not every possible build; a
+  bespoke workflow's build inputs may not be fully expressible, by design (see
+  [Design Rationale](#design-rationale)).
 - It captures the build environment and source identity, not whether the source
   itself is trustworthy, audited, or non-malicious; that is an orthogonal
   concern.
@@ -253,6 +256,15 @@ lives.
 
 ## Design Rationale
 
+**Why target the common build workflow rather than every workflow?** The
+vocabulary captures the common contract build workflow, not every possible
+build. A bespoke workflow's build inputs may not be fully expressible, and that
+is acceptable. If the proposal sought to satisfy every possible build workflow
+it would grow without bound and could not realistically be completed. The goal
+is for contracts to converge towards the workflow supported by this proposal,
+not for this proposal to expand to satisfy every build workflow. The vocabulary
+can expand, but it should do so when it serves the common workflow.
+
 **Why a vocabulary, not an algorithm?** Verification practice is still emerging
 across CIs, registries, on-chain indexes, and ad-hoc scripts. Locking in one
 workflow would close off useful directions; a shared vocabulary lets
@@ -435,6 +447,7 @@ the rebuilt wasm to the original is the verification result.
 
 ## Changelog
 
+- `v0.5.0` - Clarified that this proposal targets the common build workflow.
 - `v0.4.0` - Replaced the
   `source_repo`/`source_rev`/`tarball_url`/`tarball_sha256`
   source-identification fields with a required `source_sha256` and an optional