tests/core/src/embedding/embedding-service.spec.ts-54-57 (1)

54-57: ⚠️ Potential issue | 🟠 Major

Fix the incorrect expected length in the uses provided embed function test.

'much longer text' has length 16, so this assertion currently fails.

Suggested patch

-                expect(vector2).toEqual([17]);
+                expect(vector2).toEqual([16]);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/embedding/embedding-service.spec.ts` around lines 54 - 57, The
test "uses provided embed function" has the wrong expected length for vector2 —
the call to service.embed('much longer text') should produce a vector length of
16 (the string length), so update the assertion for vector2 (the
expect(vector2).toEqual([...]) line) to match [16]; leave the vector1 check
(expect(vector1).toEqual([5])) as-is and only change the expected numeric value
for vector2.

tests/core/src/embedding/embedding-service.spec.ts-63-69 (1)

63-69: ⚠️ Potential issue | 🟠 Major

Use plain it instead of it.effect for this non-effectful assertion.

This test block uses it.effect with Effect.gen(function* () { ... }) but contains no yield statements. Unlike the other test blocks in this file, this test performs only plain assertions and no Effect operations. Remove the it.effect and generator pattern to match the actual test semantics.

Suggested patch

-        it.effect('EmbeddingService tag is properly defined', () =>
-            Effect.gen(function* () {
-                const tag = EmbeddingService;
-                expect(tag).toBeDefined();
-                expect(tag.key).toBe('@eventiva/core/EmbeddingService');
-            })
-        );
+        it('EmbeddingService tag is properly defined', () => {
+            const tag = EmbeddingService;
+            expect(tag).toBeDefined();
+            expect(tag.key).toBe('@eventiva/core/EmbeddingService');
+        });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/embedding/embedding-service.spec.ts` around lines 63 - 69, The
test currently wraps plain assertions in an Effect generator (it.effect +
Effect.gen) even though there are no yields; update the test for
EmbeddingService by replacing the it.effect + Effect.gen(...) pattern with a
plain it(...) test body and remove the generator/Effect usage so the assertions
against the EmbeddingService tag and tag.key run directly.

tests/core/src/schema/table-relations-registry.spec.ts-11-66 (1)

11-66: 🛠️ Refactor suggestion | 🟠 Major

Add Effect observability instrumentation to test function definitions.

The test callbacks currently do not emit tracing/logging/metrics. This file should apply Effect observability wrappers (for example, Effect.withSpan, logging annotations, and metrics counters) around each test effect.

As per coding guidelines "**/*.{ts,tsx}: Implement logging, metrics, and tracing using Effect's built-in observability features for every function definition".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/schema/table-relations-registry.spec.ts` around lines 11 - 66,
Wrap each test Effect body with Effect observability helpers: use
Effect.withSpan to create a tracing span around the Effect.gen callback and add
logging/metrics annotations (e.g., attach a descriptive span name like
"tests.TableRelationsRegistry.<test-name>" and include annotations/tags for
table='test_table' and extension ids). Specifically, update the Effects created
in tests that build TableRelationsRegistryLive and call
registerRelations/getAllCallbacks (the tests referencing
TableRelationsRegistryLive, registry.registerRelations,
registry.getAllCallbacks, and the TableRelationsRegistry tag) so every
Effect.gen(...) is wrapped with observability (tracing span, and where
appropriate increment a metrics counter or add logging annotation) while
preserving the original assertions and yield* calls.

tests/databases/shared/project.json-5-5 (1)

5-5: ⚠️ Potential issue | 🟠 Major

Add the required layer:* tag to tags.

This project currently has a type tag but no layer tag, so it does not satisfy the repository’s project-tag contract.

🔧 Proposed fix

-    "tags": ["scope:tests", "type:database"],
+    "tags": ["scope:tests", "type:database", "layer:backend"],

As per coding guidelines **/project.json: "All packages must have 2-3 tags in project.json: a required Type tag (...), a required Layer tag (...), and optional Capability tags (...)".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/databases/shared/project.json` at line 5, The tags array in
project.json currently has "scope:tests" and "type:database" but is missing the
required layer tag; update the "tags" array (the "tags" key in this file) to
include an appropriate layer tag such as "layer:infrastructure" (e.g.,
["scope:tests","type:database","layer:infrastructure"]) so the project satisfies
the repository project-tag contract.

tests/databases/shared/src/index.spec.ts-1-7 (1)

1-7: ⚠️ Potential issue | 🟠 Major

Import expect explicitly (globals are disabled).

With globals: false, this test will fail because expect is used but not imported.

🔧 Proposed fix

-import { describe, it } from 'vitest';
+import { describe, it, expect } from 'vitest';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/databases/shared/src/index.spec.ts` around lines 1 - 7, The test uses
expect but the vitest globals are disabled; update the import line that
currently imports describe and it to also import expect (e.g., import {
describe, it, expect } from 'vitest') so the test referencing expect in the 'it'
block for the exported symbol typeid will run without relying on globals.

tests/databases/shared/tsconfig.json-2-9 (1)

2-9: ⚠️ Potential issue | 🟠 Major

Fix incorrect relative paths in tsconfig.json that break alias resolution.

The current paths in tests/databases/shared/tsconfig.json resolve to tests/packages/... instead of the repository root packages/..., causing all @eventiva/* aliases to fail resolution. The extends path has the same issue.

🔧 Fix

-    "extends": "../../tsconfig.base.json",
+    "extends": "../../../tsconfig.base.json",
@@
-            "@eventiva/databases.shared": ["../../packages/databases/shared/src/index.ts"],
-            "@eventiva/databases.shared/*": ["../../packages/databases/shared/src/*"]
+            "@eventiva/databases.shared": ["../../../packages/databases/shared/src/index.ts"],
+            "@eventiva/databases.shared/*": ["../../../packages/databases/shared/src/*"]

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/databases/shared/tsconfig.json` around lines 2 - 9, The tsconfig in
tests/databases/shared uses incorrect relative references so "extends":
"../../tsconfig.base.json" and the path mappings for
"@eventiva/databases.shared" and "@eventiva/databases.shared/*" resolve into
tests/packages instead of the repo root; update "extends" to point up one more
directory (e.g. "../../../tsconfig.base.json") and change the "paths" targets
from "../../packages/..." to "../../../packages/..." (adjust similarly for any
other "@eventiva/*" aliases) so the compilerOptions.paths entries and extends
correctly resolve to the repository-level packages and not tests/packages.

tests/databases/shared/vitest.config.ts-1-19 (1)

1-19: ⚠️ Potential issue | 🟠 Major

Add path-alias resolution in this Vitest project config.

This config does not declare vite-tsconfig-paths or resolve.alias. The test files in this project import @eventiva/databases.shared and other @eventiva/* modules, which are defined as path aliases in the tsconfig.json. Without vite-tsconfig-paths, Vitest will fail to resolve these imports.

🔧 Proposed fix

 import { defineProject } from 'vitest/config';
+import tsconfigPaths from 'vite-tsconfig-paths';
 
 export default defineProject({
+    plugins: [tsconfigPaths()],
     test: {
         include: ['src/**/*.spec.ts'],
         environment: 'node',

Note: tests/databases/pg/vitest.config.ts has the same issue.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/databases/shared/vitest.config.ts` around lines 1 - 19, The Vitest
project config lacks path-alias resolution so imports like `@eventiva/`* fail;
update the config created via defineProject to enable tsconfig path mapping by
importing and applying the vite-tsconfig-paths plugin (or add equivalent
resolve.alias entries) in the exported config's Vite options (e.g., add a
plugins: [tsconfigPaths()] entry or resolve.alias mapping) so test files
importing `@eventiva/databases.shared` and other `@eventiva/`* modules resolve
correctly.

tests/databases/shared/src/typeid.spec.ts-7-58 (1)

7-58: ⚠️ Potential issue | 🟠 Major

Replace Effect.gen(function* ...) with Effect.sync(...) for all six synchronous test blocks.

All six generator callbacks at lines 8, 17, 25, 33, 45, and 53 lack yield statements. Generator functions require yield or yield* to be valid; these tests only execute synchronous code.

🔧 Proposed fix

Replace each Effect.gen(function* () { ... }) with Effect.sync(() => { ... }). For example:

-        it.effect('creates column builder with default name', () =>
-            Effect.gen(function* () {
-                const builder = typeid();
-                expect(builder).toBeDefined();
-                expect(builder).toHaveProperty('_');
-            })
-        );
+        it.effect('creates column builder with default name', () =>
+            Effect.sync(() => {
+                const builder = typeid();
+                expect(builder).toBeDefined();
+                expect(builder).toHaveProperty('_');
+            })
+        );

Apply the same conversion to all six test blocks in this file.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/databases/shared/src/typeid.spec.ts` around lines 7 - 58, The tests use
Effect.gen(function* ...) unnecessarily without yields; replace each
Effect.gen(function* () { ... }) with Effect.sync(() => { ... }) in the six
synchronous test blocks so the callbacks run synchronously—update the six
occurrences surrounding the typeid(...) tests (the blocks that create builders
for default name, custom name, type prefix, different type prefixes, custom
name+type, and missing type) to call Effect.sync instead of Effect.gen.

tests/core/src/extensions/extension-hooks.spec.ts-22-24 (1)

22-24: ⚠️ Potential issue | 🟠 Major

Capture the layer context and retrieve the service explicitly.

The test discards the result of Layer.build(...) at line 22, then attempts to access ExtensionHookPubSub from the environment at line 23. However, Layer.build() only returns a Context object; it does not inject services into the current Effect environment. The service must be retrieved explicitly from the returned context.

Suggested fix

-import { Effect, Exit, Layer } from 'effect';
+import { Context, Effect, Exit, Layer } from 'effect';

-                yield* Layer.build(Layer.mergeAll(ExtensionHookPubSubLive, layer));
-                const pubsub = yield* ExtensionHookPubSub;
+                const ctx = yield* Layer.build(Layer.mergeAll(ExtensionHookPubSubLive, layer));
+                const pubsub = Context.get(ctx, ExtensionHookPubSub);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/extensions/extension-hooks.spec.ts` around lines 22 - 24, The
test currently discards the Context returned by
Layer.build(Layer.mergeAll(ExtensionHookPubSubLive, layer)) and then tries to
access ExtensionHookPubSub from the ambient environment; instead capture the
returned Context (e.g., const ctx = yield* Layer.build(...)) and then explicitly
retrieve the service from that context (e.g., use Context.get(ctx,
ExtensionHookPubSub) or the equivalent API in your Effect runtime) and call
publish on that retrieved pubsub; update the lines that call Layer.build and
access ExtensionHookPubSub accordingly so the service is obtained from the built
context.

tests/core/src/workflow/types.spec.ts-1-3 (1)

1-3: ⚠️ Potential issue | 🟠 Major

Import expect from Vitest in this file.

expect is used without being imported (lines 10, 20, 21, 22, 29, and 35). This will cause a runtime failure when Vitest globals are disabled.

Proposed fix

-import { describe, it } from 'vitest';
+import { describe, it, expect } from 'vitest';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/workflow/types.spec.ts` around lines 1 - 3, The test file
imports describe and it from 'vitest' but calls expect throughout; update the
top-level import that currently lists describe and it to also import expect so
the specs (which reference expect on lines 10, 20, 21, 22, 29 and 35) will work
when Vitest globals are disabled—i.e., modify the existing import statement that
mentions describe and it to include expect as well.

tests/databases/pg/tsconfig.json-2-13 (1)

2-13: ⚠️ Potential issue | 🟠 Major

Path mappings point to incorrect directory—they resolve under tests/packages/... instead of monorepo packages/...

The extends path and all @eventiva/* aliases resolve one directory too shallow. From tests/databases/pg/tsconfig.json, paths like ../../packages/... currently resolve to tests/packages/..., which do not exist. This directly causes the @eventiva/* module resolution failures.

The paths must be corrected to use ../../../ instead:

Correction required

-    "extends": "../../tsconfig.base.json",
+    "extends": "../../../tsconfig.base.json",
@@
-            "@eventiva/core": ["../../packages/core/src/index.ts"],
-            "@eventiva/core/*": ["../../packages/core/src/*"],
-            "@eventiva/databases.pg": ["../../packages/databases/pg/src/index.ts"],
-            "@eventiva/databases.pg/*": ["../../packages/databases/pg/src/*"],
-            "@eventiva/databases.shared": ["../../packages/databases/shared/src/index.ts"],
-            "@eventiva/databases.shared/*": ["../../packages/databases/shared/src/*"]
+            "@eventiva/core": ["../../../packages/core/src/index.ts"],
+            "@eventiva/core/*": ["../../../packages/core/src/*"],
+            "@eventiva/databases.pg": ["../../../packages/databases/pg/src/index.ts"],
+            "@eventiva/databases.pg/*": ["../../../packages/databases/pg/src/*"],
+            "@eventiva/databases.shared": ["../../../packages/databases/shared/src/index.ts"],
+            "@eventiva/databases.shared/*": ["../../../packages/databases/shared/src/*"]

Apply the same correction to tests/extensions/contact/tsconfig.json.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/databases/pg/tsconfig.json` around lines 2 - 13, The tsconfig path
mappings and extends are off by one directory: update the "extends" value and
every paths entry that currently uses "../../packages/..." to use
"../../../packages/..." so aliases like "@eventiva/core",
"@eventiva/databases.pg", and "@eventiva/databases.shared" resolve to the
monorepo packages instead of tests/packages; make the same change in the
companion tsconfig for the contact extension (fix the extends and all
"@eventiva/*" path entries to use one more ../).

tests/core/src/workflow/index.spec.ts-1-3 (1)

1-3: ⚠️ Potential issue | 🟠 Major

Import expect explicitly instead of relying on globals.

This file uses expect() without importing it (lines 7, 11, 17, 23, 29). With globals: false in the vitest configuration, these tests will fail at runtime.

Proposed fix

-import { describe, it } from 'vitest';
+import { describe, it, expect } from 'vitest';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/workflow/index.spec.ts` around lines 1 - 3, The tests call
expect() but Vitest globals are disabled; update the test imports to explicitly
import expect from 'vitest' (e.g., change the top import to "import { describe,
it, expect } from 'vitest';") so that the existing uses of expect in the spec
file (alongside describe and it) resolve correctly without relying on globals.

tests/core/src/schema/schema-encryption.spec.ts-8-12 (1)

8-12: ⚠️ Potential issue | 🟠 Major

Avoid Effect.gen when there is no yield (lint blocker).

These generator functions contain no yield, which trips require-yield/Biome correctness rules.

Suggested fix

-        it.effect('is a Schema', () =>
-            Effect.gen(function* () {
-                expect(encryptedString).toBeDefined();
-            })
-        );
+        it.effect('is a Schema', () =>
+            Effect.sync(() => {
+                expect(encryptedString).toBeDefined();
+            })
+        );
@@
-        it.effect('is an alias for encryptedString', () =>
-            Effect.gen(function* () {
-                expect(encryptedStringSchema).toBe(encryptedString);
-            })
-        );
+        it.effect('is an alias for encryptedString', () =>
+            Effect.sync(() => {
+                expect(encryptedStringSchema).toBe(encryptedString);
+            })
+        );

Also applies to: 37-41

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/schema/schema-encryption.spec.ts` around lines 8 - 12, The
tests use Effect.gen(function* () { ... }) with no yields which violates
require-yield; replace those with a synchronous Effect such as using Effect.sync
or Effect.succeed so the test returns an Effect without a generator. Concretely,
update the it.effect calls that wrap Effect.gen (referencing Effect.gen,
it.effect and the encryptedString assertions) to return Effect.sync(() => {
expect(encryptedString).toBeDefined(); }) (and similarly for the other
occurrence around the 37-41 block) so no generator is used.

tests/databases/pg/src/index.spec.ts-1-2 (1)

1-2: ⚠️ Potential issue | 🟠 Major

Import expect from Vitest explicitly.

The file uses expect() throughout but does not import it; Vitest globals are disabled in the project config (globals: false), making this code brittle and causing runtime failures.

Suggested fix

-import { describe, it } from 'vitest';
+import { describe, it, expect } from 'vitest';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/databases/pg/src/index.spec.ts` around lines 1 - 2, The tests use
expect() but Vitest globals are disabled; update the import line that currently
imports describe and it from 'vitest' to also import expect (e.g., add the
symbol expect to the import list), so tests reference the explicit expect export
rather than relying on globals; look for the import statement that includes
describe and it and add expect there.

tests/core/src/workflow/engine.spec.ts-39-43 (1)

39-43: ⚠️ Potential issue | 🟠 Major

Use Exit.isFailure for Exit values from Effect.exit(...).

The assertions use Effect.isFailure on Exit values. Effect.isFailure operates on Effect types and returns an Effect<boolean>, whereas Exit.isFailure is the correct type guard for Exit types, returning a boolean directly.

Suggested fix

 import { describe } from 'vitest';
 import * as Effect from 'effect/Effect';
 import * as Layer from 'effect/Layer';
+import * as Exit from 'effect/Exit';
@@
-                expect(Effect.isFailure(result)).toBe(true);
+                expect(Exit.isFailure(result)).toBe(true);
@@
-                expect(Effect.isFailure(result)).toBe(true);
+                expect(Exit.isFailure(result)).toBe(true);

This issue also occurs in other test files (tests/databases/pg/src/create-table.spec.ts:39–55, tests/core/src/security/integrity.spec.ts:45–46, tests/core/src/security/encryption.spec.ts:46–47, 62).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/workflow/engine.spec.ts` around lines 39 - 43, The test is
calling Effect.exit(...) which yields an Exit value but then uses
Effect.isFailure (an Effect-level predicate) in the assertion; replace the
predicate with Exit.isFailure so the assertion checks the Exit directly. Locate
the assertion that calls Effect.exit(...) and change
expect(Effect.isFailure(result)).toBe(true) to use Exit.isFailure(result)
instead; update all similar occurrences (e.g., other tests mentioned) where
Effect.isFailure is used on Exit values to use Exit.isFailure.

tests/databases/pg/vitest.config.ts-12-16 (1)

12-16: ⚠️ Potential issue | 🟠 Major

Coverage thresholds should enforce the stated exhaustive target.

Using 80 weakens the bootstrap goal and allows regressions to pass unnoticed. Set line/function/branch thresholds to 100 for this project.

Proposed fix

             thresholds: {
-                lines: 80,
-                functions: 80,
-                branches: 80,
+                lines: 100,
+                functions: 100,
+                branches: 100,
             },

Based on learnings: For test strategy and test creation decisions in Eventiva, consult tdd-and-test-creation.md and .cursor/rules/tdd-test-creation.mdc in the learnings documentation.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/databases/pg/vitest.config.ts` around lines 12 - 16, Update the vitest
coverage thresholds so they enforce full coverage: in the thresholds object
(properties lines, functions, branches) in vitest.config.ts, change the numeric
values from 80 to 100 so lines: 100, functions: 100, branches: 100 to enforce
the exhaustive target.

.devcontainer/test-runner/devcontainer.json-10-33 (1)

10-33: ⚠️ Potential issue | 🟠 Major

Avoid hardcoded DB credentials and default host port publication.

postgres/postgres credentials and 5432:5432 publication reduce security even for test environments and increase accidental collision risk.

Suggested hardening

-            "ports": ["5432:5432"],
+            "ports": ["127.0.0.1:5432:5432"],
             "environment": {
                 "POSTGRES_USER": "postgres",
-                "POSTGRES_PASSWORD": "postgres",
+                "POSTGRES_PASSWORD": "${localEnv:EVENTIVA_POSTGRES_PASSWORD}",
                 "POSTGRES_DB": "postgres"
             },
...
-        "PASSWORD": "postgres",
+        "PASSWORD": "${localEnv:EVENTIVA_POSTGRES_PASSWORD}",

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.devcontainer/test-runner/devcontainer.json around lines 10 - 33, Replace
hardcoded DB credentials and the host port publication: remove or stop
publishing "5432:5432" under "ports" and instead rely on internal container port
mapping or an ephemeral/random host port; remove hardcoded
"POSTGRES_USER"/"POSTGRES_PASSWORD"/"POSTGRES_DB" from "environment" and pull
them from secure inputs (e.g., devcontainer secrets, environment variables
injected at runtime, or .env) and ensure "HOST"/"PORT"/"USERNAME"/"PASSWORD" in
"remoteEnv" reference those secure values rather than literals; update
references in the devcontainer config so services use the secure vars (look for
"ports", "environment", "POSTGRES_USER", "POSTGRES_PASSWORD", "POSTGRES_DB", and
"remoteEnv").

tests/databases/pg/src/table-builder.spec.ts-6-105 (1)

6-105: ⚠️ Potential issue | 🟠 Major

Add Effect observability to all test callbacks.

This file contains 15+ test callbacks (describe and it) that lack Effect logging, metrics, or tracing. The coding guideline for **/*.ts files requires every function definition to implement Effect's observability features. Other test files in the repo (e.g. tests/core/src/cluster/config.spec.ts) follow this pattern using Effect.gen() within their callbacks.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/databases/pg/src/table-builder.spec.ts` around lines 6 - 105, The tests
currently use plain synchronous callbacks for describe/it; update every test
callback (all describe and it functions that reference testColumns,
createTableFinal, pgTable, status, statusEnum, etc.) to use Effect observability
by importing Effect and running the test body inside an Effect.gen block (i.e.,
wrap the existing callback body in Effect.gen and run the effect so assertions
execute within the Effect runtime), ensuring each test returns the Effect so the
test runner awaits it.

tests/platforms/default/project.json-5-5 (1)

5-5: ⚠️ Potential issue | 🟠 Major

Add the mandatory Layer tag in tags.

The manifest currently has type:platform but no layer:* tag, which breaks the repository’s tag schema requirements.

As per coding guidelines "**/project.json: All packages must have 2-3 tags ... a required Type tag ... [and] a required Layer tag ...".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/platforms/default/project.json` at line 5, The project manifest's tags
array (the "tags" key in project.json) is missing the required Layer tag; add an
appropriate layer tag (e.g., "layer:platform" or the correct layer name for this
package) alongside the existing "type:platform" and "scope:tests" entries so the
tags array contains both the required Type and Layer tags. Ensure the tag
follows the "layer:*" format and update the tags array in
tests/platforms/default/project.json accordingly.

tests/extensions/contact/project.json-5-5 (1)

5-5: ⚠️ Potential issue | 🟠 Major

Add the required Layer tag to this project.

Current tags include a Type tag but no Layer tag, so this manifest does not meet the project tagging contract.

As per coding guidelines "**/project.json: All packages must have 2-3 tags ... a required Type tag ... [and] a required Layer tag ...".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/extensions/contact/project.json` at line 5, The project manifest's
"tags" array is missing the required Layer tag; update the tags array in
tests/extensions/contact/project.json to include the appropriate Layer tag
(e.g., "layer:extension") alongside the existing "type:extension" and
"scope:tests" so the manifest meets the 2-3 tag contract.

tests/core/src/feature-flags/index.spec.ts-8-13 (1)

8-13: ⚠️ Potential issue | 🟠 Major

Replace Effect.gen with Effect.sync; the generator has no yield statements and will fail lint.

The generator body contains only assertions and no yield* expressions, which violates Biome's useYield rule (enabled via the "recommended" linting configuration). Use Effect.sync instead for synchronous effects that do not yield.

Suggested fix

         it.effect('exports FeatureFlags and related functions', () =>
-            Effect.gen(function* () {
+            Effect.sync(() => {
                 expect(FeatureFlagsIndex.FeatureFlags).toBeDefined();
                 expect(FeatureFlagsIndex.FeatureFlagsLive).toBeDefined();
                 expect(FeatureFlagsIndex.FeatureFlagsLiveConfigOnly).toBeDefined();
                 expect(FeatureFlagsIndex.FeatureFlagKeys).toBeDefined();
             })
         );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/feature-flags/index.spec.ts` around lines 8 - 13, The test
uses Effect.gen with a generator that contains no yields; replace the call to
Effect.gen(...) with Effect.sync(...) so the synchronous assertions inside the
effect (the expect checks against FeatureFlagsIndex.FeatureFlags,
FeatureFlagsIndex.FeatureFlagsLive,
FeatureFlagsIndex.FeatureFlagsLiveConfigOnly, and
FeatureFlagsIndex.FeatureFlagKeys) run without a generator and avoid the lint
useYield error; update the invocation that wraps those expect statements from
Effect.gen to Effect.sync and keep the inner function body unchanged.

tests/core/project.json-5-5 (1)

5-5: ⚠️ Potential issue | 🟠 Major

Add required Layer tag to all test projects.

All packages must have a required Layer tag (layer:backend, layer:frontend, or layer:shared) per module-boundaries.mdc. This applies to test projects as well. Currently, all six test project files (tests/core, tests/databases/pg, tests/databases/shared, tests/extensions/contact, tests/extensions/hello-world, and tests/platforms/default) are missing this required tag. Add the appropriate Layer tag to each project.json based on the corresponding main package's layer classification—typically layer:backend for test projects testing backend packages.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/project.json` at line 5, Each test project's project.json is
missing the required Layer tag in its "tags" array; update the "tags" array in
tests/core/project.json (and the other test project.json files listed) to
include the appropriate Layer tag (e.g., "layer:backend" for backend test
projects) so the tags array contains both the existing tags like "scope:tests"
and the new layer tag.

tests/core/src/runtime/run-runtime.spec.ts-15-21 (1)

15-21: ⚠️ Potential issue | 🟠 Major

Incorrect API usage: Effect.scoped does not accept a Layer.

Effect.scoped expects an Effect that requires Scope, not a Layer. To build a Layer into a scoped context, use Layer.build. Additionally, Effect.exit returns an Exit, not an Effect, so Effect.isEffect(result) will always be false.

🐛 Proposed fix

     describe('DevToolsLive', () => {
         it.effect('is a valid Layer', () =>
             Effect.gen(function* () {
                 expect(DevToolsLive).toBeDefined();
-                const result = yield* Effect.exit(Effect.scoped(DevToolsLive));
-                expect(Effect.isEffect(result)).toBe(true);
+                const result = yield* Effect.exit(Layer.build(DevToolsLive));
+                expect(Exit.isExit(result)).toBe(true);
             })
         );
     });

Note: You'll need to import Exit and Layer from effect:

-import { Effect } from 'effect';
+import { Effect, Exit, Layer } from 'effect';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/runtime/run-runtime.spec.ts` around lines 15 - 21, Replace the
incorrect use of Effect.scoped(DevToolsLive) with Layer.build(DevToolsLive) and
update the assertion to check the returned Exit rather than treating it as an
Effect: call Layer.build(DevToolsLive) where Effect.scoped was used, capture the
result from Effect.exit(...) (which is an Exit) and assert with
Exit.isExit(result) (or other Exit-check helpers) instead of Effect.isEffect;
also add necessary imports for Layer and Exit and keep the existing DevToolsLive
reference.

tests/core/src/runtime/run-runtime.spec.ts-24-33 (1)

24-33: ⚠️ Potential issue | 🟠 Major

Incorrect assertion: Effect.isEffect on an Exit value.

Effect.exit(bootstrapProgram) yields an Exit, not an Effect. The assertion Effect.isEffect(result) will always return false. The same issue appears in the runtimeOnlyProgram and defaultRuntimeProgram tests.

🐛 Proposed fix for all three program tests

     describe('bootstrapProgram', () => {
         it.effect('is a valid Effect', () =>
             Effect.gen(function* () {
                 expect(bootstrapProgram).toBeDefined();
+                expect(Effect.isEffect(bootstrapProgram)).toBe(true);
                 // May fail due to missing dependencies, but should be a valid Effect
                 const result = yield* Effect.exit(bootstrapProgram);
-                expect(Effect.isEffect(result)).toBe(true);
+                expect(Exit.isExit(result)).toBe(true);
             })
         );
     });

Apply similar changes to runtimeOnlyProgram (lines 35-44) and defaultRuntimeProgram (lines 46-55).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/runtime/run-runtime.spec.ts` around lines 24 - 33, The tests
call Effect.exit(...) which returns an Exit, so the assertion using
Effect.isEffect(result) is wrong; update the three tests (bootstrapProgram,
runtimeOnlyProgram, defaultRuntimeProgram) to assert that the returned value is
an Exit (e.g., use Exit.isExit(result) or the Exit API you have available) and,
if desired, additionally assert success/failure (e.g.,
Exit.isSuccess/Exit.isFailure) instead of checking Effect.isEffect. Locate the
assertions in the test blocks referencing bootstrapProgram, runtimeOnlyProgram
and defaultRuntimeProgram and replace the Effect.isEffect check with the
appropriate Exit checks for each.

tests/core/src/runtime/platform.spec.ts-20-24 (1)

20-24: ⚠️ Potential issue | 🟠 Major

API mismatch: createPlatformTemplate returns a Layer, not PlatformTemplateTwoPhase.

The test calls .getBootstrapLayer() and .getRuntimeLayer() on the result of createPlatformTemplate (lines 23–24, 100, 116), but the source code at packages/core/src/runtime/platform.ts:263 shows that createPlatformTemplate returns Layer.Layer<never, any, unknown>, which does not have these methods. These methods exist only on PlatformTemplateTwoPhase, returned by createPlatformTemplateTwoPhase.

Update the test to use createPlatformTemplateTwoPhase, or remove the assertions for these methods.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/runtime/platform.spec.ts` around lines 20 - 24, The test is
calling getBootstrapLayer and getRuntimeLayer on the result of
createPlatformTemplate, but createPlatformTemplate returns a Layer (which lacks
those methods); update the test to either call createPlatformTemplateTwoPhase
instead of createPlatformTemplate so the returned PlatformTemplateTwoPhase
exposes getBootstrapLayer and getRuntimeLayer, or remove the assertions that
reference getBootstrapLayer/getRuntimeLayer and only assert properties that
exist on the Layer returned by createPlatformTemplate; make the change where the
template variable is created and where those two method assertions occur.

tests/core/src/entity/entity-registry.spec.ts-26-27 (1)

26-27: ⚠️ Potential issue | 🟠 Major

Reset EntityRegistry state between tests to avoid order-coupled behaviour.

EntityRegistry is shared mutable global state. Registrations in one test can leak into others and create flaky outcomes.

Suggested isolation fix

-import { describe, it, expect } from '@effect/vitest';
+import { describe, it, expect, beforeEach } from '@effect/vitest';
@@
 describe('entity/entity-registry', () => {
+    beforeEach(() => {
+        (EntityRegistry.getAll() as Map<string, unknown>).clear();
+    });
+
     describe('EntityRegistry.get', () => {

Also applies to: 45-46, 57-58, 69-70, 84-85, 99-100

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/entity/entity-registry.spec.ts` around lines 26 - 27, Tests
register into the shared EntityRegistry (calls like
EntityRegistry.register('TestEntity', mockEntity)) but never reset it, causing
order-dependent flakes; fix by resetting the registry between tests — add a
beforeEach/afterEach in entity-registry.spec.ts that calls a reset helper (e.g.,
EntityRegistry.clear() or EntityRegistry.reset()) to remove prior registrations,
or if no reset API exists, call jest.resetModules() and re-import EntityRegistry
between tests so each test gets a fresh registry instance.

tests/core/src/entity/entity-registry.spec.ts-24-30 (1)

24-30: ⚠️ Potential issue | 🟠 Major

Replace Effect.gen generator expressions lacking yield* statements with Effect.sync for semantic correctness.

These Effect.gen(function* () { ... }) blocks contain no yield* statements, which misuse the Effect generator API. Where Effect.gen is designed for effectful computations that delegate to other Effects via yield*, these blocks perform only synchronous side effects. Use Effect.sync(() => { ... }) instead.

Suggested refactor pattern

-it.effect('returns registered entity', () =>
-    Effect.gen(function* () {
-        const mockEntity = { type: 'TestEntity', protocol: {} };
-        EntityRegistry.register('TestEntity' as any, mockEntity);
-
-        const entity = EntityRegistry.get('TestEntity' as any);
-        expect(entity).toBe(mockEntity);
-    })
-);
+it.effect('returns registered entity', () =>
+    Effect.sync(() => {
+        const mockEntity = { type: 'TestEntity', protocol: {} };
+        EntityRegistry.register('TestEntity' as any, mockEntity);
+
+        const entity = EntityRegistry.get('TestEntity' as any);
+        expect(entity).toBe(mockEntity);
+    })
+);

Also applies to lines: 36–39, 43–49, 55–61, 65–74, 80–91, 97–103

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/entity/entity-registry.spec.ts` around lines 24 - 30, The test
uses Effect.gen(function* () { ... }) without any yield* calls; replace these
generator-based Effect.gen blocks with Effect.sync(() => { ... }) for semantic
correctness. Locate the test cases that call Effect.gen (around the
EntityRegistry.register/get assertions) and change each to use Effect.sync with
the same body (preserving mockEntity, EntityRegistry.register('TestEntity',
mockEntity) and the subsequent EntityRegistry.get/assertion) and apply the same
replacement to the other listed blocks (the other Effect.gen usages) so all
synchronous test bodies use Effect.sync instead of Effect.gen.

tests/core/src/entity/entity-base.spec.ts-91-93 (1)

91-93: ⚠️ Potential issue | 🟠 Major

Remove the runtime expectation; EntityRpc is a type utility that cannot be tested at runtime.

The type annotation const _test: EntityRpc<any> = undefined as any; does not validate at runtime. Since EntityRpc<any> resolves to never, and the assigned value is undefined, the line expect(_test).toBeDefined() will fail. For compile-time-only type checking, either remove the runtime expectation or use a type-testing utility rather than a Vitest expectation.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/entity/entity-base.spec.ts` around lines 91 - 93, The test is
asserting a runtime expectation on a compile-time-only type: EntityRpc<any>
(assigned to _test) cannot be validated at runtime and causes the failing
expect(_test).toBeDefined(); remove the runtime assertion and either delete the
_test runtime declaration entirely or replace it with a compile-time type
assertion (e.g., a type-only check or a utility like ExpectType) so that
EntityRpc and the _test symbol are only used for compile-time validation.

tests/core/src/feature-flags/feature-flags.spec.ts-35-49 (1)

35-49: ⚠️ Potential issue | 🟠 Major

Harden env-var tests with guaranteed restoration (try/finally).

process.env mutations are not always restored on assertion failure, and POSTHOG_PROJECT_API_KEY is cleared but never restored. This can leak state across tests.

Suggested fix pattern

         it.effect('falls back to config when PostHog not configured', () =>
             Effect.gen(function* () {
-                const original = process.env.POSTHOG_API_KEY;
-                delete process.env.POSTHOG_API_KEY;
-                delete process.env.POSTHOG_PROJECT_API_KEY;
-
-                const flags = yield* Layer.build(FeatureFlagsLive());
-                const enabled = yield* flags.isEnabled(FeatureFlagKeys.OBSERVABILITY);
-
-                expect(enabled).toBe(true);
-
-                if (original !== undefined) {
-                    process.env.POSTHOG_API_KEY = original;
-                }
+                const originalApiKey = process.env.POSTHOG_API_KEY;
+                const originalProjectApiKey = process.env.POSTHOG_PROJECT_API_KEY;
+                try {
+                    delete process.env.POSTHOG_API_KEY;
+                    delete process.env.POSTHOG_PROJECT_API_KEY;
+
+                    const flags = yield* Layer.build(FeatureFlagsLive());
+                    const enabled = yield* flags.isEnabled(FeatureFlagKeys.OBSERVABILITY);
+                    expect(enabled).toBe(true);
+                } finally {
+                    if (originalApiKey !== undefined) process.env.POSTHOG_API_KEY = originalApiKey;
+                    else delete process.env.POSTHOG_API_KEY;
+
+                    if (originalProjectApiKey !== undefined) process.env.POSTHOG_PROJECT_API_KEY = originalProjectApiKey;
+                    else delete process.env.POSTHOG_PROJECT_API_KEY;
+                }
             })
         );

Also applies to: 51-67, 82-102, 114-128

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/feature-flags/feature-flags.spec.ts` around lines 35 - 49, The
tests (e.g., the it.effect block "returns true by default when env var not set"
that calls Layer.build(FeatureFlagsLiveConfigOnly()) and
flags.isEnabled(FeatureFlagKeys.OBSERVABILITY)) mutate process.env without
guaranteed restoration; wrap each test's env var setup and teardown in a
try/finally so originals are always restored (use temp variables for
EVENTIVA_FEATURE_OBSERVABILITY and POSTHOG_PROJECT_API_KEY), and apply the same
pattern to the other affected tests (the blocks around lines 51-67, 82-102,
114-128) to ensure no env leakage between tests.

tests/core/src/config/runtime-config.spec.ts-8-112 (1)

8-112: ⚠️ Potential issue | 🟠 Major

Prevent env-state leakage across tests.

These tests mutate process.env without guaranteed restoration. Please wrap mutations in try/finally (or a shared helper) so each case restores original values even when assertions fail.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/config/runtime-config.spec.ts` around lines 8 - 112, Tests
mutate process.env directly (in specs that call RuntimeConfigLive, Layer.build,
RuntimeConfigOptions) which can leak state between tests; capture the original
environment variables used (e.g., process.env.NODE_ENV,
EVENTIVA_INTEGRITY_NONCE, EVENTIVA_ENCRYPTION_KEY) at the start of each
it.effect, perform the mutations, and ensure you restore the originals in a
finally block (or use a shared helper) so the original values are reinstated
even if assertions fail.

tests/core/src/feature-flags/feature-flags.spec.ts-15-22 (1)

15-22: ⚠️ Potential issue | 🟠 Major

Convert Effect.gen to Effect.sync where there is no yield*.

These blocks violate the require-yield/useYield lint rule. The generator functions contain no yield* statements, so they should use Effect.sync instead.

Lines 15–22 and 147–151 are affected.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/core/src/feature-flags/feature-flags.spec.ts` around lines 15 - 22, The
tests use Effect.gen with generator functions that contain no yield* (violating
the require-yield/useYield lint rule); replace those calls with Effect.sync so
the blocks run synchronously—locate the test assertions wrapped in Effect.gen
(e.g., the block verifying FeatureFlagKeys constants like
FeatureFlagKeys.OBSERVABILITY, DEVTOOLS, CLUSTER, ENTITY_ENDPOINTS,
SCHEMA_STACK, EXTENSIONS and the other block around lines ~147–151) and change
Effect.gen(...) to Effect.sync(...) preserving the inner assertion function.

tests/extensions/hello-world/src/config.spec.ts-16-29 (1)

16-29: ⚠️ Potential issue | 🟠 Major

Always restore HELLO_WORLD_GREETING, even on failure.

If the service lookup or an assertion throws, the restore block is skipped and later tests inherit a mutated process.env. Wrap these mutations in try/finally (or an Effect finaliser) so cleanup is guaranteed.

Also applies to: 32-45

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/extensions/hello-world/src/config.spec.ts` around lines 16 - 29, The
test mutates process.env.HELLO_WORLD_GREETING but only restores it on the
success path; change the test using Effect.gen inside it.effect to guarantee
restore by wrapping the mutation and test in a try/finally (or use an Effect
finaliser) so the original value is always reset even if
Layer.build(HelloWorldConfigLayer) or the expect throws; apply the same pattern
to the other test block referenced (lines 32-45) that also mutates
HELLO_WORLD_GREETING.

tests/extensions/hello-world/project.json-5-5 (1)

5-5: ⚠️ Potential issue | 🟠 Major

Add the mandatory layer:* tag here.

scope:tests is outside the allowed tag set, and this manifest is missing the required layer:* tag entirely. As written, it cannot satisfy the repo's tag-based boundary rules.

As per coding guidelines, "All packages must have 2-3 tags in project.json: a required Type tag (type:core, type:database, type:extension, or type:platform), a required Layer tag (layer:backend, layer:frontend, or layer:shared), and optional Capability tags (capability:entities, capability:workflows, capability:ui)".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/extensions/hello-world/project.json` at line 5, The project manifest's
"tags" array in project.json uses an invalid tag "scope:tests" and is missing
the required layer tag; update the "tags" array (in
tests/extensions/hello-world/project.json) to include one of the required layer
tags (e.g., "layer:backend", "layer:frontend", or "layer:shared"), remove or
replace the invalid "scope:tests" tag, and ensure the array contains the
required type tag "type:extension" plus the newly added "layer:*" tag (and any
optional capability tags if needed) so the manifest conforms to the 2-3 tag
rule.

.devcontainer/test-runner/compose.yaml (2)

11-23: No volume for postgres data persistence.

The postgres service has no volume mount, so data will be lost when the container is removed. If this is intentional for ephemeral test environments, consider adding a brief comment to clarify. Otherwise, a named volume would preserve data across container recreations.

♻️ Optional: Add a named volume for data persistence

     healthcheck:
       test: ["CMD-SHELL", "pg_isready -U postgres"]
       interval: 5s
       timeout: 5s
       retries: 5
+    volumes:
+      - pgdata:/var/lib/postgresql/data
+
+volumes:
+  pgdata:

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.devcontainer/test-runner/compose.yaml around lines 11 - 23, The postgres
service in the compose snippet lacks a volume, so add a named volume to persist
DB files by updating the postgres service (service name "postgres") to include a
volumes entry that mounts a named volume (e.g., "pgdata") to the container data
directory (/var/lib/postgresql/data) and add a matching top-level volumes
declaration (e.g., "pgdata:") in the compose file; if ephemeral data is
intentional, instead add a clear comment next to the postgres service explaining
that no volume is by design.

---

19-21: Healthcheck uses hardcoded username, inconsistent with configurable POSTGRES_USER.

The healthcheck hardcodes -U postgres whilst the environment allows overriding POSTGRES_USER. If someone sets a different user, this inconsistency could cause confusion (though pg_isready will still work as it only checks server readiness).

♻️ Optional fix to use the configurable username

     healthcheck:
-      test: ["CMD-SHELL", "pg_isready -U postgres"]
+      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER:-postgres}"]
       interval: 5s

Note: The double $$ escapes the variable for Docker Compose so it's evaluated inside the container.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.devcontainer/test-runner/compose.yaml around lines 19 - 21, The healthcheck
currently hardcodes the PostgreSQL user with "-U postgres" causing inconsistency
with the configurable POSTGRES_USER; update the healthcheck test command
(healthcheck.test) to use the environment variable inside the container (e.g.,
replace the literal "postgres" with the escaped compose variable so the
container sees $POSTGRES_USER, using Docker Compose escaping like
"$$POSTGRES_USER") so the pg_isready invocation respects the POSTGRES_USER
setting.

.devcontainer/test-runner/compose.yaml (2)

14-14: Reduce Postgres host exposure by default in the test-runner container.

Line 14 publishes Postgres on all host interfaces. For this devcontainer, inter-service networking is already available, so consider either removing host publishing or binding to loopback only.

Safer default options

-    ports: ["5432:5432"]
+    ports: ["127.0.0.1:5432:5432"]

-    ports: ["5432:5432"]
+    # No host port required for app↔postgres traffic inside Compose network

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.devcontainer/test-runner/compose.yaml at line 14, The compose service
currently exposes Postgres to all host interfaces via the ports entry ports:
["5432:5432"]; either remove that ports mapping entirely (relying on internal
docker network) or change it to bind only to loopback (e.g., replace "5432:5432"
with "127.0.0.1:5432:5432") in the test-runner/container's service definition so
Postgres is not published on all host interfaces by default.

---

20-20: Make DB state reset explicit to keep tests deterministic.

Using a persistent named volume is convenient, but it can leak schema/data between runs in a test-runner workflow. Please document or script a reset path (down -v) and consider an ephemeral mode for CI.

Also applies to: 27-28

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.devcontainer/test-runner/compose.yaml at line 20, The compose file mounts a
persistent named volume "pgdata" which can leak state between test runs; update
the repo to make DB resets explicit by adding a documented scripted reset and an
ephemeral CI mode: add a short script or Makefile target (e.g.,
"scripts/reset-db.sh" or "make test-reset") that runs the compose teardown with
volume removal (docker compose down -v) and document this in the
devcontainer/README, and provide an alternate ephemeral service configuration
(replace the "pgdata:/var/lib/postgresql/data" mapping or add a separate CI
override that uses an anonymous volume or tmpfs for /var/lib/postgresql/data) so
CI runs use fresh DB state; apply the same change for the other occurrence(s)
around the lines referencing the same "pgdata" mapping (lines 27-28).

.github/workflows/tests-repo-pr-tdd.yml (3)

127-133: Path validation logic is sound but could benefit from documentation.

The regex patterns correctly constrain agent-generated files to expected locations. Consider adding a brief comment explaining the allowed path patterns for future maintainers:

Suggested documentation

                   invalid_paths=0
                   while IFS= read -r changed; do
                     if [ -z "${changed}" ]; then continue; fi
+                    # Allow: {core,databases/*,extensions/*/*,platforms/*}/src/**/*.spec.{ts,tsx,js,jsx}
                     if [[ "${changed}" =~ ^(core|databases/[^/]+|extensions/[^/]+/[^/]+|platforms/[^/]+)/src/.+\.spec\.[jt]sx?$ ]]; then continue; fi
+                    # Allow: {core,databases/*,extensions/*/*,platforms/*}/workflows/**/*.{yml,yaml}
                     if [[ "${changed}" =~ ^(core|databases/[^/]+|extensions/[^/]+/[^/]+|platforms/[^/]+)/workflows/.+\.(yml|yaml)$ ]]; then continue; fi
                     echo "Disallowed agent-generated path: ${changed}"
                     invalid_paths=1
                   done < agent-generated-files.txt

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/tests-repo-pr-tdd.yml around lines 127 - 133, Add a brief
inline comment above the loop that explains the allowed agent-generated path
patterns being validated (the two regex checks) and the intent of
agent-generated-files.txt and invalid_paths; specifically describe that the
first regex permits spec files under core, databases/<pkg>,
extensions/<ext>/<pkg>, or platforms/<pkg> in src with .spec.{js,jsx,ts,tsx}
extensions and the second permits workflow YAML files under workflows in those
same package paths, so future maintainers understand why other paths are
rejected.

---

299-307: Consider removing .placeholder coverage path if it's scaffolding remnant.

The glob pattern includes tests/.placeholder/coverage/coverage-summary.json. If this is a remnant from test scaffolding that's been removed, consider cleaning it up. If it's intentional for handling edge cases, a comment would clarify its purpose.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/tests-repo-pr-tdd.yml around lines 299 - 307, The
coverage_files array currently includes a specific pattern
"tests/.placeholder/coverage/coverage-summary.json" which looks like
scaffolding; remove that entry from the coverage_files assignment (the
coverage_files variable) if it is no longer needed, or if retained intentionally
add an inline comment explaining why the placeholder path must be included
(e.g., to prevent an empty glob result in certain CI scenarios) so future
reviewers understand its purpose; update the assignment where coverage_files is
defined to either omit the placeholder path or include the explanatory comment
next to that pattern.

---

119-121: Consider increasing the agent timeout for large codebases.

The 180-second timeout may be insufficient for comprehensive test generation across all packages in a monorepo. If the agent times out frequently, consider increasing to 300-600 seconds, or making it configurable via workflow input.

The current fallback behaviour ("continuing with bootstrap-generated tests") is appropriate for graceful degradation.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/tests-repo-pr-tdd.yml around lines 119 - 121, Increase the
agent timeout used in the command "timeout 180 agent -p \"$(cat
\"${prompt_file}\")\" --force --model auto --workspace tests" to a larger
default (e.g., 300–600s) or make it configurable via a workflow
input/environment variable (e.g., AGENT_TIMEOUT) so the "timeout 180" token is
replaced by a configurable value; ensure the prompt_file usage and fallback
message remain unchanged.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes