Feat/reporter extension (#463)

* feat: add initial reporter extension

* feat: add deploy, codegen, and dev hooks

* feat: add config parsing for extensions

* feat: add documentation

* feat: clean up build output and allow verbose flag

* feat: test all extension hooks

* chore: add tests for reporter

* chore: format

* chore: fix Rust versions

* fix: deprecated cargo_bin macro

* fix: add workaround for reporter dependency in tests

* chore: move Reporter tests to own crate

* fix: build hook test

* fix: reporter integration test

* feat: add unchanged deploy state

* fix: address review findings on reporter extension (#472)

- state::save now returns io::Result and callers log on failure via a
  save_state helper, instead of silently dropping state writes
- read_stdin returns Option<T>; the reporter logs a diagnostic and
  degrades gracefully on bad input instead of panicking and surfacing
  as a non-zero extension exit
- HookName and DeployKind are marked #[non_exhaustive] so adding a
  hook or deploy kind in the future is not a breaking change for
  external extension authors consuming stellar-scaffold-ext-types
- Drop unused thiserror dependency from the reporter crate
- Remove a stale TODO comment in report.rs whose behavior is already
  correct

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* fix: ensure post-codegen hook fires on error and propagate codegen failures

`generate_contract_bindings` previously short-circuited via `?` inside the
rebuild block, so PostCodegen was skipped whenever any inner step (bindings
typescript, npm install/build, fs ops, create_contract_template) returned
Err. Combined with `handle_contracts` swallowing per-contract errors, this
made the build exit 0 while a hook that consumers rely on never fired —
exactly the failure mode of `extension_hooks_fire_in_order`.

Restructure so PostCodegen always fires after the fallible work, then
propagate the error via a new CodegenStepFailed variant. `handle_contracts`
now counts failures and returns ContractClientFailures so a broken codegen
step can no longer masquerade as a successful build. Adds a regression test
that shims npm to fail and asserts both pre- and post-codegen still appear.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* revert: restore non-fatal handle_contracts; drop ContractClientFailures

Reverts the handle_contracts change from 590a1a5. That commit made
per-contract codegen failures propagate as a build error, but
`build_clients::contracts::contracts_with_failures_show_summary` explicitly
asserts `build.success()` while showing per-contract success/fail messages —
non-fatal contract failures are documented behavior, not an oversight.

Propagation also surfaced pre-existing real codegen failures in several
example contracts (case_02_account, case_17, case_18) that had been
silently swallowed; restoring or expecting those is out of scope for this
fix.

The PostCodegen-on-error fix and its regression test remain.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Willem Wyndham <willem@ahalabs.dev>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: 3 people

.github/workflows/tests.yml

@@ -41,12 +41,13 @@ jobs:
       - run: just build
       - run: just build-cli-test-contracts
       - name: Create nextest archive
-        run: cargo nextest archive --archive-file nextest-archive.tar.zst --package stellar-scaffold-cli --package stellar-registry-cli --features integration-tests
+        run: cargo nextest archive --archive-file nextest-archive.tar.zst --package stellar-scaffold-cli --package stellar-registry-cli --package stellar-scaffold-reporter --features integration-tests
       - name: Package runtime artifacts
         run: |
           tar -cf - \
             target/debug/stellar-scaffold \
             target/debug/stellar-registry \
+            target/debug/stellar-scaffold-reporter \
             target/stellar/local/ \
             crates/stellar-scaffold-test/fixtures/soroban-init-boilerplate/target/stellar/local/ \
             | zstd -1 -o runtime-artifacts.tar.zst
@@ -81,6 +82,8 @@ jobs:
             filter: "test-integration-scaffold-examples-2"
           - name: registry-cli
             filter: "test-integration-registry"
+          - name: reporter
+            filter: "test-integration-reporter"
     env:
       STELLAR_RPC_URL: http://localhost:8000/soroban/rpc
       STELLAR_NETWORK_PASSPHRASE: "Standalone Network ; February 2017"

Cargo.lock

@@ -5,7 +5,7 @@
 
 **Scaffold Stellar** is a developer toolkit for building decentralized applications (dApps) and smart contracts on the [**Stellar** blockchain](https://stellar.org).
 
-It helps you go from **idea** to **working full-stack dApp** faster — by providing CLI tools, reusable contract templates, a smart contract registry, and a modern frontend.
+It helps you go from **idea** to **working full-stack dApp** faster by providing CLI tools, reusable contract templates, a smart contract registry, and a modern frontend.
 
 ---
 
@@ -143,6 +143,28 @@ stellar registry install my-contract-instance                           # Instal
 > Use `--help` on any command for usage instructions.
 
 ---
+
+## Extensions
+
+Scaffold Stellar's build pipeline supports extensions by calling binaries on your PATH that tap into lifecycle hooks fired before and after each compile, deploy, codegen, and watch cycle.
+
+The built-in **[Scaffold Reporter](./crates/stellar-scaffold-reporter/)** extension is included in every new project. It logs compile times, WASM sizes, deploy durations, and total build cycle time directly to your console.
+
+Register extensions in `environments.toml`:
+
+```toml
+[development]
+extensions = ["reporter"]
+
+# Optional per-extension config:
+[development.ext.reporter]
+warn_size_kb = 128
+```
+
+See the [Extensions Guide](https://scaffoldstellar.com/docs/extensions) to learn how the hook system works and how to build your own extension.
+
+---
+
 ## Smart Contract Deployment
 
 ### 1. Publish Your Contract
@@ -248,7 +270,7 @@ Ask questions in the repo Discussions tab
 
 Search [DeepWiki](https://deepwiki.org/)
 
-Or just open an issue — we're happy to help!
+Or just open an issue. We're happy to help!
 
 Happy hacking!
 ---

README.md

@@ -1,3 +1,23 @@
 fn main() {
     crate_git_revision::init();
+
+    // cargo_bin!("stellar-scaffold-reporter") in integration tests expands to
+    // env!("CARGO_BIN_EXE_stellar-scaffold-reporter"), which Cargo sets for
+    // same-package binaries and dev-dependency binaries during `cargo test` but
+    // NOT during `cargo clippy --tests`.  Emitting it here ensures it is always
+    // present at compile time regardless of how the crate is being built.
+    let out_dir = std::env::var("OUT_DIR").unwrap();
+    // OUT_DIR = target/<profile>/build/<hash>/out — 3 levels up is target/<profile>/
+    let target_dir = std::path::Path::new(&out_dir).ancestors().nth(3).unwrap();
+    let exe_suffix = if cfg!(target_os = "windows") {
+        ".exe"
+    } else {
+        ""
+    };
+    println!(
+        "cargo:rustc-env=CARGO_BIN_EXE_stellar-scaffold-reporter={}",
+        target_dir
+            .join(format!("stellar-scaffold-reporter{exe_suffix}"))
+            .display()
+    );
 }