llm, update the AGENTS.md text to be a bit more over about when to stop due to blockers and how much effort to put in.

tasks/workstation/linux/software/llm.yml

@@ -598,15 +598,16 @@
 
               # Rules
 
-              Never use any `git` subcommands that change anything, including
+              Never use any `git` subcommands that change the repo, including
               but not limited to `add`, `commit`, `pull`, `push`, `branch`,
               `switch`, etc. The user is who controls the respository changes.
-              You may informational git subcommands such as use `git status`.
+              You may use informational git subcommands such as `git status`,
+              and may occasionally be asked to run `git clone` type commands.
 
               If any programs need installed in order to work on a project, we
-              need to document that in an install.sh script, as well as add it
-              to ~/PACKAGES.txt so that the user can ensure they stay installed.
-              install.sh scripts should be for both `apt` systems (Debian,
+              need to document that in an `install.sh` script, as well as add it
+              to `~/PACKAGES.txt` so that we can ensure they stay installed.
+              `install.sh` scripts should be for both `apt` systems (Debian,
               Ubuntu) and pacman system (Arch, Artix). using distribution
               package managers is preferable over `pip` and `npm` when
               possible, unless the project is actually Python or Node.js.
@@ -620,10 +621,27 @@
               such as `/usr/lib/jvm`, please ask the user and halt all further
               operations until you have received feedback.
 
+              # Effort
+
               It is never okay to brute force a solution if something is not
               working well. it is better to ask the user for assistance or alert
               them that you've encountered blockers and then cease the process
-              until you've received feedback.
+              until you've received feedback. This especially relates to when
+              system errors occur which are not related to the source code, such
+              as a compiler failing to be found or an SDK version mismatch. If
+              the error is with the source code though, troubleshooting and code
+              changes should continue until the program is compiling properly.
+
+              For CLI projects such as script languages, the final result should
+              always be tested both to run successfully and have the proper
+              output. All test cases should be analyzed and walked through,
+              which will help ensure all the requirements have been met.
+
+              For GUI programs (such as Android, Flutter, Kotlin Multiplatform,
+              Kivy, etc), the project should be tested to both compile & build
+              successfully and also generate the proper installation file (APK,
+              Linux Bundle). Once that is confirmed, the user/desginer will test
+              that the application meets the proper requirements.
 
               # Preferences