context fixes

Author: Zvi Fried

src/mcp_as_a_judge/prompts/shared/critical_tool_warnings.md

@@ -2,3 +2,4 @@
 
 - Skipping this tool causes severe token inefficiency and wasted iterations.
 - Always invoke this tool at the appropriate stage to avoid extreme token loss and redundant processing.
+- Do not rely on assistant memory for identifiers. Always pass the exact `task_id` and recover it via `get_current_coding_task` if missing.

src/mcp_as_a_judge/prompts/system/judge_coding_plan.md

@@ -42,6 +42,7 @@ Evaluate submissions against the following comprehensive SWE best practices:
 - Is there evidence of understanding industry best practices?
 - Are trade-offs between different approaches analyzed?
 - Does the research demonstrate avoiding reinventing the wheel?
+ - Does research explicitly cover all major aspects implied by the user requirements, not just a subset (e.g., cover each system, protocol, framework, or integration mentioned)?
 
 **🏗️ Internal Codebase Analysis (ONLY evaluate if Status: REQUIRED):**
 - Validate that existing codebase patterns are properly considered
@@ -156,7 +157,7 @@ IMPORTANT applicability rule:
 ### 1. User Requirements Alignment
 
 - Does the plan directly address the user's stated requirements?
-- Are all user requirements covered in the implementation plan?
+- Are all user requirements decomposed into explicit sub-aspects (components, integrations, protocols, patterns) and covered in the implementation plan and research?
 - Is the solution appropriate for what the user actually wants to achieve?
 - Flag any misalignment between user needs and proposed solution
 

src/mcp_as_a_judge/prompts/system/research_requirements_analysis.md

@@ -86,6 +86,7 @@ Always emphasize research quality over pure quantity:
 - Recency and relevance to current technology versions
 - Practical applicability to the specific task context
 - Coverage of implementation details and edge cases
+ - Multi-aspect coverage: Ensure the research plan explicitly maps to ALL major aspects implied by the user requirements (each referenced system, framework, protocol, integration), rather than focusing on a single subset.
 
 ## Analysis Output Requirements
 
@@ -107,4 +108,4 @@ You must respond with a JSON object that matches this schema:
 - **Context Sensitivity**: Consider the specific repository and project needs
 - **Practical Balance**: Don't over-research simple tasks or under-research complex ones
 - **Clear Reasoning**: Always explain why a specific count is recommended
-- **Adaptive Approach**: Different tasks need different research strategies
+- **Adaptive Approach**: Different tasks need different research strategies

src/mcp_as_a_judge/prompts/system/research_validation.md

@@ -43,6 +43,7 @@ Evaluate if the research is comprehensive enough and if the design is properly b
 - **REJECT IF MISSING**: No URLs provided means no online research was performed - REJECT immediately
 - **ONLINE RESEARCH EVIDENCE**: Do URLs demonstrate actual online research into implementation approaches and existing libraries?
 - **EXISTING SOLUTIONS FOCUS**: Do URLs show research into current repo capabilities, well-known libraries, and best practices?
+- **FULL REQUIREMENTS COVERAGE**: Do the provided URLs collectively cover ALL major aspects implied by the user requirements (each named system, framework, protocol, integration), rather than focusing on a single subset?
 - **REJECT IMMEDIATELY**: Missing URLs, insufficient online research, or failure to investigate existing solutions first
 
 ## Response Requirements

src/mcp_as_a_judge/prompts/system/workflow_guidance.md

@@ -62,9 +62,9 @@ CREATED → PLANNING → PLAN_APPROVED → IMPLEMENTING → REVIEW_READY → TES
   - For XS/S tasks: Skip planning, proceed to implementation (next_tool: null, but guidance must explain: implement → judge_code_change → judge_testing_implementation → judge_coding_task_completion)
   - For M/L/XL tasks: Recommend planning tools (judge_coding_plan)
 - **PLANNING** → Validate plan or gather more requirements
-- **PLAN_APPROVED** → Start implementation (implement ALL code AND tests, ensure tests pass)
-- **IMPLEMENTING** → Continue implementation until ALL code AND tests are complete and passing, then call judge_code_change
-- **REVIEW_READY** → Validate implementation code (judge_code_change for code review ONLY, not tests)
+- **PLAN_APPROVED** → Start implementation (begin coding; tests may be written before or after review)
+- **IMPLEMENTING** → After code changes are ready, call judge_code_change to review implementation; then proceed to testing
+- **REVIEW_READY** → Optional state if used by client; otherwise proceed directly from IMPLEMENTING to judge_code_change
 - **TESTING** → Validate test results and coverage (judge_testing_implementation ONLY)
 - **COMPLETED** → Workflow finished (next_tool: null)
 - **BLOCKED** → Resolve obstacles (raise_obstacle)
@@ -86,6 +86,7 @@ When recommending judge_coding_plan, the preparation_needed MUST include ALL ele
 - Detailed implementation plan with code examples
 - System design with architecture and data flow
 - List of files to be modified or created
+ - Research coverage plan that maps to ALL major aspects in the user requirements (each referenced system, framework, protocol, integration). Avoid focusing on a single subset; ensure multi-aspect coverage.
 
 **Conditionally Required (check task metadata):**
 - **If research_required = true**: Gather research URLs (minimum based on research_scope)
@@ -130,14 +131,13 @@ preparation_needed: [
 - judge_code_change has been approved
 - Code review is complete and implementation approved
 - Ready for test results and coverage validation
-- The task is transitioning from REVIEW_READY to TESTING state
+- The task is in or transitioning to TESTING state
 
 **DO NOT call judge_code_change for:**
-- Individual file changes during implementation
-- Partial implementations
-- Work-in-progress code
-- Single file modifications
-- Before testing validation is complete
+- Clearly incomplete, non-compilable, or placeholder code
+- Changes unrelated to the approved plan
+
+Note: You may call judge_code_change for a logical code change even if tests are not yet written or are failing. Tests are validated separately after code review.
 
 ### Task Completion Logic
 

src/mcp_as_a_judge/prompts/tool_descriptions/get_current_coding_task.md

@@ -3,6 +3,8 @@
 ## Description
 Retrieve the most recently active coding task UUID (task_id) and metadata from conversation history. Use when the task_id is missing from context.
 
+{% include 'shared/critical_tool_warnings.md' %}
+
 ## When to use
 - Need the task_id for follow-up tool calls
 - Want to resume the last active coding task

src/mcp_as_a_judge/prompts/tool_descriptions/judge_code_change.md

@@ -1,12 +1,12 @@
 # Judge Code Change
 
 ## Description
-Review implementation code (not tests) once all implementation work is complete and tests are passing. Called when `workflow_guidance.next_tool == "judge_code_change"`.
+Review implementation code (not tests) when implementation changes are ready for review. Tests are validated separately by `judge_testing_implementation`. Called when `workflow_guidance.next_tool == "judge_code_change"`.
 
 {% include 'shared/critical_tool_warnings.md' %}
 
 ## When to use
-- All implementation files written/modified, tests exist and pass; ready for review
+- After creating or modifying implementation code and a review is needed. Tests may be written before or after review; they are validated via `judge_testing_implementation`.
 
 ## Human-in-the-Loop (HITL) checks
 - If foundational choices are unclear or need confirmation (e.g., framework/library, UI vs CLI, web vs desktop, API style, auth, hosting), first call `raise_missing_requirements` to elicit the user’s intent
@@ -25,6 +25,6 @@ Review implementation code (not tests) once all implementation work is complete
 {{ JUDGE_RESPONSE_SCHEMA }}
 ```
 
-## Notes
-- Review only implementation code here; tests are validated via `judge_testing_implementation`. Always use the exact `task_id`.
+- Review only implementation code here; tests are validated via `judge_testing_implementation`.
+- Always use the exact `task_id`; recover it via `get_current_coding_task` if missing.
 - If HITL was performed, update the task description/requirements via `set_coding_task` if text needs to be clarified for future steps

src/mcp_as_a_judge/prompts/tool_descriptions/judge_coding_plan.md

@@ -3,6 +3,8 @@
 ## Description
 Validate a proposed plan and design against requirements, research needs, and risks. Called when `workflow_guidance.next_tool == "judge_coding_plan"`.
 
+{% include 'shared/critical_tool_warnings.md' %}
+
 ## Prerequisites
 - Thoroughly analyze requirements, propose a concrete plan, and produce a system design
 

src/mcp_as_a_judge/prompts/tool_descriptions/judge_coding_task_completion.md

@@ -24,4 +24,5 @@ Final validation gate before declaring a task complete. Called when `workflow_gu
 ```
 
 ## Notes
-- Do not present completion summaries to the user without calling this tool. Always use the exact `task_id`.
+- The AI coding assistant MUST NOT present or claim task completion, or provide a final completion summary to the user, without successfully calling this tool and receiving approval.
+- Always use the exact `task_id`; if missing due to memory limits, recover it via `get_current_coding_task`.

src/mcp_as_a_judge/prompts/tool_descriptions/judge_testing_implementation.md

@@ -3,6 +3,8 @@
 ## Description
 Validate test quality, coverage, and execution results after code review is approved. Called when `workflow_guidance.next_tool == "judge_testing_implementation"`.
 
+{% include 'shared/critical_tool_warnings.md' %}
+
 ## Args
 - `task_id`: string — Task UUID (required)
 - `test_summary`: string — Summary of the implemented tests (required)
@@ -21,4 +23,5 @@ Validate test quality, coverage, and execution results after code review is appr
 ```
 
 ## Notes
-- Use after `judge_code_change` is approved. Follow `workflow_guidance.next_tool` for the next step. Always use the exact `task_id`.
+- Use after `judge_code_change` is approved. Follow `workflow_guidance.next_tool` for the next step.
+- Always use the exact `task_id`; recover it via `get_current_coding_task` if missing.