feat/discovery

'i' flag in publicIdRegex makes prefix case-insensitive — 'CFJ_xxx' matches

packages/shared-kernel/src/types/ids.ts:78

The 'i' flag is applied to the full regex `^${prefix}_${ULID_BODY_PATTERN}$`. Since the prefix is lowercase (e.g. 'cfj'), 'i' causes 'CFJ_...', 'Cfj_...' etc. to pass wire validation. The docstring says this flag is for accepting lowercase ULID bodies (backward compat), but it silently widens the prefix contract too. Fix: include lowercase chars explicitly in ULID_BODY_PATTERN (`[0-9A-HJKMNPa-hjkmnptv-zTV-Z]{26}`) and drop the 'i' flag, or document that uppercase-prefix tolerance is intentional.

isValidPublicId() accepts non-registry prefixes — diverges from publicIdRegex

packages/shared-kernel/src/types/ids.ts:125

isValidPublicId() uses /^[a-z]{3}_[0-9A-HJKMNP-TV-Z]{26}$/ — accepts any 3-char lowercase prefix, including 'aaa_...'. This is intentional for a format-only check, but it diverges from publicIdRegex which enforces a specific registry prefix. The function's JSDoc should explicitly state it's a format check only (not a registry membership check) to prevent misuse as an authorization guard.

No injection risk — publicIdRegex inputs are compile-time constants

packages/shared-kernel/src/types/ids.ts:78

prefix parameter is typed as PublicIdPrefix (union of literal strings). No user-controlled input flows into the RegExp constructor. Safe.

Stale 'cjb_' JSDoc in event-schemas.ts — contradicts canonical registry

services/utility/bills/cfe/src/domain/event-schemas.ts:48

JSDoc on JobCreatedEventDataSchema.publicId still says 'cjb_...' as the CfeJob prefix. The canonical value is now 'cfj' in both the registry and the DB schema. Misleads any reader auditing the id registry and will cause confusion when event-schemas are eventually tightened to use publicIdRegex.

JSDoc claims 'retired copies re-export this constant' — unverified by diff

packages/shared-kernel/src/types/ids.ts:14

The new JSDoc states domains/utility/src/schema/base.ts enum and packages/api/src/schemas/common.schemas.ts map 're-export this constant'. If those files still carry independent values (even if identical), the SSOT claim is aspirational rather than structural. The diff does not show those files being updated to delegate to PublicIdPrefix.

one-api.md reference in JSDoc lacks explicit path

packages/shared-kernel/src/types/ids.ts:10

The JSDoc references 'one-api.md' without a path. The same PR's change to database/schema/index.ts shows the pattern: '.claude/rules/contracts-read-model.md'. Should be '.claude/rules/one-api.md' for consistency.

Comment update in database/schema/index.ts is correct

packages/database/src/schema/index.ts:119

Updating the ADR path to .claude/rules/contracts-read-model.md aligns with the Tier 5 retirement rule in CLAUDE.md. No issue.

publicIdRegex() has no unit tests

packages/shared-kernel/src/types/ids.ts:72

New exported wire-validation utility with non-trivial behavior (flag handling, ULID body composition, case-sensitivity toggle). Already consumed by job.public-schemas.ts for production wire validation. Missing tests: correct prefix match, wrong prefix rejection, 'i' flag lowercase acceptance, invalid format rejection. A bug here silently breaks schema enforcement across all public-API schemas.

~6 test files and seed data carry stale 'cjb_' prefix strings

domains/utility/src/cfe-job/__tests__/cfe-job.decisions.test.ts:56

Affected files: cfe-job.decisions.test.ts (L56,78,162,171), credit-metering.decisions.test.ts (L97,105), event-schemas.test.ts (multiple), seed-utility-demo.ts (L1352,1363,1396). Tests pass today because decision functions treat IDs as opaque strings (no regex validation). But the test data is inconsistent with the enforced wire schema (cfj_*), and any future validation tightening will cause silent failures.

Seed data 'cjb_*' IDs may break integration tests validating response schemas

packages/database/src/seed-utility-demo.ts:1352

seed-utility-demo.ts seeds cfe_jobs with publicId = 'cjb_001_test_queued' etc. PublicJobIdSchema now enforces cfj_* via publicIdRegex. Integration tests that seed from this file and inspect job IDs in API responses risk failing schema validation or asserting on wrong prefix values.

No regression test pinning PublicIdPrefix.CfeJob === 'cfj'

packages/shared-kernel/src/types/ids.ts:56

The CfeJob prefix was corrected from 'cjb' to 'cfj' with a comment citing production data. No snapshot or assertion test pins this value. An accidental revert would propagate to wire validation (PublicJobIdSchema) without a test-layer catch.

'i' flag footgun — callers must know to pass it for wire schemas

packages/shared-kernel/src/types/ids.ts:64

The docstring says 'public-v1 wire schemas pass i' but there's no named constant or wrapper to enforce this. A caller that forgets the flag silently gets a stricter schema. Consider exporting a PUBLIC_V1_REGEX_FLAGS = 'i' constant or two wrappers (publicIdRegexStrict / publicIdRegexWire) to make the pit of success explicit.

MonitoringSubscription prefix 'sub' is ambiguous across domains

packages/shared-kernel/src/types/ids.ts:54

'sub' for MonitoringSubscription could collide conceptually with Stripe subscriptions or other subscription entities. 'mns' or 'mons' would be more domain-specific. No current collision in the registry.