craftainer-crud-sdk 0.1.0__tar.gz

craftainer_crud_sdk-0.1.0/.claude/README.md

@@ -0,0 +1,82 @@
+# .claude/
+
+Project-scope Claude Code configuration, shared with every collaborator
+who opens this repo (see the root `.gitignore`, which does *not* exclude
+this directory).
+
+- `settings.json` — enables official plugins from the built-in
+  `claude-plugins-official` marketplace via `enabledPlugins`:
+  - `context7` — pulls up-to-date, version-specific library
+    documentation and examples into context from Context7's hosted
+    remote MCP server (`https://mcp.context7.com/mcp`); no local
+    install. Works anonymously; set a `CONTEXT7_API_KEY` env var for
+    higher rate limits.
+  - `security-guidance` — security review for Claude-generated code:
+    pattern-based warnings on `Edit`/`Write`, an LLM diff review when
+    Claude finishes a turn, and an agentic reviewer on `git commit`
+    that traces cross-file data flow. Needs only Python 3.8+ on
+    `PATH` — an instance without a Python runtime of its own should
+    confirm this is still true before relying on it.
+
+  `settings.json` also wires up the `PostToolUse` hook below.
+- `hooks/self-check.sh` — after Claude edits a file, runs the fast,
+  pre-commit-stage hooks from `../.pre-commit-config.yaml` (whitespace,
+  YAML/TOML/JSON checks, ...) against just that file via `prek`, so
+  issues are caught and auto-fixed immediately instead of first at commit
+  time. An instance's own slower, pre-push-only hooks stay pre-push-only —
+  too slow to run after every edit.
+- `agents/plan-executor.md` — the subagent that executes one work item
+  of a `docs/plans/` plan on a faster model (`model: sonnet`), under
+  the main session as orchestrator (see `../CLAUDE.md`, "Execute
+  multi-item work as an orchestrator"). It holds the executor's side of
+  the protocol: what a brief contains, the write-set and no-push rules,
+  the escalation triggers, and the report format.
+- The `PreToolUse` hook on `Bash` runs `snip hook`, the
+  [snip](https://github.com/edouard-claude/snip) token-filtering proxy:
+  it rewrites supported commands (`git` and others; an instance's own
+  language tooling once it's added) to return only their signal
+  (failures, diffs, summaries) instead of full output. `snip` itself is
+  installed by `scripts/develop.sh`, pinned to `SNIP_VERSION` in
+  `../.devcontainer/Dockerfile`, and checksum-verified against its published release
+  checksums — see "Versions and config" in `docs/TEMPLATE.md`. Chosen
+  over the more popular
+  [rtk](https://github.com/rtk-ai/rtk) because its filters are
+  declarative YAML data (auditable) and it fails open (a broken filter
+  passes the command through unfiltered rather than blocking it); rtk's
+  larger community and multi-maintainer team are the tradeoff, so revisit
+  this choice if `snip` goes unmaintained.
+- `../.mcp.json` — project-scope MCP servers not available as a
+  `claude-plugins-official` plugin, so they can't go through
+  `enabledPlugins` above:
+  - `clear-thought` (`@waldzellai/clear-thought-onepointfive`) — a
+    local stdio MCP server exposing structured reasoning/mental-model
+    tools, launched via `npx`. `npx` needs Node.js, which is the only
+    reason `scripts/develop.sh` installs it (pinned via
+    `../.devcontainer/Dockerfile`'s `NODE_VERSION` ARG) — Claude Code itself doesn't need it.
+
+  An instance adds its own stack-specific MCP servers here (database,
+  object storage, browser automation, ...), pinned to an exact
+  version/commit the same way, and reading credentials via `${VAR}` from
+  the same env vars its own `../.devcontainer/compose.yml` gives its dev
+  service — never re-pinned a second time.
+
+## Do
+
+- Keep this file's `enabledPlugins` pinned to specific plugin names —
+  don't rely on a whole marketplace being auto-installed.
+
+## Don't
+
+- Add personal preferences here — this file is committed and shared;
+  use your own user-scope Claude Code settings for those instead.
+
+## Removing a tool
+
+- **snip**: delete the `PreToolUse` hook entry in `settings.json` and the
+  `snip` install block (and `SNIP_VERSION` ARG in `../.devcontainer/Dockerfile`) from
+  `scripts/develop.sh`.
+- **context7** / **security-guidance**: delete the plugin's
+  `enabledPlugins` entry in `settings.json`.
+- **clear-thought**: delete its entry from `../.mcp.json`; if nothing
+  else needs Node.js, also remove its install block (and `NODE_VERSION`
+  ARG) from `../.devcontainer/Dockerfile`/`scripts/develop.sh`.

craftainer_crud_sdk-0.1.0/.claude/agents/plan-executor.md

@@ -0,0 +1,72 @@
+---
+name: plan-executor
+description: Executes exactly one work item of a docs/plans/ plan, briefed by the orchestrating main session. Works only inside its brief's write set, in its own worktree, and hands back to the orchestrator instead of improvising when it hits an escalation trigger. Use one per independent work item; run independent items in parallel.
+model: sonnet
+---
+
+You execute one work item from a plan under `docs/plans/`. The
+orchestrator (the main session) wrote your brief. It owns every decision
+outside that brief and talks to the user. Your job is to finish your
+item and report it accurately.
+
+## Your brief contains
+
+1. **Goal:** the work item, quoted from the plan, plus any Decision log
+   entries that apply. Decision log entries are settled. Don't reopen
+   them.
+2. **Write set:** the only files and directories you may create, change
+   or delete. Everything else is read-only to you.
+3. **Interfaces:** names and signatures you must provide, or may rely on
+   from items running in parallel. Code against them exactly as stated,
+   even if the other side doesn't exist yet in your worktree.
+4. **Done when:** the checks that must pass before you report `done`.
+
+## Rules
+
+- Before writing anything, read `CLAUDE.md`, then every `README.md` on
+  the path to each file in your write set, root first (`CLAUDE.md`,
+  "Before writing anything").
+- Before relying on a third-party library's API, look it up with
+  context7. Don't code from memory.
+- Commit only to your own `wip/<id>` branch in your worktree. Never
+  push, open a PR, create a repo, tag, publish, or delete a branch.
+- Don't run integration tests, e2e tests or load tests unless your
+  brief says to. They share the devcontainer's services, and the
+  orchestrator runs them one at a time in its own lanes. Run lint,
+  type-check and unit tests for your write set yourself.
+- Show real check output. "Looks done" is not verification.
+
+## Escalate: stop and hand back
+
+Stop working and report `STATUS: escalate` as soon as any of these
+happens. Don't work around it:
+
+1. A required check still fails after two distinct fix attempts.
+2. The fix needs a file outside your write set, or an interface that
+   differs from your brief.
+3. Your brief contradicts the code, a `README.md`, an ADR or an NFR, or
+   is ambiguous enough that you'd be guessing.
+4. A library or framework behaves differently from what your brief
+   assumes.
+5. The only way to pass a check is a suppression comment, a lower
+   coverage threshold, or a weakened guardrail.
+6. Anything under `.devcontainer/` would need to change. That needs a
+   rebuild only the user can trigger.
+7. Any outward-facing or hard-to-reverse action would be needed.
+8. A measurement contradicts the expected effect, or the run-to-run
+   spread is larger than the effect.
+
+The orchestrator researches the problem, decides, and resumes you with
+a message. Keep your worktree as it is when you escalate.
+
+## Report: your final message, exactly this shape
+
+```
+STATUS: done | escalate
+SUMMARY: <2-5 lines>
+CHANGED: <files>
+CHECKS: <command -> verbatim output tail, one per check>
+COMMIT: <one-line message, then short bullets>
+ESCALATION: <only when escalating: trigger number, what you tried,
+            evidence (verbatim output), options, your recommendation>
+```

craftainer_crud_sdk-0.1.0/.claude/hooks/self-check.sh

@@ -0,0 +1,35 @@
+#!/usr/bin/env bash
+# PostToolUse hook (Edit|Write): after Claude edits a file, run the fast,
+# pre-commit-stage hooks from .pre-commit-config.yaml against just that
+# file via prek -- reusing the same config as `git commit` would, instead
+# of a second, separate set of checks -- so whitespace/lint issues are
+# caught (and auto-fixed where possible) immediately, not first at commit
+# time. An instance's own slower, pre-push-only hooks (type checker, test
+# suite, lock-file check, ...) are deliberately excluded here: too slow to
+# run after every single edit.
+set -euo pipefail
+
+input="$(cat)"
+file_path="$(jq -r '.tool_input.file_path // empty' <<<"$input")"
+
+[ -n "$file_path" ] || exit 0
+[ -f "$file_path" ] || exit 0
+
+project_dir="${CLAUDE_PROJECT_DIR:-$PWD}"
+case "$file_path" in
+  "$project_dir"/*) ;;
+  *) exit 0 ;;
+esac
+
+command -v prek >/dev/null 2>&1 || exit 0
+
+cd "$project_dir"
+relative_path="${file_path#"$project_dir"/}"
+
+if ! output="$(prek run --files "$relative_path" 2>&1)"; then
+  echo "$output" >&2
+  echo "prek found issues in $relative_path (fixed automatically where possible) -- review the diff." >&2
+  exit 2
+fi
+
+exit 0

craftainer_crud_sdk-0.1.0/.claude/settings.json

@@ -0,0 +1,36 @@
+{
+  "attribution": {
+    "commit": "",
+    "pr": ""
+  },
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Edit|Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/self-check.sh",
+            "timeout": 60
+          }
+        ]
+      }
+    ],
+    "PreToolUse": [
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "snip hook",
+            "timeout": 10
+          }
+        ]
+      }
+    ]
+  },
+  "enabledPlugins": {
+    "context7@claude-plugins-official": true,
+    "security-guidance@claude-plugins-official": true
+  }
+}

craftainer_crud_sdk-0.1.0/.claude/skills/owasp-scan/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: owasp-scan
+description: Scan every file under src/ for OWASP Top Ten (2025) issues, in parallel, and report findings.
+---
+
+# OWASP Top Ten scan
+
+Check all files under `src/` against the OWASP Top Ten (2025) categories
+and report what's found. Read-only — do not fix anything unless the user
+asks afterward.
+
+## Steps
+
+1. **List target files.** `find src/ -type f -name "*.py"` (adjust the
+   extension filter if the tree isn't Python). Exclude generated/vendor
+   code if any exists under `src/`.
+
+2. **Batch them.** Group files by their top-level subdirectory under
+   `src/app/` (`controllers`, `crud`, `models`, `repositories`, `views`,
+   `health`, etc.), splitting further so no batch exceeds ~8 files. Each
+   batch becomes one subagent task.
+
+3. **Scan in parallel.** In a single message, launch one `Explore` agent
+   per batch (`run_in_background: false` is not needed — let them run in
+   parallel and collect results as they land). Give each agent:
+   - The exact file list for its batch (full paths).
+   - The checklist below.
+   - Instruction to report only findings it can point at a concrete
+     file:line and a concrete failure scenario (input/state that
+     triggers it) — no generic advice, no "consider adding X" without a
+     specific gap it fills.
+   - Instruction to reply in under 300 words per file with findings, or
+     say "no findings" for a file with none.
+
+4. **Aggregate.** Merge all agents' findings into one list, drop
+   duplicates, sort most-severe first (Injection/Broken Access
+   Control/Auth failures above Security Misconfiguration above
+   Logging/Monitoring gaps).
+
+5. **Report to the user** as a single markdown list grouped by OWASP
+   category, each item: `path:line — one-sentence defect — concrete
+   failure scenario`. Skip categories with no findings; don't pad the
+   report with reassurance about what's fine.
+
+## OWASP Top Ten (2025) checklist for each agent
+
+- **A01 Broken Access Control** — missing/incorrect authz checks,
+  IDOR (object access by ID without ownership check), path traversal,
+  CORS misconfig, and SSRF (outbound requests built from
+  user-controlled URLs/hosts without allowlisting — folded into this
+  category for 2025).
+- **A02 Security Misconfiguration** — debug mode/verbose errors enabled
+  in non-dev paths, permissive defaults, unnecessary exposed
+  endpoints/features.
+- **A03 Software Supply Chain Failures** — dependency/version pinned
+  elsewhere with a known vulnerability you can name, unpinned/floating
+  versions for security-sensitive packages, unverified third-party
+  build steps or CI actions.
+- **A04 Cryptographic Failures** — plaintext secrets/passwords, weak or
+  homemade crypto/hashing, hardcoded keys, missing TLS enforcement.
+- **A05 Injection** — SQL/NoSQL/OS command/LDAP injection via
+  unsanitized input, unsafe `eval`/template rendering, missing
+  parameterization.
+- **A06 Insecure Design** — missing rate limiting or business-logic
+  guards where abuse is plausible (only flag with a concrete abuse
+  path, not speculative).
+- **A07 Authentication Failures** — weak session/token handling,
+  missing expiry/invalidation, predictable tokens, password rules
+  absent where passwords are set.
+- **A08 Software or Data Integrity Failures** — unsafe deserialization
+  (pickle, yaml.load without safe loader), unsigned/unverified updates
+  or artifacts.
+- **A09 Security Logging & Alerting Failures** — security-relevant
+  events (auth failures, access-control denials) not logged, sensitive
+  data (passwords, tokens) logged in plaintext, or no alerting hook for
+  events that should page someone.
+- **A10 Mishandling of Exceptional Conditions** — broad/bare exception
+  handlers that swallow security-relevant errors, error paths that
+  fail open (e.g. an auth check that defaults to "allow" if the
+  check itself throws), inconsistent error handling that leaks
+  internals in one path and hides failures in another.
+
+## Notes
+
+- This is a read pass, not `/security-review` or `/code-review` — don't
+  invoke those; this skill is narrower (OWASP-only, src/ only) and
+  faster because it fans out.
+- If the user wants fixes applied afterward, treat that as a separate,
+  explicit follow-up — don't edit files as part of the scan itself.

craftainer_crud_sdk-0.1.0/.devcontainer/Dockerfile

@@ -0,0 +1,79 @@
+# syntax=docker/dockerfile:1.28
+# Single-stage build: develop (the devcontainer image). Built with the repo
+# root as context (see compose.yml). The repo-root Dockerfile is reserved for
+# an instance's own runtime image -- see docs/TEMPLATE.md's "Contents" and
+# "Instance extension points".
+
+ARG DEBIAN_VERSION=trixie
+
+# renovate: datasource=github-releases depName=j178/prek
+ARG PREK_VERSION=0.5.5
+
+# renovate: datasource=npm depName=@anthropic-ai/claude-code
+ARG CLAUDE_CODE_VERSION=2.1.296
+
+# renovate: datasource=github-releases depName=edouard-claude/snip
+ARG SNIP_VERSION=0.25.2
+
+# renovate: datasource=github-releases depName=cli/cli
+ARG GH_VERSION=2.102.0
+
+# uv itself isn't a project dependency manager here -- it's only the
+# mechanism scripts/develop.sh uses to install an exact, checksum-verified
+# CPython build (see PYTHON_VERSION below) rather than an unpinned apt
+# package. Left on PATH afterward; harmless, and an instance that adds
+# Python as its own application runtime can reuse it directly.
+# renovate: datasource=github-releases depName=astral-sh/uv
+ARG UV_VERSION=0.13.0
+
+# python3 is infrastructure tooling, not an application runtime this
+# template assumes: prek needs an interpreter to build the venv for any
+# "language: python" hook (.pre-commit-config.yaml's pre-commit-hooks
+# repo), and .github/scripts/*.py need one directly.
+# renovate: datasource=python-version depName=python
+ARG PYTHON_VERSION=3.14.8
+
+# Node.js is infrastructure tooling too, not an application runtime: npx
+# (the clear-thought MCP server in .mcp.json) is the only thing that
+# needs it.
+# renovate: datasource=node-version depName=node
+ARG NODE_VERSION=24.21.0
+
+ARG SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
+ARG SSL_CERT_DIR=/etc/ssl/certs
+
+########################################
+# develop — interactive devcontainer image, based on Microsoft's generic
+# base devcontainer image. No *application* language runtime is assumed
+# here — an instance adds its own (Python via uv, Rust via rustup, Go,
+# Node.js, OpenTofu/Ansible, ...) on top of this stage, following the same
+# ARG/scripts/develop.sh pattern established below. The Python and Node.js
+# this stage does install are infrastructure tooling only -- see the ARG
+# comments above.
+########################################
+FROM mcr.microsoft.com/devcontainers/base:${DEBIAN_VERSION} AS develop
+ARG PREK_VERSION
+ARG CLAUDE_CODE_VERSION
+ARG SNIP_VERSION
+ARG UV_VERSION
+ARG PYTHON_VERSION
+ARG NODE_VERSION
+ARG GH_VERSION
+ARG SSL_CERT_FILE
+ARG SSL_CERT_DIR
+
+ENV SSL_CERT_FILE=${SSL_CERT_FILE} \
+    SSL_CERT_DIR=${SSL_CERT_DIR} \
+    REQUESTS_CA_BUNDLE=${SSL_CERT_FILE} \
+    CURL_CA_BUNDLE=${SSL_CERT_FILE}
+
+COPY scripts/develop.sh /tmp/develop.sh
+RUN bash /tmp/develop.sh "$PREK_VERSION" "$CLAUDE_CODE_VERSION" "$SNIP_VERSION" "$UV_VERSION" "$PYTHON_VERSION" "$NODE_VERSION" "$GH_VERSION"
+
+# Instance hook: scripts/develop.d/*.sh, see that directory's README.md.
+COPY scripts/develop.d/ /tmp/develop.d/
+RUN for f in /tmp/develop.d/*.sh; do [ -e "$f" ] || continue; echo "==> $f"; bash "$f" || exit 1; done
+
+USER vscode
+WORKDIR /workspace
+CMD ["sleep", "infinity"]

craftainer_crud_sdk-0.1.0/.devcontainer/Dockerfile.dockerignore

@@ -0,0 +1,11 @@
+# Build context excludes for the devcontainer image (.devcontainer/Dockerfile).
+# BuildKit reads <Dockerfile>.dockerignore next to the Dockerfile in place of
+# the context root's .dockerignore, which stays free for an instance's own
+# runtime image.
+.git
+.github
+.devcontainer
+.secrets
+docs
+README.md
+CLAUDE.md

craftainer_crud_sdk-0.1.0/.devcontainer/README.md

@@ -0,0 +1,164 @@
+# .devcontainer/
+
+- `devcontainer.json` — references `compose.yml` and `compose.instance.yml`
+  as the devcontainer's `dockerComposeFile`, and configures the devcontainer itself
+  (features, mounts, editor settings).
+- `Dockerfile` — the devcontainer image (a single `develop` stage), built
+  with the repo root as context; `Dockerfile.dockerignore` holds its
+  build-context excludes. The top-level `Dockerfile` is reserved for an
+  instance's runtime image (`../docs/TEMPLATE.md`).
+- `compose.yml` — the dev service (`myapp`), built from `Dockerfile`'s
+  `develop` stage. An instance that needs backing services
+  (a database, a queue, ...) adds its own `stack/` directory (one
+  subdirectory per service, each with its own compose fragment) and an
+  `include:` list in `compose.instance.yml` pointing at them — see `stack/README.md`'s
+  "Devcontainer stack pattern" convention once an instance adds one.
+- `compose.instance.yml` — instance-owned stub (`ignore` tier, never
+  touched by sync): an instance's `include:` list and extra `services.myapp`
+  settings. See `docs/TEMPLATE.md`'s "Instance extension points".
+
+## Docker-in-Docker vs. the host's Docker
+
+This devcontainer has its own isolated Docker-in-Docker daemon (the
+`docker-in-docker` feature in `devcontainer.json`). It is **not** the
+same daemon running any backing-service stack an instance adds — that
+stack is started by whatever invoked "Reopen in Container" against the
+*host's* Docker. So `docker`/`docker compose` run from inside the
+devcontainer can build and run throwaway containers of their own, but can
+never see or `exec` into a sibling container an instance's `stack/`
+starts — only a `docker compose` invoked on the host can.
+
+## SSH agent forwarding
+
+`devcontainer.json`'s `mounts` bind-mounts two possible SSH agent
+sockets, and `postStartCommand` runs `resolve-ssh-agent.sh` on every
+container start to symlink whichever one actually works to
+`/home/vscode/.ssh-agent-resolved.sock` — the path `remoteEnv` points
+`SSH_AUTH_SOCK` at. Either way, `git push` over SSH inside the container
+authenticates against the same agent and keys already loaded on the
+host — no key material is ever copied into the container.
+
+The two candidates:
+
+- `/ssh-agent` — the host's own `SSH_AUTH_SOCK` (`${localEnv:SSH_AUTH_SOCK}`),
+  bind-mounted directly. This is a real Linux socket on WSL2, so normal
+  Unix permissions carry through and it works as-is (see "Windows" below
+  for getting an agent running there in the first place). If
+  `SSH_AUTH_SOCK` is unset when the container is created (true for
+  `devcontainers/ci` in `.github/workflows/checks.yml` — GitHub Actions
+  runners have no agent), `@devcontainers/cli` drops the empty source and
+  this mount degrades to a plain anonymous volume instead of erroring —
+  harmless there since CI never pushes.
+- `/ssh-agent-macos` — Docker Desktop's own agent-forwarding proxy, always
+  available at the fixed path `/run/host-services/ssh-auth.sock` inside
+  its VM on both macOS and Windows. macOS has no real `SSH_AUTH_SOCK`
+  equivalent to WSL2's — the closest thing is this VM-internal proxy.
+
+Both sockets arrive owned `root:root` mode `660` regardless of platform
+or who owns the socket on the host side — bind-mounting a socket special
+file carries over the owning uid/gid as seen inside the Docker Desktop
+VM (root), not the host user's — so `remoteUser` (`vscode`) can't connect
+to either without help. `resolve-ssh-agent.sh` runs `sudo chmod 666` on
+each candidate before testing it (harmless: these are forwarding sockets
+meant to be reachable by whatever connects to them, and chmod on a bind
+mount only touches this one inode, not host files) — this needs the
+passwordless `sudo` already granted to `vscode`.
+
+Both also require an agent to actually be running on the host — on
+macOS, `ssh-add -l` in a host Terminal should list a key; if it doesn't,
+`ssh-add --apple-use-keychain ~/.ssh/id_ed25519` first — and a full
+"Rebuild Container" after `mounts` changes (mounts don't apply to an
+already-running container). `resolve-ssh-agent.sh` re-checks both
+sockets on every start (not just container creation) since which one is
+live can change if the host agent restarts between sessions.
+
+### Windows
+
+Launching VS Code the normal way (Start Menu, a desktop shortcut, or
+"Open Folder") starts it with no `SSH_AUTH_SOCK` at all — Windows has
+no such environment variable, even with an agent (Git Bash's own, or
+the Windows OpenSSH Authentication Agent service) already holding your
+keys — so this always hits the degraded-mount path above, silently, and
+`git push`/`pull` inside the container has no key material to
+authenticate with no matter what's in your Windows `~/.ssh`.
+
+With Docker Desktop's WSL2 backend (not the Hyper-V backend — that one
+has no comparable path), fix this by running the agent inside a WSL2
+distro instead, since that's the same Linux environment Docker Desktop
+runs containers in and shares socket/filesystem access with:
+
+1. Make sure a real, user-facing WSL2 distro (e.g. Ubuntu — not just
+   the internal `docker-desktop` one) is installed and enabled under
+   Docker Desktop's Settings → Resources → WSL Integration.
+2. Inside that distro, copy your keys in from Windows and start an
+   agent:
+   ```sh
+   mkdir -p ~/.ssh && cp /mnt/c/Users/<you>/.ssh/id_ed25519* ~/.ssh/
+   chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_ed25519
+   eval "$(ssh-agent -s)"
+   ssh-add ~/.ssh/id_ed25519
+   ```
+   Put the `eval`/`ssh-add` lines in `~/.bashrc` (guard with
+   `ssh-add -l >/dev/null 2>&1 ||` so it doesn't spawn a new agent every
+   shell) so this survives new terminals without repeating it by hand.
+3. From that same WSL shell, run `code .` — this opens VS Code via the
+   Remote-WSL extension first, with `SSH_AUTH_SOCK` inherited from the
+   shell that launched it.
+4. From inside that window, run "Dev Containers: Reopen in Container".
+   `${localEnv:SSH_AUTH_SOCK}` now resolves to the WSL2 agent socket
+   instead of nothing, so the bind-mount above actually carries an
+   agent through.
+
+Git Bash's own ssh-agent doesn't help here even though it holds the
+same keys: its socket is an MSYS emulation, not a real Unix socket
+Docker Desktop can bind-mount into a Linux container, and `code .` run
+from a Git Bash prompt doesn't change what environment the VS Code GUI
+process itself starts with anyway.
+
+## After a rebuild
+
+"Dev Containers: Rebuild Container" reruns `postCreateCommand` from
+scratch (dependency installs, `prek install`, ...) — no manual setup
+step there. Still worth doing once the container is back:
+
+- Run `prek run --all-files --hook-stage manual` — the same check-suite
+  that gates CI (`checks.yml`) — to confirm whatever motivated the
+  rebuild (a `.devcontainer/Dockerfile`/`scripts/develop.sh` change, a new tool) works
+  end-to-end inside the container, not just that the image built.
+- If the change added, removed, or reordered a `mounts` entry, confirm
+  it actually took effect — mounts apply only at container creation, not
+  on every start (see "SSH agent forwarding" above for the concrete
+  case: a mount change needs a full rebuild, not just a restart).
+- If `forwardPorts`/`portsAttributes` changed, check the Ports panel
+  picked up the new list.
+
+A plain "Reopen in Container" (no rebuild) is enough for changes outside
+`.devcontainer/` and `scripts/develop.sh` — those only
+need the window reconnected, not a fresh image.
+
+## Do
+
+- Add a new compose fragment's path to `compose.instance.yml`'s `include:`
+  list the same time you add the fragment — an unreferenced file starts
+  nothing.
+- Keep service credentials and connection settings in the compose files'
+  `environment:` blocks, so opening the devcontainer is the only setup
+  step.
+- Commit `devcontainer-lock.json` in the same change as any feature
+  edit in `devcontainer.json`. Regenerate it with
+  `npx @devcontainers/cli upgrade --workspace-folder .`, or by
+  rebuilding the devcontainer. Feature versions are bumped by hand,
+  not by Renovate: Renovate can't regenerate this file, so
+  `../.github/renovate.json` turns its devcontainer feature updates
+  off rather than let them merge with a stale lockfile.
+
+## Don't
+
+- Bind- or volume-mount a language runtime's dependency tree, or anything
+  else you don't want a host antivirus/DLP tool scanning or syncing — it
+  lives purely in the container's writable layer instead. (`claude-config`
+  and `gh-config` are deliberate, narrow exceptions — small login and
+  session state; see `compose.yml`'s comments on those volumes.)
+- Add a `ports:` mapping or a `networks:` block anywhere here.
+- Pin a feature or image version as `latest` — pin the exact version so
+  Renovate can bump it deliberately.

craftainer_crud_sdk-0.1.0/.devcontainer/compose.instance.yml

@@ -0,0 +1,5 @@
+# Instance-owned, never touched by template sync: an instance puts its
+# `include:` stack fragments and any extra `services.myapp` settings
+# (`env_file`, `environment`, `depends_on`) here, so `compose.yml` stays
+# template-owned.
+services: {}

craftainer_crud_sdk-0.1.0/.devcontainer/compose.yml

@@ -0,0 +1,42 @@
+# Dev service: the devcontainer itself, built from .devcontainer/Dockerfile's
+# `develop` stage, with the repo root as build context. The workspace is bind-mounted so source
+# edits are picked up without a rebuild. An instance that adds backing
+# services (a database, a queue, ...) adds its own `include:` list to
+# compose.instance.yml instead, pointing at its own `stack/*/compose.yml`
+# fragments -- see
+# .devcontainer/README.md's "Docker-in-Docker vs. the host's Docker".
+services:
+  # Not `app`: Chrome HSTS-preloads the whole `.app` TLD, which also
+  # matches the bare hostname `app`, so a browser container (e.g. an
+  # instance's Selenium) would force http://app:<port> to HTTPS.
+  myapp:
+    build:
+      context: ..
+      dockerfile: .devcontainer/Dockerfile
+      target: develop
+    volumes:
+      - ..:/workspace:cached
+      # No volume for a language-runtime environment (venv, node_modules,
+      # target/, ...): a mounted one gets swept by Windows DLP/malware-
+      # scanning tools just like a bind-mounted one, so it lives purely in
+      # the container's writable layer instead -- see each language's own
+      # README for its specific env var/path convention once an instance
+      # adds one.
+      - claude-config:/home/vscode/.claude
+      - gh-config:/home/vscode/.config/gh
+    command: sleep infinity
+    # No ports: mapping and no networks: block — see .devcontainer/
+    # README.md's "Don't". An instance that needs host access adds
+    # forwardPorts to devcontainer.json; one with backing services
+    # reaches them by name on the default network compose generates for
+    # this project.
+
+volumes:
+  # Persists Claude Code CLI session/credential state across container
+  # rebuilds. A small amount of session-state data, not a language
+  # runtime's dependency tree, so the DLP/malware-scanning concern above
+  # doesn't apply the same way here.
+  claude-config:
+  # Persists the GitHub CLI's login (`gh auth login`) across rebuilds, for
+  # the same reason.
+  gh-config:

craftainer_crud_sdk-0.1.0/.devcontainer/devcontainer-lock.json

@@ -0,0 +1,9 @@
+{
+  "features": {
+    "ghcr.io/devcontainers/features/docker-in-docker:4.1.3": {
+      "version": "4.1.3",
+      "resolved": "ghcr.io/devcontainers/features/docker-in-docker@sha256:fae40f3c8be5a7c3b0db344c1d30341bc2c91ba38d1d5b14cd2ad72e6d65d084",
+      "integrity": "sha256:fae40f3c8be5a7c3b0db344c1d30341bc2c91ba38d1d5b14cd2ad72e6d65d084"
+    }
+  }
+}