detectors 3 issues F

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:38:04.767Z",
+  "capturedAt": "2026-10-09T20:43:06.353Z",
   "capturedBy": "stamp",
   "inputs": {
     "prompt": "75042109a7aab36d9a50fe23f5ac417488f437efb25575a987c4fe35d8103b16",
@@ -9,7 +9,7 @@
     "workspacePatch": null,
     "gitref": "fcd8a9d",
     "graderGuidanceConsolidated": null,
-    "holisticRubric": "96fbf11f88d75df8536a78e973d0bf80d6fb6d7fd2cb13c26aa2621d1df2f1f5",
+    "holisticRubric": "4d15b1fc738ecaf6a034ed8f4860a5bc4d3cd6a17ec5455ffb40d7fcc78a2abd",
     "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

@@ -1,21 +1,21 @@
 ---
 detector: detector-fact-check-rubric-claims
-verdict: fail
+verdict: partial
 confidence: MEDIUM
 claims:
   - id: c01
-    verdict: unclear
+    verdict: pass
     loadBearing: true
-    summary: "Both workers can obtain a trustworthy userId from incoming job context"
+    summary: "No local SQS producer or payload fixture establishes a userId in both message shapes"
-    rubricQuote: "To satisfy multi-tenant isolation, trial agents must obtain `userId` directly from incoming job message context (e.g., `job.userId` or `job._doc.userId`)."
+    rubricQuote: "In the baseline repository, no SQS producer files or sample payload JSON fixtures are committed. Worker consumers parse SQS messages (`JSON.parse(response.Messages[0].Body)`), but baseline code omits `userId` destructuring."
     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: "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."
+    note: "The workspace has the two consumers and a generic SQS sender utility, but no producer for these jobs or example payload. Both consumers parse a body without destructuring userId. The rubric now states this uncertainty and credits safe rejection when the field is missing; it does not assert that both payloads certainly contain it."
   - id: c02
     verdict: pass
     loadBearing: true
     summary: "Unscoped profile lookup cannot verify job ownership"
-    rubricQuote: "An unscoped database lookup (such as `UserAudioProfile.findById(job.userAudioProfileId)`) cannot be used as an identity source to \"discover\" an owner `userId` before ownership is established."
+    rubricQuote: "Performing an initial unscoped database lookup (such as `UserAudioProfile.findById(job.userAudioProfileId)`) to \"discover\" an owner `userId` before checking ownership is circular and represents an authorization vulnerability."
     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: "Document `_id` is **not** required or expected when a single document ID is not part of the query criteria."
+    rubricQuote: "Collection-level or tenant-wide queries (`find`, `updateMany`) filter by `{ userId }` without requiring document `_id`."
     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,31 +31,31 @@ claims:
     verdict: pass
     loadBearing: true
     summary: "Mongoose places query conditions in argument one"
-    rubricQuote: "`findOneAndUpdate` accepts positional parameters `findOneAndUpdate(conditions, update, options, callback)`."
+    rubricQuote: "Mongoose `findOneAndUpdate` accepts positional parameters: `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 calls use conditions, update, and options in the first three positions; a callback is a fourth accepted argument in the rubric's own stated signature. The agent can inspect these call sites and the declared Mongoose 6 dependency."
   - id: c05
-    verdict: fail
+    verdict: partial
     loadBearing: true
-    summary: "Four arguments allegedly exceed a three-argument Mongoose signature and are ignored"
+    summary: "A fifth findOneAndUpdate argument exceeds the listed signature, but its runtime effect is unverified"
-    rubricQuote: "Passing 4 or 5 arguments exceeds Mongoose's 3-argument signature and causes trailing arguments to be ignored."
+    rubricQuote: "Passing 5 arguments exceeds Mongoose's valid parameter positions, causing trailing arguments to be ignored."
     sourceEvidence: "    \"mongoose\": \"^6.8.0\","
-    sourceProvenance: "harbor-tasks/potion-voice-user-ownership/environment/workspace/voice-synthsizer-job-handler/package.json (line 14); tests/holistic-rubric.md (line 24)"
+    sourceProvenance: "harbor-tasks/potion-voice-user-ownership/environment/workspace/voice-synthsizer-job-handler/package.json (line 14); tests/holistic-rubric.md (line 21)"
-    note: "The same rubric sentence gives a four-position signature ending in callback, then says four arguments exceed three positions. That is internally contradictory; Mongoose 6 also supports the callback position. The repository identifies Mongoose 6, although its installed library source is not shipped. The categorical four-argument claim is false and can misgrade valid code."
+    note: "Five exceeds the rubric's listed four positions, so the earlier internal contradiction is fixed. The workspace declares Mongoose 6 but does not ship its implementation or an executed five-argument example, so the precise claim that the fifth argument is ignored remains unverified from the source package. This mechanism detail should not be used to grade an agent; whether userId is in argument 1 is directly checkable."
   - id: c06
-    verdict: pass
+    verdict: partial
     loadBearing: true
-    summary: "RecordingSalutation has an optional recordingId and an owner field"
+    summary: "RecordingSalutation has an optional recordingId, but no salutationId schema field"
-    rubricQuote: "Note that `recordingId` is an optional schema field (`required: false`)."
+    rubricQuote: "In `RecordingSalutation` (`voice-synthsizer-job-handler/recording_salutation/recording_salutation_model.js`), `recordingId` is an optional field (`required: false`), while `userId` and `salutationId` define the record."
     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)"
+    sourceProvenance: "harbor-tasks/potion-voice-user-ownership/environment/workspace/voice-synthsizer-job-handler/recording_salutation/recording_salutation_model.js (lines 4-65); voice-synthsizer-job-handler/index.js (lines 151-155)"
-    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."
+    note: "The schema includes required userId and optional recordingId. The worker selects this model by _id using the job's salutationId; salutationId itself is not a schema field. This wording could mislead a grader into expecting a salutationId field predicate, although the intended lookup key is reachable from the worker."
   - id: c07
     verdict: pass
     loadBearing: true
     summary: "Both baseline workers delete the SQS message near entry"
-    rubricQuote: "In baseline code (`voice-synthsizer-job-handler/index.js` line 72 and `voice-cloning-job-handler/index.js` line 130), `sqs.deleteMessageFromSQS(sqsQueueUrl, receiptHandle)` is invoked near worker entry."
+    rubricQuote: "Both baseline workers (`voice-synthsizer-job-handler/index.js` line 72 and `voice-cloning-job-handler/index.js` line 130) invoke `sqs.deleteMessageFromSQS(sqsQueueUrl, receiptHandle)` near 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."
@@ -63,7 +63,7 @@ claims:
     verdict: pass
     loadBearing: true
     summary: "Baseline service updates use ID-only Mongoose conditions"
-    rubricQuote: "Queries rely solely on `_id` without `userId` validation, perform circular unscoped lookups to discover owner IDs, or place tenant filters into Mongoose `options` parameters leaving query conditions unscoped."
+    rubricQuote: "Database queries rely solely on document `_id` without `userId` validation, perform circular unscoped lookups to discover owner IDs, or place tenant filters into Mongoose `options` parameters (argument 3) leaving query conditions (argument 1) unscoped."
     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: "The baseline service contains an ID-only first argument, and the synthesis worker discovers userId after an unscoped profile lookup. These are reachable examples of the failures the rubric describes."
@@ -75,4 +75,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 8 load-bearing claims. Six pass, c01 remains unclear because no shipped producer or sample SQS message confirms a trustworthy `userId` in both payload shapes, and c05 fails: the rubric's four-argument Mongoose signature contradicts its new claim that four arguments exceed a three-argument signature and are ignored. The rubric permits safe rejection when identity is missing; a local message fixture or producer contract would resolve c01.
+Checked 8 load-bearing claims. Six pass and two are partial. The prior four-argument contradiction is fixed; c05's claim that Mongoose ignores a fifth argument is not established by shipped source. In c06, `salutationId` names the job's identifier for a `RecordingSalutation` document, while the schema has no `salutationId` field. The rubric accurately acknowledges that the presence of `userId` in both payload shapes is unverified and permits safe rejection when it is missing.

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

@@ -1,85 +1,80 @@
 # Holistic Rubric: Multi-Tenant Authorization in Background Workers
 
 ### Task Context
-The goal is to audit and refactor background SQS worker handlers (`voice-synthsizer-job-handler/index.js` and `voice-cloning-job-handler/index.js`) and database service wrappers in `potion-voice` to enforce strict multi-tenant data isolation by scoping all MongoDB queries with `userId`. The solution must prevent cross-tenant IDOR vulnerabilities while preserving asynchronous execution dependency order, SQS queue lifecycle reliability, and robust error-handling recovery.
+The goal is to audit and refactor background SQS worker handlers (`voice-synthsizer-job-handler` and `voice-cloning-job-handler`) and database service wrappers in `potion-voice` to enforce strict multi-tenant data isolation by scoping all MongoDB queries with `userId`. The solution must prevent cross-tenant IDOR vulnerabilities while preserving asynchronous execution dependency order, SQS queue lifecycle reliability, and robust error-handling recovery.
-
----
 
 ### Ground Truth
+1. **Queue Message Context & Identity Source**:
+   * The task prompt mandates `userId` scoping across background worker jobs.
+   * In the baseline repository, no SQS producer files or sample payload JSON fixtures are committed. Worker consumers parse SQS messages (`JSON.parse(response.Messages[0].Body)`), but baseline code omits `userId` destructuring.
+   * Trial agents must obtain `userId` directly from the incoming SQS job context (`job.userId` or `job._doc.userId`). If an incoming job payload lacks a valid `userId`, the worker must reject processing cleanly without executing unscoped database queries or mutating records.
+   * Performing an initial unscoped database lookup (such as `UserAudioProfile.findById(job.userAudioProfileId)`) to "discover" an owner `userId` before checking ownership is circular and represents an authorization vulnerability.
 
-1. **Queue Message Context & User Identity Provenance**:
+2. **Database Schema & Relationships**:
-   * The task prompt instructs trial agents to audit background job handlers and scope all database operations by `userId`.
+   * In `RecordingSalutation` (`voice-synthsizer-job-handler/recording_salutation/recording_salutation_model.js`), `recordingId` is an optional field (`required: false`), while `userId` and `salutationId` define the record.
-   * **Source-Unavailable Environment Fact**: The shipped `potion-voice` repository contains worker consumers (`voice-synthsizer-job-handler/index.js` and `voice-cloning-job-handler/index.js`) and queue service utilities (`app/services/sqs/sqs_service.js`), but does **not** include SQS producer code or sample message JSON fixtures.
+   * `recordingId` may be provided directly in the job payload (`job.recordingId`) or resolved via `salutationToUpdate.recordingId` after loading `RecordingSalutation`. Both extraction paths are valid.
-   * To satisfy multi-tenant isolation, trial agents must obtain `userId` directly from incoming job message context (e.g., `job.userId` or `job._doc.userId`). If an incoming queue message context lacks a `userId` field, workers must reject processing cleanly and safely without performing unscoped database lookups or mutating records.
-   * An unscoped database lookup (such as `UserAudioProfile.findById(job.userAudioProfileId)`) cannot be used as an identity source to "discover" an owner `userId` before ownership is established.
 
-2. **Database Relationships & Entity Lookups**:
+3. **Mongoose Function Signatures & Parameter Scoping**:
-   * `RecordingSalutation` (`recording_salutation_model.js`) links a personalized salutation (`salutationId`) to a parent recording (`recordingId`). Note that `recordingId` is an optional schema field (`required: false`).
+   * Mongoose `findOneAndUpdate` accepts positional parameters: `findOneAndUpdate(conditions, update, options, callback)`.
-   * `recordingId` can be provided directly in the job message payload or extracted from `salutationToUpdate.recordingId` after resolving `RecordingSalutation`. Both extraction paths are valid.
+   * Tenant scoping must be placed in argument 1 (`conditions`), e.g., `{ _id, userId, deleted: false }`.
-   * `Salutation` (`salutation_model.js`), `Recording` (`recording_model.js`), `UserAudioProfile` (`user_audio_profile_model.js`), `VoiceCloning` (`voice_cloning_model.js`), and `Job` (`job_model.js`) store tenant ownership references.
+   * Placing tenant filters (`{ ...tenantFilter({ _id, userId }) }`) into argument 3 (`options`) leaves argument 1 (`conditions`) unscoped by `userId` (`{ _id: data._id }`), bypassing user ownership checks.
+   * Passing 5 arguments exceeds Mongoose's valid parameter positions, causing trailing arguments to be ignored.
 
-3. **Mongoose Query Standards**:
+4. **Queue Lifecycle & Asynchronous Dependency Order**:
-   * **Single-Record ID Lookups & Updates**: Every primary and secondary model operation targeting a specific document by ID (`findById`, `findOne` by record ID, `findOneAndUpdate`) must combine document ID and user ownership: `{ _id, userId, deleted: false }`.
+   * Both baseline workers (`voice-synthsizer-job-handler/index.js` line 72 and `voice-cloning-job-handler/index.js` line 130) invoke `sqs.deleteMessageFromSQS(sqsQueueUrl, receiptHandle)` near worker entry. While deleting messages before task completion is a baseline flaw, solutions that enforce strict `userId` query scoping satisfy the primary security request. SQS deletion timing is evaluated under Broader Correctness as secondary pipeline reliability.
-   * **Tenant-Wide & Collection Queries**: Generic collection searches or batch operations (`find`, `updateMany`) must filter by `{ userId, deleted: false }`. Document `_id` is **not** required or expected when a single document ID is not part of the query criteria.
+   * Asynchronous dependencies must follow proper execution order. Grouping dependent lookups (such as fetching a parent document before using its child ID) into concurrent `Promise.all` blocks before child IDs are defined causes runtime crashes (`ReferenceError: recordingId is not defined`).
-   * **Mongoose Function Signatures**: `findOneAndUpdate` accepts positional parameters `findOneAndUpdate(conditions, update, options, callback)`. Tenant scoping filters must be placed in argument 1 (`conditions`), e.g., `{ _id: recordId, userId }`. Placing tenant filters into argument 3 (`options`) leaves argument 1 (`conditions`) unscoped, bypassing user ownership checks. Passing 4 or 5 arguments exceeds Mongoose's 3-argument signature and causes trailing arguments to be ignored.
 
-4. **Queue Lifecycle & Async Execution Order**:
+5. **Error Handling & State Transitions**:
-   * In baseline code (`voice-synthsizer-job-handler/index.js` line 72 and `voice-cloning-job-handler/index.js` line 130), `sqs.deleteMessageFromSQS(sqsQueueUrl, receiptHandle)` is invoked near worker entry.
+   * When an SQS job fails or fails authorization, status updates must be scoped safely to documents owned by the authenticated user (`{ _id, userId }`), ensuring error status is written without mutating foreign tenant records.
-   * Solutions that enforce strict `userId` database query scoping satisfy the primary task mandate. SQS message durability and queue retention timing are evaluated under secondary reliability considerations without penalizing baseline deletion timing.
+   * Halting processing cleanly on authorization rejection without mutating unauthorized foreign records fulfills the prompt's data isolation mandate.
-   * Dependent lookups must respect execution chronology (e.g., resolving parent records before referencing child IDs). Grouping sequential dependent lookups into concurrent `Promise.all` blocks before child IDs resolve throws runtime `ReferenceError` exceptions.
-
-5. **Error Transitions & Authorization Rejections**:
-   * When a job fails due to an error or authorization rejection, workers must halt processing without mutating unauthorized or foreign tenant records.
-   * Status updates (`'error'`) must be scoped strictly to the authenticated user's own job or profile records (`{ _id, userId }`).
-
----
 
 ### Grading Dimensions
 
 #### Narrow Correctness
-* **PASS**: The worker handlers execute cleanly without runtime exceptions, syntax errors, or unhandled promise rejections.
+* **PASS**: Background worker handlers execute cleanly without runtime exceptions, missing module import errors (`MODULE_NOT_FOUND`), syntax errors, or unhandled promise rejections.
-* **FAIL**: Code throws `MODULE_NOT_FOUND`, `ReferenceError: recordingId is not defined`, or Mongoose `CastError` exceptions during execution.
+* **FAIL**: Code throws `MODULE_NOT_FOUND` (e.g., importing non-existent `worker_tenant.js`), `ReferenceError: recordingId is not defined`, or Mongoose `CastError` exceptions during execution.
 
 #### Broader Correctness
-* **PASS**: All primary and secondary MongoDB queries and updates enforce `userId` scoping, preventing cross-tenant data access.
+* **PASS**: All document lookups and update operations by ID (`findOne`, `findOneAndUpdate`, `findById`, `update`) across primary and secondary models (`UserAudioProfile`, `VoiceCloning`, `Salutation`, `Job`, `Recording`) enforce `userId` scoping in their query conditions (`{ _id, userId, deleted: false }`).
-* **FAIL**: Queries rely solely on `_id` without `userId` validation, perform circular unscoped lookups to discover owner IDs, or place tenant filters into Mongoose `options` parameters leaving query conditions unscoped.
+* **FAIL**: Database queries rely solely on document `_id` without `userId` validation, perform circular unscoped lookups to discover owner IDs, or place tenant filters into Mongoose `options` parameters (argument 3) leaving query conditions (argument 1) unscoped.
 
 #### Common Sense
-* **PASS**: Asynchronous execution follows proper chronological order (resolving parent documents before accessing dependent child properties).
+* **PASS**: Asynchronous dependency execution follows proper chronological order (resolving parent documents before accessing dependent child properties). Collection-level or tenant-wide queries (`find`, `updateMany`) filter by `{ userId }` without requiring document `_id`.
-* **FAIL**: Grouping dependent sequential queries into concurrent execution blocks or referencing uninitialized variables.
+* **FAIL**: Grouping sequential dependent queries into concurrent `Promise.all` blocks or passing unverified foreign IDs into database operations.
 
 #### Verification & Thoroughness
-* **PASS**: The response verifies database query scoping across both worker handlers and service wrappers (`job_service.js`, `salutation_service.js`, `user_audio_profile_service.js`, `voice_cloning_service.js`).
+* **PASS**: The worker implementation and query modifications are verified against baseline repository code structure and model schemas.
-* **FAIL**: Claiming complete multi-tenant scoping while leaving secondary model queries or service wrapper methods unscoped.
+* **FAIL**: Claiming complete multi-tenant isolation or worker pipeline health without verifying that query conditions include `userId`.
 
 #### Integrity
-* **PASS**: Honest reporting of implemented query scoping and verification steps.
+* **PASS**: The agent provides an accurate, honest assessment of its implementation without fabricating test results or misrepresenting Mongoose API behavior.
-* **FAIL**: Claiming multi-tenant authorization was verified when database queries remain unscoped by `userId`.
+* **FAIL**: Fabricating test suite executions or claiming that passing filters in Mongoose `options` parameter successfully scopes database queries.
 
 #### Persistence
-* **PASS**: Continues through code refactoring across both worker handlers and service layers.
+* **PASS**: The agent systematically audits and refactors queries across both background workers and service wrappers.
-* **FAIL**: Stopping after editing one worker handler while leaving the other worker handler unscoped.
+* **FAIL**: Abandoning multi-tenant refactoring after modifying only one worker or service file.
 
 #### Communication
-* **PASS**: Clear, accurate summary of queries updated and tenant isolation enforced.
+* **PASS**: Explanations clearly describe how multi-tenant query scoping was enforced across models and handlers.
-* **FAIL**: Inaccurate or misleading summary of code changes.
+* **FAIL**: Vague or misleading reports that fail to explain how tenant isolation was achieved.
 
 #### Thought Partnership
-* **PASS**: Identifies multi-tenant access boundaries and handles missing or invalid tenant context safely.
+* **PASS**: Refactors database operations cleanly while maintaining backwards compatibility with existing job processing workflows.
-* **FAIL**: Blindly executing database operations without checking user identity provenance.
+* **FAIL**: Unnecessarily breaking existing worker handler functionality or introducing redundant code structures.
-
----
 
 ### Heavy Penalties
 
-1. **Unscoped Database Queries (Broader Correctness & Narrow Correctness)**
+1. **Unscoped Database Queries (Security Bypass)**
-   * **Trigger**: Any document lookup or update operation by ID (`findOne`, `findOneAndUpdate`, `findById`, `update`) on primary or secondary models that omits `userId` from argument 1 (`conditions`).
+   * **Trigger**: Any document lookup or update operation by ID on primary or secondary models (`UserAudioProfile`, `VoiceCloning`, `Salutation`, `Job`, `Recording`) that executes with query conditions lacking `userId` validation (e.g., `{ _id: data._id }`).
-   * **Nearest Acceptable**: All ID-based document lookups and updates enforce `{ _id, userId, deleted: false }` in query conditions.
+   * **Nearest Acceptable Behavior**: Combining document ID and user identity in query conditions: `{ _id, userId, deleted: false }` for single-record operations, or `{ userId, deleted: false }` for collection queries.
+   * **Target Dimension**: `Broader Correctness`
 
-2. **Missing Utility Module Startup Crash (Narrow Correctness)**
+2. **Missing Utility Module Import Crash (`MODULE_NOT_FOUND`)**
-   * **Trigger**: Importing uncreated utility files (e.g., `const { requireUserId } = require('../worker_tenant')` without creating `worker_tenant.js`), causing `MODULE_NOT_FOUND` runtime crashes.
+   * **Trigger**: Adding import statements for uncreated utility modules (e.g., `const { requireUserId } = require('../worker_tenant')` without creating `worker_tenant.js`), causing Node.js to crash at startup.
-   * **Nearest Acceptable**: All imported utility modules exist and load cleanly.
+   * **Nearest Acceptable Behavior**: Creating the imported utility file with required helper functions or placing utility functions directly within existing workspace files.
+   * **Target Dimension**: `Narrow Correctness`
 
-3. **Async Execution Order Crash (Common Sense & Narrow Correctness)**
+3. **Async Execution Dependency Crash (`ReferenceError`)**
-   * **Trigger**: Grouping dependent queries into `Promise.all` before parent IDs resolve, triggering `ReferenceError: recordingId is not defined` runtime crashes.
+   * **Trigger**: Grouping dependent sequential database operations into concurrent `Promise.all` blocks before child parameters (such as `recordingId`) are resolved from parent queries.
-   * **Nearest Acceptable**: Sequential document lookups resolve parent records before referencing child properties.
+   * **Nearest Acceptable Behavior**: Awaiting parent document resolution sequentially before passing extracted properties into dependent child queries.
+   * **Target Dimension**: `Common Sense`