[Chore] Remove the completion check

apps/api/src/handlers/tasks/index.ts

@@ -19,7 +19,6 @@ import { manageSourceControl } from './manageSourceControl';
 import { updateTaskModelSelection } from './updateModelSelection';
 import { listTaskModels } from './listModels';
 import { saveTaskMemory } from './saveTaskMemory';
-import { checkTaskCompletion } from './checkTaskCompletion';
 import { recordAutomationResult } from './recordAutomationResult';
 import { updatePersonalization } from './updatePersonalization';
 
@@ -44,5 +43,4 @@ tasksRouter.post('/:taskId/task_suggestions', submitTaskSuggestions);
 tasksRouter.post('/:taskId/automation_result', recordAutomationResult);
 tasksRouter.post('/:taskId/mcp_recommendations', submitMcpRecommendations);
 tasksRouter.post('/runs/:runId/memory', saveTaskMemory);
-tasksRouter.post('/runs/:runId/completion_check', checkTaskCompletion);
 tasksRouter.post('/runs/:runId/personalization', updatePersonalization);

apps/docs/models.mdx

@@ -355,10 +355,6 @@ When a judgment model is on, Roomote asks it first for:
 - choosing the forum tag when Roomote opens a thread in a Discord forum channel
 - whether a settled session or task turn holds something worth saving to
   [Memory](/memory) that the agent did not record itself
-- checking a finished coding turn against the evidence: the request, the
-  agent's checklist, the diff, and the commands it ran. This check has no
-  helper-model fallback; without a judgment model the agent runs its own slower
-  review pass instead. See [Tasks](/tasks)
 
 Roomote acts on the judgment model only when it is confident. When it is
 unsure, unavailable, or returns an error, Roomote keeps the behavior it has

apps/docs/tasks.mdx

@@ -171,22 +171,8 @@ video. Roomote skips visual proof when it would not add useful evidence. Judge
 the evidence against the stated result rather than requiring a recording for
 every change.
 
-When a [judgment model](/models#judgment-model) is configured, Roomote
-automatically holds the agent's work against the evidence at the moments that
-matter: before the agent reports to you, before it pushes or opens a pull
-request, and when its turn ends with code changes. The evidence is what you
-asked for, the agent's own checklist, the diff, and the shell commands it
-actually ran. It looks for a requested item or
-checklist item left undone without explanation, a claimed change the diff does
-not contain, a claimed test or build result the recorded commands do not
-support, code shipped with no validation and no reason, an interface change
-with visual proof waved off, a plain defect in the changed lines, and leftovers
-such as debug logging or a disabled test. If anything is found, the report or
-push is held once with the reasons, so the agent fixes or explains before a
-person sees the claim or the code ships; a second attempt for the same work
-always goes through. The check takes about a second and does not replace pull
-request review. Without a judgment
-model, the agent runs a slower review pass of its own before delivery instead.
+When visual proof kept screenshots or recordings, a separate reviewer opens
+them and checks that they show the shipped change before the task reports back.
 
 Visual proof should use genuine application, authentication, database, and
 backend state when practical. When an artifact instead uses disclosed simulated