v1.4.1 (#50)

* docs+infra(dev-container): recommend dev container path; make Dockerfile.dev multi-arch

The dev container is the supported install path because GCO pins many
exact Python package versions and host installs frequently fail with
dependency-resolver errors. Update the docs to reflect that, and fix
two things that were undermining the recommendation.
Documentation
- README, QUICKSTART, CONTRIBUTING now lead with `docker build -f
  Dockerfile.dev` and demote pip/pipx to a collapsed "advanced" path
  with explicit guidance on the resolver-conflict failure mode.
- New "Installation Issues" section in docs/TROUBLESHOOTING.md walks
  through `ResolutionImpossible` errors and points at the dev container
  as the canonical fix.
- mcp/README.md and QUICKSTART.md now use absolute-path-in-args for
  the MCP config so the same snippet works in Cursor, Kiro, Claude
  Desktop, etc. without relying on client-specific `cwd` handling.
Dockerfile.dev — multi-arch
- Add ARG TARGETARCH and derive a GNU arch tag (x86_64 / aarch64) for
  the AWS CLI v2 and Docker static-client tarballs; pass TARGETARCH
  straight through for the kubectl URL.
- Builds natively on linux/amd64 (CI on x86_64 GitHub runners, Intel
  Macs, Linux x86_64 hosts) and linux/arm64 (Apple Silicon, Graviton,
  arm64 Linux). Native arm64 build on Apple Silicon drops from ~7-8
  min (qemu emulation under Finch/Colima) to ~2 min — matching the
  build-time claim in the docs.
- All baked-in deps verified to install from wheels on arm64 (no sdist
  fallback for any pinned package).
CI — integration:docker:dev-container
- New "Verify amd64 image actually contains amd64 binaries" step:
  asserts uname -m and AWS CLI v2 banner agree on x86_64.
- New QEMU + buildx setup followed by linux/arm64 cross-build, then
  triple-layer arch verification: uname -m == aarch64, AWS CLI banner
  contains aarch64, gco --version loads, and an inline Python ELF
  e_machine inspection of kubectl + the Docker static client to catch
  single-binary regressions that would slip past a run-time check
  under QEMU translation.
- Bumped job timeout 25→40 min to absorb the cross-build (~10× slower
  under qemu).

* updates

* Update integration-tests.yml

* docs(gco-dev): harden repo detection with gco/ directory check

The gco-dev shell helper previously accepted any directory whose
git toplevel contained a Dockerfile.dev. Add a second check for a
top-level gco/ directory so the function only activates inside the
GCO repo (or a clone pointed to via $GCO_HOME), rather than silently
bind-mounting an unrelated tree at /workspace.

Updated in lockstep:
  - QUICKSTART.md
  - CONTRIBUTING.md

Author: Jmevorach

CONTRIBUTING.md

@@ -111,10 +111,26 @@ host-socket pass-through, not true Docker-in-Docker — do not add
 root-equivalent access to the host Docker daemon through the mounted
 socket, so only use this on trusted hosts.
 
-**Tip**: Create a shell alias for convenience:
+**Tip**: Create a shell function for convenience. Using a function (rather than an alias that hardcodes `$(pwd)`) means it auto-resolves your GCO clone via `git rev-parse`, so `gco stacks *` and other source-tree-dependent commands work regardless of which subdirectory you call it from. Set `GCO_HOME` in your shell to use it from anywhere on disk:
 
 ```bash
-alias gco-dev='docker run --rm -v ~/.aws:/root/.aws:ro -v $(pwd):/workspace -w /workspace gco-dev'
+gco-dev() {
+    local project_root="${GCO_HOME:-$(git rev-parse --show-toplevel 2>/dev/null)}"
+    # Check for both Dockerfile.dev *and* the gco/ namespace package
+    # so we don't accidentally bind-mount an unrelated repo that
+    # happens to have a Dockerfile.dev at its root.
+    if [[ -z "$project_root" \
+        || ! -f "$project_root/Dockerfile.dev" \
+        || ! -d "$project_root/gco" ]]; then
+        echo "gco-dev: not inside the GCO repo. cd into your clone, or set GCO_HOME." >&2
+        return 1
+    fi
+    docker run --rm \
+        -v ~/.aws:/root/.aws:ro \
+        -v "$project_root:/workspace" \
+        -w /workspace \
+        gco-dev "$@"
+}
 # Then use: gco-dev gco stacks list
 ```
 

QUICKSTART.md

@@ -81,10 +81,27 @@ docker run -it --rm \
 gco --version
 ```
 
-> **Tip:** save yourself some typing with an alias on the host:
+> **Tip:** save yourself some typing with a shell function on the host. We use a function (rather than a plain alias mounting `$(pwd)`) so that the GCO clone is always mounted at `/workspace` no matter where you call it from — `gco stacks *` and other commands that need `cdk.json` / `app.py` / `gco/` at the workspace root will keep working from any subdirectory of the repo, and from anywhere on disk if you `export GCO_HOME=/path/to/your/clone`:
 >
 > ```bash
-> alias gco-dev='docker run --rm -v ~/.aws:/root/.aws:ro -v $(pwd):/workspace -v /var/run/docker.sock:/var/run/docker.sock -w /workspace gco-dev'
+> gco-dev() {
+>     local project_root="${GCO_HOME:-$(git rev-parse --show-toplevel 2>/dev/null)}"
+>     # Check for both Dockerfile.dev *and* the gco/ namespace package
+>     # so we don't accidentally bind-mount an unrelated repo that
+>     # happens to have a Dockerfile.dev at its root.
+>     if [[ -z "$project_root" \
+>         || ! -f "$project_root/Dockerfile.dev" \
+>         || ! -d "$project_root/gco" ]]; then
+>         echo "gco-dev: not inside the GCO repo. cd into your clone, or set GCO_HOME." >&2
+>         return 1
+>     fi
+>     docker run --rm \
+>         -v ~/.aws:/root/.aws:ro \
+>         -v "$project_root:/workspace" \
+>         -v /var/run/docker.sock:/var/run/docker.sock \
+>         -w /workspace \
+>         gco-dev "$@"
+> }
 > # Then run any command directly: gco-dev gco stacks list
 > ```
 >