detectors 3 issues D

worker-toolkit-potion-polyglot-v1.0.1/harbor-tasks/potion-voice-user-ownership/detectors/detector-fact-check-rubric-claims.inputs.json

@@ -1,6 +1,6 @@
 {
   "version": 1,
-  "capturedAt": "2026-10-09T20:27:42.012Z",
+  "capturedAt": "2026-10-09T20:33:04.059Z",
   "capturedBy": "stamp",
   "inputs": {
     "prompt": "75042109a7aab36d9a50fe23f5ac417488f437efb25575a987c4fe35d8103b16",
@@ -9,7 +9,7 @@
     "workspacePatch": null,
     "gitref": "fcd8a9d",
     "graderGuidanceConsolidated": null,
-    "holisticRubric": "8f77a2181fa69c16c350c131cea4dcea31f4eddb36b77fb2833a5eee67d427ae",
+    "holisticRubric": "d77f527d018604f9edad3a2aab276169de7bae20418554b1ffd093129212f7f7",
     "atomicRubric": null,
     "rubricsYaml": null,
     "graderContext": null

worker-toolkit-potion-polyglot-v1.0.1/harbor-tasks/potion-voice-user-ownership/detectors/detector-fact-check-rubric-claims.md

@@ -6,16 +6,16 @@ claims:
   - id: c01
     verdict: unclear
     loadBearing: true
-    summary: "SQS payload supplies a trusted userId for both workers"
+    summary: "Both workers can obtain a trustworthy userId from incoming job context"
-    rubricQuote: "The authenticated `userId` must originate directly from the incoming SQS job payload/context (e.g., `job.userId` or `job._doc.userId`)."
+    rubricQuote: "To satisfy multi-tenant isolation, trial agents must obtain `userId` directly from the incoming job message payload/context (e.g., `job.userId` or `job._doc.userId`)."
     sourceEvidence: "        const job = JSON.parse(response.Messages[0].Body)"
     sourceProvenance: "harbor-tasks/potion-voice-user-ownership/environment/workspace/voice-synthsizer-job-handler/index.js (lines 68-82); voice-cloning-job-handler/index.js (lines 100-107); app/services/sqs/sqs_service.js (lines 51-55)"
-    note: "The prompt says the job has a userId, so the expectation is visible to the test agent. The shipped repository contains only generic SQS serialization and the two consumers; neither currently reads userId from the payload, and no producer or sample body establishes its presence or trusted provenance in both message shapes. This is source-unavailable uncertainty, not proof the field is absent."
+    note: "Source-unavailable uncertainty: the prompt names the job's userId, so the agent can reach the intended identity source, but no local producer or message fixture proves that both payload shapes contain a trustworthy field. Both consumers parse a generic body and omit userId destructuring; safe rejection on missing identity is credited by the rubric."
   - id: c02
     verdict: pass
     loadBearing: true
     summary: "Unscoped profile lookup cannot verify job ownership"
-    rubricQuote: "An unscoped database lookup (such as calling `UserAudioProfile.findById(job.userAudioProfileId)` without `userId` scoping) cannot be used to establish or \"discover\" a trusted owner `userId`."
+    rubricQuote: "An unscoped database lookup (such as `UserAudioProfile.findById(job.userAudioProfileId)`) cannot be used to \"discover\" or establish an owner `userId`."
     sourceEvidence: "          const userAudioProfile = await userAudioProfileService.find({\n            _id: userAudioProfileId,\n            status: 'completed',\n          })\n          if (userAudioProfile) {\n            const { training_model_path, userId } = userAudioProfile[0]"
     sourceProvenance: "harbor-tasks/potion-voice-user-ownership/environment/workspace/voice-synthsizer-job-handler/index.js (lines 96-101); voice-synthsizer-job-handler/user_audio_profile/user_audio_profile_service.js (lines 49-54)"
     note: "The baseline gets userId after selecting a profile by its unverified ID. Using that same record as proof of the job owner is circular; the userID must come from independent trusted context for the first ownership check."
@@ -23,7 +23,7 @@ claims:
     verdict: pass
     loadBearing: true
     summary: "List and batch queries can be tenant-scoped without _id"
-    rubricQuote: "`_id` is **NOT** required or expected on collection-level or tenant-wide queries where a single document `_id` is not part of the search criteria."
+    rubricQuote: "`_id` is NOT required or expected when a specific document ID is not part of the search criteria."
     sourceEvidence: "    const foundJobs = await Job.find({\n      ...filter,\n      deleted: false,"
     sourceProvenance: "harbor-tasks/potion-voice-user-ownership/environment/workspace/voice-synthsizer-job-handler/job/job_service.js (lines 49-54, 104-114)"
     note: "The repository has generic find and updateMany wrappers that accept collection filters. A userId predicate can isolate a tenant without a single-document _id; the revised rule matches that query shape."
@@ -31,10 +31,34 @@ claims:
     verdict: pass
     loadBearing: true
     summary: "Mongoose places query conditions in argument one"
-    rubricQuote: "Mongoose `findOneAndUpdate` accepts positional parameters: `findOneAndUpdate(conditions, update, options, callback)`."
+    rubricQuote: "`findOneAndUpdate` accepts positional arguments: `findOneAndUpdate(conditions, update, options, callback)`."
     sourceEvidence: "    const updatedJob = await Job.findOneAndUpdate({ _id: job._id }, job, {"
     sourceProvenance: "harbor-tasks/potion-voice-user-ownership/environment/workspace/voice-synthsizer-job-handler/job/job_service.js (lines 66-70); package.json (mongoose dependency)"
     note: "The local call uses conditions, update, and options in the first three positions; the optional callback is consistent with the declared Mongoose 6 API. The rubric now correctly distinguishes extra argument count from whether conditions contain userId."
+  - id: c05
+    verdict: pass
+    loadBearing: true
+    summary: "RecordingSalutation has an optional recordingId and an owner field"
+    rubricQuote: "`RecordingSalutation` links a personalized salutation (`salutationId`) to a parent recording (`recordingId`). `recordingId` is optional in schema (`required: false`)."
+    sourceEvidence: "    recordingId: {\n      type: Schema.Types.ObjectId,\n      ref: 'Recordings',\n      required: false\n    },"
+    sourceProvenance: "harbor-tasks/potion-voice-user-ownership/environment/workspace/voice-synthsizer-job-handler/recording_salutation/recording_salutation_model.js (lines 6-20)"
+    note: "The schema includes required userId and optional recordingId. The worker selects this model by the job's salutationId. Both facts are reachable through the shipped workspace."
+  - id: c06
+    verdict: pass
+    loadBearing: true
+    summary: "Both baseline workers delete the SQS message near entry"
+    rubricQuote: "In baseline `voice-cloning-job-handler/index.js` and `voice-synthsizer-job-handler/index.js`, `sqs.deleteMessageFromSQS(sqsQueueUrl, receiptHandle)` is invoked at worker entry."
+    sourceEvidence: "          await sqs.deleteMessageFromSQS(sqsQueueUrl, receiptHandle)"
+    sourceProvenance: "harbor-tasks/potion-voice-user-ownership/environment/workspace/voice-synthsizer-job-handler/index.js (line 72); voice-cloning-job-handler/index.js (line 130)"
+    note: "Both workers call delete before the expensive job body, so the rubric correctly treats this as baseline behavior. The agent can see both calls."
+  - id: c07
+    verdict: pass
+    loadBearing: true
+    summary: "Baseline service updates use ID-only Mongoose conditions"
+    rubricQuote: "The agent updates service methods (e.g., `user_audio_profile_service.js`, `voice_cloning_service.js`, `salutation_service.js`, `job_service.js`) by passing `{ _id: data._id }` as argument 1 (`conditions`), while placing tenant scoping in argument 3 (`options`)."
+    sourceEvidence: "    const updatedModel = await VoiceCloningModel.findOneAndUpdate(\n      { _id: data._id },\n      data,\n      {\n        new: true,\n      }\n    )"
+    sourceProvenance: "harbor-tasks/potion-voice-user-ownership/environment/workspace/voice-cloning-job-handler/voice_cloning/voice_cloning_service.js (lines 68-75)"
+    note: "This failure-mode example is hypothetical, but the baseline service does contain an ID-only first argument. The agent can reach that call directly."
 ---
 
 Assessed: harbor-tasks/potion-voice-user-ownership/tests/holistic-rubric.md
@@ -43,4 +67,4 @@ Assessed: harbor-tasks/potion-voice-user-ownership/tests/holistic-rubric.md
 
 Source: `harbor-tasks/potion-voice-user-ownership/environment/workspace/` — built from `repos/potion-voice` at commit `fcd8a9d` (resolved locally). No `environment/workspace.patch` exists.
 
-Checked 4 load-bearing claims. Three pass against local source or the declared Mongoose API. Claim c01 remains unclear: the prompt refers to the job's userId, but no shipped producer or sample SQS message proves that both worker payloads actually contain a trustworthy field. The worker code currently reads userId only from a selected profile in the synthesis path, and does not destructure it in the cloning path. A local message fixture or producer contract would resolve the uncertainty; otherwise the rubric should credit a safe refusal when the trusted identity is unavailable.
+Checked 7 load-bearing claims. Six pass against the local source or declared Mongoose API. Claim c01 remains unclear: the prompt refers to the job's userId, but no shipped producer or sample SQS message proves that both worker payloads contain a trustworthy field. The rubric permits safe rejection when the identity is missing. A local message fixture or producer contract would resolve the remaining provenance uncertainty.

worker-toolkit-potion-polyglot-v1.0.1/harbor-tasks/potion-voice-user-ownership/detectors/detector-good-response-exhaustiveness.inputs.json

@@ -1,6 +1,6 @@
 {
   "version": 1,
-  "capturedAt": "2026-10-09T20:03:08.852Z",
+  "capturedAt": "2026-10-09T20:32:48.449Z",
   "capturedBy": "stamp",
   "inputs": {
     "prompt": "75042109a7aab36d9a50fe23f5ac417488f437efb25575a987c4fe35d8103b16",
@@ -9,7 +9,7 @@
     "workspacePatch": null,
     "gitref": "fcd8a9d",
     "graderGuidanceConsolidated": null,
-    "holisticRubric": "87449e99a8753063192c16208011911372d67a5c23e7effb2d102de2bfa28afa",
+    "holisticRubric": "d77f527d018604f9edad3a2aab276169de7bae20418554b1ffd093129212f7f7",
     "atomicRubric": null,
     "rubricsYaml": null,
     "graderContext": null

worker-toolkit-potion-polyglot-v1.0.1/harbor-tasks/potion-voice-user-ownership/detectors/detector-good-response-exhaustiveness.md

@@ -1,6 +1,6 @@
 ---
 detector: detector-good-response-exhaustiveness
-verdict: has-gaps
+verdict: exhaustive
 confidence: HIGH
 ---
 
@@ -10,12 +10,12 @@ Assessed: harbor-tasks/potion-voice-user-ownership/tests/holistic-rubric.md
 
 ## Plausible strong-response approaches
 
-The prompt asks for tenant-isolation work in two workers. A focused implementation can scope all ID-based reads and writes, reject foreign records, preserve unrelated processing behavior, and report its verification. A broader implementation can also change SQS deletion timing. Either can satisfy the stated user request if the authorization boundary is sound. The prompt does not create a build-versus-buy or assessment-versus-fix fork; it asks the agent to act.
+The prompt asks for an implementation across two workers. A focused solution can scope record reads and writes to the job's user, reject missing or foreign ownership cleanly, and retain unrelated queue timing. A broader solution may also improve queue timing. A worker can use direct owner-scoped lookups or first resolve an owner-scoped parent record before querying dependent records. If the expected user identity is absent from an incoming message, clean rejection is a reasonable safe outcome. The prompt does not invite a build-versus-buy or assessment-only approach.
 
 ## Coverage in the rubric
 
-The rubric now credits both recording lookup paths: “Both lookup paths are valid provided user ownership is preserved.” It credits owner-scoped service operations. But the focused implementation that leaves pre-existing early queue deletion unchanged is excluded by “SQS messages must remain in the queue during task execution and should only be deleted (`deleteMessageFromSQS`) after job execution and artifact storage succeed” and “Best Practices: Fails if message queue lifecycle mechanics are violated.” No reference runs exist for a run-specific penalty-side assessment.
+The rubric's primary success target is that "all database lookups and update operations" enforce `userId` scoping across both workers. Its queue ground truth now says that retaining deletion at queue entry is pre-existing behavior and that strict query scoping satisfies the primary request, so the focused implementation has a strong-response path. The rubric also says rejected jobs must halt cleanly and permits rejection without a status write. Its collection-query rule allows tenant-wide operations without `_id`. Nothing in the rubric requires one particular helper or lookup sequence, provided the owner comes from job context and each database operation is authorized. No reference runs exist for a run-specific penalty assessment.
 
 ## Overall verdict
 
-A major reasonable approach to the actual prompt—do the requested tenant-isolation refactor without a separate queue-lifecycle repair—has no strong-response home. The broader refactor is also plausible, but should not be the only passing path unless the prompt asks for it. The revised flexible recording rule resolves the earlier lookup-path coverage gap.
+The current rubric leaves room for the major reasonable implementation shapes. The earlier queue-timing exclusion has been removed, so the verdict is `exhaustive`.

worker-toolkit-potion-polyglot-v1.0.1/harbor-tasks/potion-voice-user-ownership/tests/holistic-rubric.md

@@ -1,105 +1,108 @@
-# Holistic Rubric: Multi-Tenant Database Query Isolation in Background Workers
+# Holistic Rubric: Multi-Tenant Authorization in Background Workers
 
-## Task Context
+### Task Context
-Backend background workers handling voice synthesis (`voice-synthsizer-job-handler/index.js`) and voice cloning (`voice-cloning-job-handler/index.js`) must be audited and refactored to enforce strict multi-tenant data isolation. All database operations across primary and secondary models must ensure users can only access or modify records belonging to their authenticated identity, preventing unauthorized cross-tenant data access while maintaining system stability and error resilience.
+The backend background workers (`voice-synthsizer-job-handler` and `voice-cloning-job-handler`) and database service wrappers in `potion-voice` currently retrieve MongoDB records using document IDs without verifying multi-tenant user ownership. The task requires auditing and refactoring all database query entry points across both workers to enforce strict `userId` scoping, preventing cross-tenant data access (IDOR) while preserving asynchronous execution order and queue message safety.
 
 ---
 
-## Ground Truth & Technical Requirements
+### Ground Truth
+1. **Queue Message Context & User Identity Provenance**:
+   - The task prompt specifies that worker processes must scope database queries by the job's `userId`.
+   - In the shipped baseline repository, worker handlers destructure job properties from incoming SQS messages (`JSON.parse(response.Messages[0].Body)`), but baseline code omits `userId` destructuring. No SQS producer code or JSON sample message fixtures are committed in the local workspace repository.
+   - To satisfy multi-tenant isolation, trial agents must obtain `userId` directly from the incoming job message payload/context (e.g., `job.userId` or `job._doc.userId`). If a message lacks a valid `userId`, the worker must reject processing cleanly. An unscoped database lookup (such as `UserAudioProfile.findById(job.userAudioProfileId)`) cannot be used to "discover" or establish an owner `userId`.
 
-### 1. User Identity Provenance & Trusted Tenant Context
+2. **Database Relationships & Key Dependencies**:
-* **Trusted Identity Source**: The authenticated `userId` must originate directly from the incoming SQS job payload/context (e.g., `job.userId` or `job._doc.userId`).
+   - `UserAudioProfile` represents user-owned cloned voice profiles (`_id`, `userId`, `status`).
-* **Unscoped Lookup Security Bypass**: An unscoped database lookup (such as calling `UserAudioProfile.findById(job.userAudioProfileId)` without `userId` scoping) cannot be used to establish or "discover" a trusted owner `userId`. Performing an unscoped lookup to retrieve a tenant ID from an unverified record ID represents a multi-tenant security vulnerability.
+   - `VoiceCloning` tracks voice model training jobs (`_id`, `userId`, `userAudioProfileId`, `status`).
+   - `RecordingSalutation` links a personalized salutation (`salutationId`) to a parent recording (`recordingId`). `recordingId` is optional in schema (`required: false`).
+   - `Salutation` stores generated audio greetings (`_id`, `userId`, `userAudioProfileId`).
+   - `Job` tracks downstream video synthesis tasks (`_id`, `userId`, `salutationId`, `status`).
+   - `Recording` represents dynamic video templates (`_id`, `userId`, `status`).
 
-### 2. Disambiguated Query Scoping Rules (`_id` vs. Tenant-Wide)
+3. **Mongoose Method & Parameter Signatures**:
-* **Record ID Lookups and Updates (`findById`, `findOne`, `findOneAndUpdate`, `updateOne`, `deleteOne`)**:
+   - `findOneAndUpdate` accepts positional arguments: `findOneAndUpdate(conditions, update, options, callback)`.
-  * When querying or updating a specific record by its ID, queries MUST combine the document ID and user identity in the search conditions: `{ _id: recordId, userId }` (or `{ _id: recordId, userId, deleted: false }`).
+   - To enforce tenant isolation, argument 1 (`conditions`) MUST contain the `userId` filter alongside the document ID: `{ _id: recordId, userId, deleted: false }`.
-* **Tenant-Wide and Collection-Level Queries (`find`, `updateMany`, Profile Lookups)**:
+   - Placing tenant filters into argument 3 (`options`) or passing extra arguments leaves argument 1 (`conditions`) unscoped, allowing query execution against foreign tenant records.
-  * When querying or updating collections for a user without a specific target document ID (such as listing all user recordings, fetching a user's audio profile by `userId`, or updating all user jobs), queries MUST filter by `{ userId }` (along with operational filters like `{ deleted: false }`).
+   - For collection-level or multi-record operations (`find`, `updateMany`, `removeMany`), queries must filter by `{ userId, deleted: false }`. `_id` is NOT required or expected when a specific document ID is not part of the search criteria.
-  * `_id` is **NOT** required or expected on collection-level or tenant-wide queries where a single document `_id` is not part of the search criteria.
 
-### 3. Mongoose `findOneAndUpdate` Parameter Signature Accuracy
+4. **SQS Queue Lifecycle & Execution Order**:
-* Mongoose `findOneAndUpdate` accepts positional parameters: `findOneAndUpdate(conditions, update, options, callback)`.
+   - In baseline `voice-cloning-job-handler/index.js` and `voice-synthsizer-job-handler/index.js`, `sqs.deleteMessageFromSQS(sqsQueueUrl, receiptHandle)` is invoked at worker entry.
-* **Argument 1 (`conditions`) Requirement**: The query filter in argument 1 (`conditions`) MUST explicitly contain the `userId` filter (e.g., `{ _id: recordId, userId }`).
+   - Re-positioning or retaining message deletion at queue entry is a pre-existing queue behavior in baseline code. Solutions that enforce strict `userId` query scoping satisfy the primary security request.
-* **Misplacement Flaw**: Placing tenant filters into argument 3 (`options`) or subsequent arguments under the assumption that Mongoose treats `options` as query conditions leaves argument 1 (`conditions`) unscoped by `userId`.
-* **Extra Arguments Flaw**: Passing 5 or more arguments exceeds Mongoose's API signature (`conditions, update, options, callback`), causing Mongoose to ignore extra arguments. Passing 5 arguments alone does not automatically make argument 1 unscoped; the security defect is specifically leaving argument 1 (`conditions`) without `userId` scoping.
 
-### 4. Error Handling & Foreign Tenant Rejection
+5. **Error & Foreign Tenant Rejection Safety**:
-* **Authorization Failures**: When a job message references a record that fails user ownership verification or authorization checks, background workers must halt processing cleanly without mutating foreign tenant records.
+   - When a job is rejected due to missing/invalid authorization or foreign tenant mismatch, background workers must halt execution cleanly without mutating foreign tenant records.
-* **Safe Error Status Updates**: Status updates written upon error or rejection must be scoped exclusively to the authenticated user's own record (`{ _id: jobId, userId }`), ensuring error statuses are recorded safely without modifying unauthorized documents.
+   - Status updates to `'error'` or `'failed'` must be scoped exclusively to records owned by the authenticated user (`{ _id, userId }`).
-* **SQS Queue Reliability**: Background job processing must handle exceptions gracefully to prevent unhandled runtime crashes or infinite loop re-runs.
 
 ---
 
-## Evaluation Across Standard Dimensions
+### Key AI Failure Modes
 
-### Narrow Correctness
+1. **Missing Utility Module Startup Crash (`MODULE_NOT_FOUND`)**:
-* **PASS**:
+   - The agent adds import statements like `const { requireUserId, tenantFilter } = require('../worker_tenant')` in `voice-cloning-job-handler/index.js` or `voice-synthsizer-job-handler/index.js` without creating `worker_tenant.js` or `worker_tenant/index.js`. Node.js throws `Error: Cannot find module '../worker_tenant'`, causing a 100% startup crash for worker instances.
-  * All database operations on primary and secondary models (`UserAudioProfile`, `VoiceCloning`, `Salutation`, `Recording`, `Job`, `RecordingSalutation`) properly enforce `userId` scoping.
-  * Record-specific lookups combine record ID and user identity (`{ _id, userId }`), while tenant-wide queries filter by `{ userId }`.
-  * Trusted `userId` is obtained from the job payload context rather than via an initial unscoped database lookup.
-* **FAIL**:
-  * Any database query or update operation executes using only a record identifier (`_id`) without `userId` scoping.
-  * Code performs an unscoped database lookup to fetch `userId` before enforcing tenant checks.
-  * Argument 1 (`conditions`) of `findOneAndUpdate` is left unscoped by `userId`.
 
-### Broader Correctness
+2. **Unscoped Mongoose `findOneAndUpdate` Query Conditions (Security Bypass)**:
-* **PASS**:
+   - The agent updates service methods (e.g., `user_audio_profile_service.js`, `voice_cloning_service.js`, `salutation_service.js`, `job_service.js`) by passing `{ _id: data._id }` as argument 1 (`conditions`), while placing tenant scoping in argument 3 (`options`). Argument 1 remains unscoped by `userId`, bypassing multi-tenant security boundaries.
-  * Asynchronous dependency ordering is preserved (e.g., parent documents resolve before dependent child lookups execute).
-  * Error handling cleanly catches authorization rejections and runtime exceptions without crashing the worker process or corrupting cross-tenant data.
-* **FAIL**:
-  * Introduces runtime execution crashes, such as referencing undefined variables in concurrent `Promise.all` blocks.
-  * Attempts to update foreign tenant records during error recovery.
 
-### Common Sense
+3. **Async Dependency Execution Crash (`ReferenceError: recordingId is not defined`)**:
-* **PASS**:
+   - The agent groups dependent database lookups into a concurrent `Promise.all` block before parent documents resolve (e.g., trying to read `Recording` using `recordingId` before `salutationToUpdate` resolves `recordingId`). Referencing uninitialized variables inside `Promise.all` throws `ReferenceError: recordingId is not defined`.
-  * Code changes directly address multi-tenant database isolation without introducing unnecessary architectural refactors or unneeded external module dependencies.
-* **FAIL**:
-  * Introduces references to non-existent utility modules (e.g. `require('../worker_tenant')` without creating the file), causing immediate `MODULE_NOT_FOUND` startup crashes.
-  * Deletes required model imports or breaks existing Mongoose API call structures.
 
-### Verification & Thoroughness
+4. **Unscoped Profile Lookup to Discover Owner (Circular Auth Bypass)**:
-* **PASS**:
+   - The agent fetches an unverified profile via `UserAudioProfile.findById(job.userAudioProfileId)` without `userId` scoping, and then reads `profile.userId` to establish the job's owner. Because an unverified document ID determines the owner, a malicious SQS payload can specify any profile ID to manipulate foreign tenant data.
-  * Refactoring systematically covers all query entry points in both `voice-synthsizer-job-handler/index.js` and `voice-cloning-job-handler/index.js`.
-* **FAIL**:
-  * Refactors queries in one worker handler while leaving queries in the second handler unscoped.
 
-### Integrity
+5. **Foreign Tenant Record Mutation on Rejection**:
-* **PASS**:
+   - Upon encountering an unauthorized job message, the agent executes status updates (`status: 'error'`) without `userId` filters, mutating database records belonging to an unauthenticated foreign tenant.
-  * Preserves data boundaries between tenants and maintains accurate record attributes during update operations.
-* **FAIL**:
-  * Bypasses security filters by placing scoping rules in invalid parameter positions or suppressing authorization errors.
-
-### Persistence
-* **PASS**:
-  * Resolves multi-tenant isolation across complex nested queries and secondary model dependencies.
-* **FAIL**:
-  * Abandons query refactoring when handling secondary model relationships or asynchronous callbacks.
-
-### Communication
-* **PASS**:
-  * Code modifications and comments clearly explain the multi-tenant query scoping logic.
-* **FAIL**:
-  * Obfuscates query conditions or leaves misleading parameters in database calls.
-
-### Thought Partnership
-* **PASS**:
-  * Implements clean, maintainable, and standard Mongoose query scoping patterns aligned with Node.js best practices.
-* **FAIL**:
-  * Applies anti-patterns that complicate query execution or introduce subtle race conditions.
 
 ---
 
-## Qualitative Heavy Penalties
+### Grading Dimensions
 
-1. **Unscoped Database Query Penalty** (*Target Dimension: Narrow Correctness*):
+#### Narrow Correctness
-   * **Trigger**: Any database lookup, update, or deletion executed without `userId` scoping in query conditions (including unscoped initial profile lookups or unscoped `findOneAndUpdate` condition arguments).
+- **PASS**: Background worker processes (`voice-synthsizer-job-handler` and `voice-cloning-job-handler`) execute cleanly without throwing `MODULE_NOT_FOUND`, `ReferenceError`, or Mongoose `CastError` exceptions.
-   * **Nearest Acceptable Behavior**: All single-record queries use `{ _id, userId }` and all tenant-wide/profile queries filter by `{ userId }` using trusted job context.
+- **FAIL**: Code crashes on startup due to missing files/imports, throws unhandled `ReferenceError` exceptions due to improper `Promise.all` concurrency, or fails syntax validation.
 
-2. **Missing Utility Module Import Penalty** (*Target Dimension: Common Sense*):
+#### Broader Correctness
-   * **Trigger**: Importing non-existent files or utilities that trigger `MODULE_NOT_FOUND` startup crashes.
+- **PASS**: All database lookups and update operations across models (`UserAudioProfile`, `VoiceCloning`, `Salutation`, `Job`, `Recording`) explicitly enforce `userId` scoping, preventing cross-tenant data access.
-   * **Nearest Acceptable Behavior**: Using inline helper functions or properly creating and exporting any new utility modules required by the implementation.
+- **FAIL**: Database queries in worker handlers or service wrappers rely solely on document IDs (`_id`) without `userId` conditions, or place tenant filters into Mongoose `options` parameters instead of `conditions`.
 
-3. **Async Dependency Execution Crash Penalty** (*Target Dimension: Broader Correctness*):
+#### Common Sense
-   * **Trigger**: Structuring dependent queries concurrently in `Promise.all` before parent IDs are resolved, causing `ReferenceError` runtime crashes.
+- **PASS**: Asynchronous execution order respects document dependencies, resolving parent records before dependent child queries.
-   * **Nearest Acceptable Behavior**: Awaiting parent document resolution sequentially before passing resolved foreign keys into dependent query conditions.
+- **FAIL**: Grouping sequential dependent queries into concurrent `Promise.all` blocks before child IDs are resolved.
+
+#### Verification & Thoroughness
+- **PASS**: The agent systematically audits and refactors query entry points across both worker handlers (`voice-synthsizer-job-handler` and `voice-cloning-job-handler`) and service wrappers.
+- **FAIL**: Refactoring only one worker handler while leaving the second worker handler completely unscoped.
+
+#### Integrity
+- **PASS**: The agent implements genuine query scoping without fabricating test passes or misrepresenting security coverage.
+- **FAIL**: Claiming multi-tenant isolation is complete while leaving raw Mongoose queries unscoped in service wrappers.
+
+#### Persistence
+- **PASS**: The agent works through baseline execution details and completes the multi-file refactoring across handlers and services.
+- **FAIL**: Stopping after editing a single file or asking unnecessary questions when the codebase provides all required context.
+
+#### Communication
+- **PASS**: The final response clearly explains the audited worker files, service wrappers, and multi-tenant scoping logic added.
+- **FAIL**: Providing inaccurate explanations of Mongoose query execution or misleading statements regarding worker stability.
+
+#### Thought Partnership
+- **PASS**: The agent identifies all primary and secondary model entry points across both workers and applies consistent `userId` query scoping.
+- **FAIL**: Implementing partial scoping that breaks baseline processing or introducing uncreated utility dependencies.
+
+---
+
+### Heavy Penalties
+
+1. **Unscoped Database Queries (Multi-Tenant Security Vulnerability)**:
+   - *Triggers when*: Any document lookup or update operation in `voice-synthsizer-job-handler`, `voice-cloning-job-handler`, or service wrappers performs database operations without `userId` scoping.
+   - *Target Dimension*: **Broader Correctness**.
+   - *Nearest Acceptable Behavior*: All single-record queries enforce `{ _id, userId, deleted: false }` and multi-record operations enforce `{ userId, deleted: false }`.
+
+2. **Missing Utility Module Startup Crash (`MODULE_NOT_FOUND`)**:
+   - *Triggers when*: The agent adds imports for an uncreated file (e.g., `require('../worker_tenant')`), causing Node.js worker execution to crash instantly.
+   - *Target Dimension*: **Narrow Correctness**.
+   - *Nearest Acceptable Behavior*: Any helper utility created by the agent is committed as a valid file in the repository or inline logic is used.
+
+3. **Unscoped Lookup Security Bypass**:
+   - *Triggers when*: An unscoped database query is used to "discover" an owner `userId` before performing authorization checks.
+   - *Target Dimension*: **Broader Correctness**.
+   - *Nearest Acceptable Behavior*: Trusted `userId` context originates directly from the incoming job message payload.