@profoundlogic/coderflow-server 0.6.8 → 0.7.0

package/dist/base-image/Dockerfile

@@ -188,6 +188,9 @@ COPY apply-local-state.sh /usr/local/bin/apply-local-state.sh
 COPY coder-git-credential-helper /usr/local/bin/coder-git-credential-helper
 RUN chmod +x /usr/local/bin/entrypoint.sh /usr/local/bin/sync-repos.sh /usr/local/bin/rewind-files.sh /usr/local/bin/agent-wrapper.sh /usr/local/bin/start-code-server.sh /usr/local/bin/apply-local-state.sh /usr/local/bin/coder-git-credential-helper
 
+# Standard instruction templates
+COPY standard-instructions/ /usr/local/share/standard-instructions/
+
 # Expose code-server port
 EXPOSE 8080
 

package/dist/base-image/entrypoint.sh

@@ -899,6 +899,19 @@ main() {
         log "Copying AGENTS.md from /coder-setup/$ENVIRONMENT/" >&2
         cp "/coder-setup/$ENVIRONMENT/AGENTS.md" /workspace/AGENTS.md
 
+        # Append standard instruction blocks to AGENTS.md if configured
+        # STANDARD_INSTRUCTIONS env var contains space-separated block names (e.g. "output-requirements screenshot-guidelines")
+        STANDARD_INSTRUCTIONS_DIR="/usr/local/share/standard-instructions"
+        if [ -n "$STANDARD_INSTRUCTIONS" ] && [ -d "$STANDARD_INSTRUCTIONS_DIR" ]; then
+            for block in $STANDARD_INSTRUCTIONS; do
+                if [ -f "$STANDARD_INSTRUCTIONS_DIR/$block.md" ]; then
+                    printf '\n' >> /workspace/AGENTS.md
+                    cat "$STANDARD_INSTRUCTIONS_DIR/$block.md" >> /workspace/AGENTS.md
+                    log "Standard instructions appended: $block" >&2
+                fi
+            done
+        fi
+
         # Create agent-specific symlink based on CODER_AGENT or default_agent
         AGENT="${CODER_AGENT:-${default_agent:-claude}}"
         if [ "$AGENT" = "claude" ]; then

package/dist/base-image/standard-instructions/ibmi-database-sql.md

@@ -0,0 +1,11 @@
+## Database and SQL
+
+Use your skills to explore the database using SQL, as appropriate. Keep in mind:
+
+- You are working in a typical IBM i development environment. A data library is included on your library list.
+- It's normal that data files are not present in your build/task library.
+- Don't try to query SYSTABLES to discover what tables are available. Rather, look at the physical (.pf) and logical (.lf) file sources and SQL sources in the repo to determine what tables are available.
+- Table layouts can be discovered by interpreting the source code. You can also query the table with your SQL skill to return the table layout metadata along with query results.
+- It's not necessary to qualify table names with a schema/library in queries. Just refer to the known table names in the project and they will be found on your library list.
+- Do not attempt to use any tables that are not present in the source repo.
+- Do not attempt to alter existing tables unless specifically asked to.

package/dist/base-image/standard-instructions/ibmi-exploratory-verification.md

@@ -0,0 +1,38 @@
+## Exploratory Verification
+
+For any task involving interactive IBM i display file screens, you must perform some ad-hoc exploratory verifications before the task can be considered complete. This applies both to coding and non-coding tasks that involve interactive screens.
+
+The goal is to produce a coherent summary of your explorations, including screen renderings.
+
+1. Come up with a list of ad-hoc tests that verify your task is complete and working. The list should cover all affected screens. Keep a "mental note" (and/or temp file) of this list.
+2. For coding tasks, finish the coding work and verify all changes build successfully.
+3. Use your `ibmi-interactive-session` skill to start a new session.
+4. For each test case:
+
+- Use the `ibmi-interactive-session` skill to operate the application. Interpret the screen buffer and fields information to understand what is on screen and navigate to the screen you want to test and perform any required operations.
+- Keep "mental notes" (and/or temp files) of what you are doing and make sure that specific screen history file names can be correlated to each step.
+- In your notes, create a text summary that explains how your exploration passed or failed the test. Use the `ibmi-interactive-session` skill to produce an HTML rendering and correlate the generated `<iframe>` tag text with your summary. Do not use basic renderings unless HTML rendering fails, or unless you are specifically asked to.
+
+5. Review the results of your test cases.
+
+- If all pass, proceed to step 6.
+- If there are failures:
+    - If you think you can solve them, sign off and end your IBM i session. Restart at step 2.
+    - If the problems don't seem solvable, you can proceed to step 6.
+
+6. Sign off and end your session.
+7. Using your notes, prepare a final summary of all explorations, including corresponding renderings, as a temporary Markdown file. This content will be embedded directly in your final summary file. Use this format:
+
+## Exploratory Verification Results
+
+### Test Case 1: Title
+Summary text to describe the exploration and results
+
+<screen rendering>
+
+### Test Case 2: Title
+Summary text to describe the exploration and results
+
+<screen rendering>
+
+**Important** Make sure that screen rendering content is placed at the root of the Markdown document (i.e. not in lists, etc.) as shown above.

package/dist/base-image/standard-instructions/ibmi-output-requirements.md

@@ -0,0 +1,6 @@
+## IBM i Output Requirements
+
+In addition to the standard output requirements, your task summary must also include:
+
+- The IBM i task library name. Use the value from environment variable `IBMI_BUILD_LIBRARY`.
+- Exploratory verification results, if applicable. **Important**: Embed at the root of the `summary.md` file, i.e. not inside a list or any other element.

package/dist/base-image/standard-instructions/output-requirements.md

@@ -0,0 +1,18 @@
+## Output Requirements
+
+After completing any task, you MUST create the following output files:
+
+**Important: The `/task-output` directory is located at the SYSTEM ROOT, NOT inside `/workspace`. Ensure you write to `/task-output/...` and NOT `/workspace/task-output/...`.**
+
+### 1. Summary File: `/task-output/summary.md`
+
+Write a detailed summary explaining:
+
+- What you did and why
+- What issues you encountered and how you resolved them
+- Test results (if applicable)
+- Any recommendations or next steps
+
+### 2. Commit Message: `/task-output/commit-message.txt`
+
+Write a concise git commit message covering **all uncommitted changes** made during this session, not just the last thing you worked on. This message will be used to commit everything at once when changes are approved. Before writing, review all pending changes (e.g. via `git diff --stat`) in any repositories you modified to ensure nothing is missed.

package/dist/base-image/standard-instructions/screenshot-guidelines.md

@@ -0,0 +1,17 @@
+## Screenshot Guidelines
+
+When using Playwright or other tools to capture screenshots that demonstrate final results:
+
+- **Save screenshots to `/task-output/attachments/`** with descriptive filenames (e.g., `result-login-page.png`, `result-feature-complete.png`)
+
+- **Include in `summary.md`** using **markdown image syntax** (not HTML) with the `attachment://` URL scheme:
+
+    ```markdown
+    ![Description of the result](attachment://result-screenshot.png)
+    ```
+
+- **Important**: You MUST use markdown syntax `![alt](attachment://file.png)`. Do NOT use HTML `<img>` tags - they will not work.
+
+- The `attachment://` scheme is automatically resolved to the correct URL by the web interface
+
+- Only include screenshots that demonstrate the completed work or important outcomes