feat: chat A2A inner loop, council routing, compaction authority (3/3)

.dockerignore

@@ -1,7 +1,13 @@
+# NOTE: keep _path_in_target_image() in scripts/stack_control.sh in sync
+# with these patterns. The script mirrors them in a global exclusion block
+# so `verify` doesn't hash files that don't actually ship in any image.
 frontend/node_modules
 workspace/
 .env
 .venv
 *.db
 *.json
-*.xml
+*.xml
+# Allow build manifests to be COPY'd into images (written by stack_control.sh
+# before each build; per-target name avoids races during parallel builds).
+!build-manifest-*.json

.env.example

@@ -48,6 +48,10 @@ VITE_API_URL=http://localhost:8000
 # API type values (in params.api_type): vertex_ai | azure | bedrock | null
 
 # ─── Sandbox (optional — needed for code execution) ──────────────
+# Provider: e2b (cloud) | docker (local containers) | local (bare metal)
+# For Docker sandbox or A2A inner loop, use the Docker stack instead:
+#   cp docker/.stack.env.local.example docker/.stack.env.local
+#   ./scripts/stack_control.sh start
 # SANDBOX_PROVIDER=e2b
 # SANDBOX_E2B_API_KEY=
 

.github/copilot-instructions.md

@@ -0,0 +1,45 @@
+# Do not use base docker compose commands to do any kind of stack operations.
+# Instructions on restarting and rebuilding the stack:
+# Use the following tool preferentially :
+scripts/stack_control.sh
+
+# Use the following tool to determine which containers (if any) require a rebuild and why:
+/scripts/stack_control.sh verify
+
+# Other scripts are also available to you under:
+scripts/local/*
+
+# Credentials are available in
+docker/.stack.env.local
+
+# Python venv is located in
+~/workspaces/venvs/ii-agent
+
+# When creating new design docs, place then in docs/design-docs rather than creating them within agentic memory storage.
+
+# When creating new test docs, place then in docs/test-docs rather than creating them within agentic memory storage.
+
+# When creating new implementation docs, place then in docs/impl-docs rather than creating them within agentic memory storage.
+
+# Logging — loguru vs stdlib (READ THIS BEFORE WRITING OR REVIEWING ANY logger.* CALL)
+#
+# `ii_agent.core.logger` and `loguru.logger` use BRACE-STYLE formatting `{}`.
+# `ii_agent_tools.logger` and `ii_server.logger` use STDLIB %-STYLE `%s`.
+#
+# In a loguru file, `logger.info("foo %s bar", x)` does NOT interpolate. The
+# message renders literally as `foo %s bar` and the extra positional arg is
+# silently dropped. This has caused production debugging failures multiple
+# times (sandbox claim logs showing `row=%s slot=%s session=%s`).
+#
+# Rules:
+#   - In files that import `from ii_agent.core.logger import logger` or
+#     `from loguru import logger`: use f-strings or `{var}` placeholders with
+#     `.format()`/keyword args. NEVER `%s`, `%d`, `%r` with positional args.
+#       OK:  logger.info(f"Claimed slot {slot} for session {sid}")
+#       OK:  logger.info("Claimed slot {} for session {}", slot, sid)
+#       BAD: logger.info("Claimed slot %s for session %s", slot, sid)
+#   - In files that import `from ii_agent_tools.logger import get_logger` or
+#     `from ii_server.logger import get_logger`: use stdlib `%s`/`%d` style.
+#       OK:  logger.info("Claimed slot %s for session %s", slot, sid)
+#   - When migrating a file from stdlib to loguru (or vice versa), audit
+#     EVERY `logger.*` call in that file at the same time.