From e95ae3a4309f076b295341157ba1bf24fae15251 Mon Sep 17 00:00:00 2001 From: "Tobias J. Endres" Date: Tue, 2 Sep 2025 22:06:04 +0200 Subject: [PATCH] docs: Update lessons learned with insights on task execution order --- lessons_learned.md | 1 + 1 file changed, 1 insertion(+) diff --git a/lessons_learned.md b/lessons_learned.md index 8ff96a7..657ce08 100644 --- a/lessons_learned.md +++ b/lessons_learned.md @@ -14,3 +14,4 @@ * **Verifying Tool Capabilities:** Do not assume limitations of tools (e.g., `run_shell_command`) without direct, empirical testing in the specific execution environment. My previous understanding of the sandbox's network and file system access was incomplete or incorrect for this user's setup. * **"Try Before Stating Inability":** Never state an inability to perform a task without first attempting it, especially when the user insists on its feasibility. A direct attempt, even if it reveals a different kind of failure, provides concrete debugging information and builds trust. This is a fundamental principle for effective assistance. * **Debugging Persistent Issues:** When a problem (like the `Can't pull image` error) persists despite multiple attempts at resolution, systematically verify each step of the process on the remote host (e.g., file existence, content, permissions, service status) using direct commands. +* **Mixing `tasks` and `roles` in a Play:** When a play contains both `tasks` and `roles`, the `tasks` block is executed *before* any `roles` are executed. This can lead to unexpected behavior if tasks depend on changes made by roles, or vice-versa. Debug tasks placed in the `tasks` block might run before the roles they are meant to debug have completed. \ No newline at end of file