refactor: eliminate shell scripts across toolchains for Bazel-native implementation

This comprehensive refactoring modernizes the build system by eliminating 24+ shell
scripts across critical toolchain files and replacing them with Bazel-native approaches.
The changes improve cross-platform compatibility, hermetic builds, and maintainability
while preserving all existing functionality.

## Key Improvements

### Shell Script Elimination (24+ scripts removed):
- **wkg/defs.bzl**: 6 major patterns → ctx.actions.run() with direct tool calls
- **cpp_component_toolchain.bzl**: 6 wrapper patterns → direct symlinks
- **wasm_validate.bzl**: 5 complex scripts → Bazel-native actions with structured mnemonics
- **jco_toolchain.bzl**: 4 exec wrappers → repository_ctx.symlink()
- **wit_deps_check.bzl**: 2 shell patterns → ctx.actions.run() with stdout parameter
- **go/defs.bzl**: 1 simple pattern → ctx.actions.symlink()

### Cross-Platform Compatibility:
- Eliminated Unix-specific shell dependencies (exec, cp, which commands)
- Replaced shell wrappers with platform-agnostic symlinks
- Improved Windows/macOS/Linux compatibility

### Build System Improvements:
- Better action separation with distinct mnemonics for debugging
- Reduced external tool dependencies for hermetic builds
- Cleaner error handling and progress reporting
- More maintainable code with explicit Bazel action declarations

## Preserved Appropriate Complexity

Complex shell scripts were preserved where genuinely necessary:
- **TinyGo path resolution**: Dynamic absolute path calculation required at runtime
- **WIT binding generation**: Complex file discovery patterns
- **Test infrastructure**: Placeholder implementations for development

## Validation

- All builds tested and verified working
- Pre-commit hooks passing (buildifier, clippy, formatting)
- Comprehensive cross-platform path resolution testing
- OCI integration, component signing, and validation workflows confirmed functional

This refactoring exemplifies "The Bazel Way" by using the right tool for each job:
simple operations use Bazel-native approaches while complex orchestration uses
shell scripts where appropriate.

Breaking Changes: None - all existing functionality preserved

Author: avrabe

.github/workflows/docs-deploy.yml

@@ -0,0 +1,53 @@
+name: Deploy Documentation to Netcup
+
+on:
+  push:
+    branches: [main]
+    paths: ['docs-site/**']
+  workflow_dispatch:
+
+jobs:
+  build-and-deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+          cache: 'npm'
+          cache-dependency-path: docs-site/package-lock.json
+
+      - name: Install dependencies
+        run: |
+          cd docs-site
+          npm ci
+
+      - name: Build documentation site
+        run: |
+          cd docs-site
+          npm run build
+
+      - name: Deploy to Netcup hosting
+        uses: SamKirkland/[email protected]
+        with:
+          server: ${{ secrets.NETCUP_URI }}
+          username: ${{ secrets.NETCUP_USER }}
+          password: ${{ secrets.NETCUP_PASSWORD }}
+          local-dir: ./docs-site/dist/
+          server-dir: /
+          exclude: |
+            **/.git*
+            **/.git*/**
+            **/node_modules/**
+            **/.DS_Store
+            **/Thumbs.db
+
+      - name: Purge Cloudflare cache (optional)
+        if: ${{ secrets.CLOUDFLARE_ZONE_ID }}
+        uses: jakejarvis/cloudflare-purge-action@master
+        env:
+          CLOUDFLARE_ZONE: ${{ secrets.CLOUDFLARE_ZONE_ID }}
+          CLOUDFLARE_TOKEN: ${{ secrets.CLOUDFLARE_TOKEN }}

MODULE.bazel.lock

@@ -1,32 +1,32 @@
 {
   "tool_name": "wkg",
-  "github_repo": "bytecodealliance/wkg",
+  "github_repo": "bytecodealliance/wasm-pkg-tools",
   "latest_version": "0.11.0",
-  "last_checked": "2025-01-02T10:30:00Z",
-  "note": "Checksums need verification - current values are placeholders",
+  "last_checked": "2025-08-15T16:00:00Z",
+  "note": "Updated with real checksums from GitHub releases",
   "versions": {
     "0.11.0": {
-      "release_date": "2024-11-15",
+      "release_date": "2025-06-19",
       "platforms": {
         "darwin_amd64": {
-          "sha256": "PLACEHOLDER_NEEDS_REAL_CHECKSUM_64_CHARS_XXXXXXXXXXXXXXXX",
+          "sha256": "f1b6f71ce8b45e4fae0139f4676bc3efb48a89c320b5b2df1a1fd349963c5f82",
           "binary_name": "wkg-x86_64-apple-darwin"
         },
         "darwin_arm64": {
-          "sha256": "PLACEHOLDER_NEEDS_REAL_CHECKSUM_64_CHARS_XXXXXXXXXXXXXXXX",
+          "sha256": "e90a1092b1d1392052f93684afbd28a18fdf5f98d7175f565e49389e913d7cea",
           "binary_name": "wkg-aarch64-apple-darwin"
         },
         "linux_amd64": {
-          "sha256": "PLACEHOLDER_NEEDS_REAL_CHECKSUM_64_CHARS_XXXXXXXXXXXXXXXX",
-          "binary_name": "wkg-x86_64-unknown-linux-musl"
+          "sha256": "e3bec9add5a739e99ee18503ace07d474ce185d3b552763785889b565cdcf9f2",
+          "binary_name": "wkg-x86_64-unknown-linux-gnu"
         },
         "linux_arm64": {
-          "sha256": "PLACEHOLDER_NEEDS_REAL_CHECKSUM_64_CHARS_XXXXXXXXXXXXXXXX",
-          "binary_name": "wkg-aarch64-unknown-linux-musl"
+          "sha256": "159ffe5d321217bf0f449f2d4bde9fe82fee2f9387b55615f3e4338eb0015e96",
+          "binary_name": "wkg-aarch64-unknown-linux-gnu"
         },
         "windows_amd64": {
-          "sha256": "PLACEHOLDER_NEEDS_REAL_CHECKSUM_64_CHARS_XXXXXXXXXXXXXXXX",
-          "binary_name": "wkg-x86_64-pc-windows-gnu.exe"
+          "sha256": "ac7b06b91ea80973432d97c4facd78e84187e4d65b42613374a78c4c584f773c",
+          "binary_name": "wkg-x86_64-pc-windows-gnu"
         }
       }
     }

checksums/tools/wkg.json

@@ -0,0 +1 @@
+Subproject commit eab0eb17f50fe663441b876dea2d123441a38a17

docs-site

@@ -1,4 +1,7 @@
 load("//cpp:defs.bzl", "cpp_component")
+load("//go:defs.bzl", "go_wasm_component")
+load("//rust:defs.bzl", "rust_wasm_component_bindgen")
+load("//wit:defs.bzl", "wit_library")
 
 # Simple C++ component to test build system
 cpp_component(
@@ -9,6 +12,46 @@ cpp_component(
     world = "auth-service-world",
 )
 
+# WIT interfaces for components
+wit_library(
+    name = "analytics_service_wit",
+    package_name = "analytics:service",
+    srcs = ["wit/analytics_service.wit"],
+    world = "analytics-service",
+)
+
+wit_library(
+    name = "user_service_wit",
+    package_name = "user:service",
+    srcs = ["wit/user_service.wit"],
+    world = "user-service",
+)
+
+# Go analytics service component
+go_wasm_component(
+    name = "analytics_service",
+    srcs = ["components/analytics_service.go"],
+    go_mod = "go.mod",
+    visibility = ["//visibility:public"],
+    wit = ":analytics_service_wit",
+    world = "analytics-service",
+)
+
+# Rust user service component
+rust_wasm_component_bindgen(
+    name = "user_service",
+    srcs = ["components/user_service.rs"],
+    visibility = ["//visibility:public"],
+    wit = ":user_service_wit",
+)
+
+# Alias for auth service to match expected name
+alias(
+    name = "auth_service",
+    actual = ":auth_service_cpp",
+    visibility = ["//visibility:public"],
+)
+
 # Test binary
 cc_test(
     name = "simple_build_test",

examples/cpp_component/multi_component_system/BUILD.bazel

@@ -0,0 +1,8 @@
+module example.com/multi-component-system
+
+go 1.24
+
+require (
+	github.com/google/uuid v1.6.0
+	golang.org/x/sync v0.10.0
+)

examples/cpp_component/multi_component_system/go.mod

@@ -7,6 +7,7 @@ Investigation into converting [olareg](https://github.com/criminaldou/olareg) to
 ## Olareg Analysis
 
 **✅ PROMISING ASPECTS:**
+
 - Simple, minimal Go codebase (~3000 lines)
 - Few external dependencies (spf13/cobra, opencontainers/go-digest)
 - Self-contained HTTP server design
@@ -43,8 +44,9 @@ For immediate testing, we're using Docker registry:2 on localhost:5001 as our te
 ## Recommendation
 
 **DEFER** full olareg WASM implementation until:
+
 - TinyGo has better WASI Preview 2 HTTP support, OR
 - Rust implementation path becomes clearer, OR
 - Host-provided HTTP adapter pattern is established
 
-The investigation was valuable for understanding the scope and complexity of registry-as-component scenarios.
+The investigation was valuable for understanding the scope and complexity of registry-as-component scenarios.