Posix rewrite

.github/workflows/test.yml

@@ -36,5 +36,8 @@ jobs:
       - name: Checkout
         uses: actions/checkout@v4
 
+      - name: Check Podman Dependency
+        run: podman --version
+
       - name: Run shim tests
         run: ./shimmy test

AGENTS.md

@@ -1,6 +1,6 @@
 ## Scope
 
-This repository packages and makes common CLI tools available to your shell as small Bash shims that call `podman run`.
+This repository packages and makes common CLI tools available to your shell as small wrappers that call `podman run`.
 
 ## Project Map
 
@@ -24,9 +24,12 @@ This repository packages and makes common CLI tools available to your shell as s
 
 - Read `CONTRIBUTING.md` before making repo changes.
 - Follow the naming conventions in `CONTRIBUTING.md` for files, functions, and variables.
-- Keep runtime shims as small Bash wrappers with `set -euo pipefail`.
+- Keep runtime shims as small POSIX shell wrappers with `#!/bin/sh` and `set -eu`.
 - Mount `$PWD` to `/work` unless the shim has a documented reason not to.
 - Use `<PREFIX>_IMAGE` for image override and `<PREFIX>_IMAGE_PULL=always` for pull policy.
+- Any Shimmy-defined variable exported into the user's shell must use the `SHIMMY_` prefix.
 - Update shim helper code, install script, tests, and README together when behavior changes.
-- When testing containers, use Podman and non-mutating cli calls (eg: version or --help) to validate execution  
+- Treat Podman as an explicit dependency. Do not add Shimmy-side installation or provisioning steps for it.
+- On macOS, remember the official Podman pkg installer may place the binary at `/opt/podman/bin/podman`. If automation cannot find `podman`, check that `/opt/podman/bin` is on `PATH`.
+- When testing containers, use live Podman and non-mutating cli calls (eg: version or --help) to validate execution  
 - Ensure runnable shell files keep executable bits.

CONTRIBUTING.md

@@ -10,12 +10,14 @@ Use it as the source of truth for repository contribution guidance that should b
 - Update related implementation, tests, installer behavior, and user-facing docs together when behavior changes.
 - Reuse established repo patterns before introducing new structure or naming.
 - Keep runnable shell files executable.
+- Treat Podman as an explicit Shimmy dependency. Do not install or provision it from Shimmy code, tests, or CI helpers.
+- Use live Podman execution for shim tests. Do not replace `podman` with fake binaries or argv-only mocks when validating shim behavior.
 
 ## Naming Conventions
 
 Use these naming conventions for files, functions, and variables unless a stronger repo-specific rule already exists.
 
-Default to common Bash best practices when choosing names. Apply the overrides in this section when they are more specific.
+Default to POSIX shell best practices when choosing names. Apply the overrides in this section when they are more specific.
 
 ### Naming Priorities
 
@@ -67,7 +69,7 @@ Examples:
 
 - `shims/aws`
 - `scripts/install-shimmy.sh`
-- `lib/repo/shimmy-env.sh`
+- `lib/repo/shimmy-startup.sh`
 - `docs/prompt-shimmy-project.md`
 
 ### Function Naming
@@ -76,35 +78,36 @@ Use function names that are explicit, source-safe, and easy to scan.
 
 - Do not use the `function` keyword.
 - Keep functions in a file sorted alphabetically unless a different order materially improves readability.
-- For library functions, use the common `shimmy::` prefix to avoid collisions with other libraries or built-in commands.
-- Internal library functions that are not intended for direct sourcing by an external user should start with a single leading underscore after the namespace.
-- Use lowercase snake_case after the namespace.
+- For shell functions, use the POSIX-safe `shimmy_` prefix to avoid collisions with other libraries or built-in commands.
+- Internal helper functions that are not intended for external use should start with `shimmy__`.
+- Use lowercase snake_case after the prefix.
 - Keep token flow general to specific.
 - Flag functions that return `0/1` or `true/false` intent should be prefixed with `is_`.
 - Name flag functions so the predicate is obvious from the call site.
 
 Patterns:
 
-- public library function: `shimmy::<resource>_<action>_<instance>`
-- internal library function: `shimmy::_<resource>_<action>_<instance>`
-- public flag function: `shimmy::is_<resource>_<state>`
-- internal flag function: `shimmy::_is_<resource>_<state>`
+- public function: `shimmy_<resource>_<action>_<instance>`
+- internal function: `shimmy__<resource>_<action>_<instance>`
+- public flag function: `shimmy_is_<resource>_<state>`
+- internal flag function: `shimmy__is_<resource>_<state>`
 
 Examples:
 
-- `shimmy::image_build_context_hash`
-- `shimmy::is_shimmy_in_path`
-- `shimmy::is_dir_in_path`
-- `shimmy::_is_token_in_manifest`
-- `shimmy::install_path_render`
-- `shimmy::_log_level_normalize`
-- `shimmy::_shim_list_read`
+- `shimmy_image_build_context_hash`
+- `shimmy_is_shimmy_in_path`
+- `shimmy_is_dir_in_path`
+- `shimmy__is_token_in_manifest`
+- `shimmy_install_path_render`
+- `shimmy__log_level_normalize`
+- `shimmy__shim_list_read`
 
 Avoid:
 
 - `function shimmy_install()`
 - `shimmyInstall`
 - `_shimmy_install`
+- `shimmy::install_path_render`
 - `install_shimmy_thing`
 
 ### Variable Naming
@@ -114,6 +117,7 @@ Choose variable names using the same general-to-specific token flow.
 - Local shell variables should use lowercase snake_case.
 - Exported environment variables and shared constants should use uppercase snake_case.
 - Global environment variables should use uppercase snake_case and start with the `SHIMMY_` prefix.
+- Any variable that Shimmy exports into the user's shell environment must use the `SHIMMY_` prefix.
 - Use resource-first ordering where possible.
 - Reuse established env var prefixes for tool shims.