Fixed
/start <stopped-container> failed with "Container not found"
Closes #24. Surfaced by @famewolf's question in #2 about how Docksentry handles stopped containers.
The partial-name resolver behind all three lifecycle commands was hardcoded to docker ps (running only), so stopped containers were invisible even on exact-name match — defeating the main use case of /start. Verified live against a real stopped container before fixing.
_resolve_container() now accepts include_stopped=False. Lifecycle commands (/start, /stop, /restart) pass True so they see docker ps -a. Everything else (/pin, /logs, /unpin, /autoupdate, /notes, etc.) keeps the running-only default so their pickers don't surface dead containers where it would be confusing.
For the original question: stopped containers are not updated by Docksentry, by design — every update path starts with docker ps, so they're invisible to update detection and stay on their previous image. This release fixes only the resolver gap for the deliberate lifecycle commands.
docker pull amayer1983/docksentry:latest
docker compose up -d