feat(audit): expand multi-tenant dimension to 100% standard coverage#328
Merged
jeffersonrodrigues92 merged 5 commits intomainfrom Apr 14, 2026
Merged
Conversation
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughUpdated the production-readiness-audit skill's Dimension 33 prompt to enforce canonical multi-tenant patterns, including stricter environment variable validation, lib-commons v4 integration requirements, tenant-routed database access, Redis/S3/RabbitMQ key prefixing, backward-compatibility testing, and a new HARD GATES vs warnings framework for validation reporting. Changes
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@default/skills/production-readiness-audit/SKILL.md`:
- Around line 3447-3448: The non-canonical file detection currently uses overly
broad glob patterns '**/tenant/' and '**/multitenancy/' which flag benign files
(docs, examples, tests) and causes HARD GATE failures; update the rule to narrow
the patterns to only match canonical source locations (e.g.,
'**/src/**/tenant/**', '**/src/**/multitenancy/**' or explicit
resolver/middleware directories) and/or add exclusions for common non-production
folders ('**/test/**', '**/docs/**', '**/examples/**'), and change the
enforcement from HARD GATE to a WARNING for these patterns so that
non-production files do not yield score=0; apply the same adjustments where the
patterns are repeated (the second occurrence mirrored at the later block).
- Around line 3590-3591: The auditor currently validates presence of the listed
canonical env vars but omits APPLICATION_NAME; update the env-var validation
logic and documentation to include APPLICATION_NAME as a required canonical
variable (e.g., extend the canonical set that currently lists MULTI_TENANT_*
items to also include APPLICATION_NAME), ensure the check that enforces "All X
canonical env var names present" increments and enforces the new required count,
and update any rejection rules that flag non-canonical names so they still apply
while allowing APPLICATION_NAME as valid for Tenant Manager settings resolution.
- Around line 3584-3585: The HARD GATE text that mandates "organization_id +
ledger_id" on all queries is too rigid; update the SKILL.md entries that list
the HARD GATEs (the lines referencing organization_id + ledger_id and
TenantMiddleware/MultiPoolMiddleware) to require that queries include tenant
scoping semantics instead of a specific key pair, and state that tenant
isolation must be validated via the canonical tenant resolution pattern
(referencing tenant-manager/core resolution) so modules may use their
module-specific scoping keys as long as TenantMiddleware or MultiPoolMiddleware
injects and enforces the tenant context.
- Around line 3633-3634: The conditional "only if service has targetServices" is
underspecified—update the SKILL.md section for "M2M credential provider" to
define a deterministic activation rule: require either (a) the service manifest
contains a non-empty targetServices array, or (b) an explicit boolean
flag/annotation (e.g., enableM2MCredentials=true) in service metadata, and
include the precedence rule if both exist; add a one-line detection algorithm
and an example manifest showing the field/annotation and expected behavior so
automated audits can consistently decide whether to enable the two-level cache
(L1 sync.Map 30s → L2 Redis → AWS Secrets Manager).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 6a643003-0a39-456c-a91b-ae904188b44b
📒 Files selected for processing (1)
default/skills/production-readiness-audit/SKILL.md
jeffersonrodrigues92
force-pushed
the
feat/production-readiness-full-multi-tenant-coverage
branch
2 times, most recently
from
b6d0320 to
63cea87
Compare
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
default/skills/production-readiness-audit/SKILL.md (1)
3668-3672:⚠️ Potential issue | 🟠 MajorM2M activation fallback condition is logically incomplete
The rule says checks apply only when BOTH conditions are met, but then says “If neither condition is met, mark N/A.”
This leaves the one-condition-met case undefined and can cause inconsistent scoring.Suggested fix
-If neither condition is met, mark M2M section as N/A and do not deduct score. +If either condition is not met, mark M2M section as N/A and do not deduct score.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@default/skills/production-readiness-audit/SKILL.md` around lines 3668 - 3672, The activation rule for M2M checks is ambiguous: it currently requires BOTH (a) targetServices declared and (b) outbound credential provider usage, but only specifies behavior when NEITHER is met; update the logic to explicitly handle the case when exactly one condition is met. Modify the text around "Activation rule" and the scoring decision for the M2M section so it states: if BOTH conditions are true run checks; if NEITHER condition is true mark M2M N/A; if ONLY ONE condition is true mark M2M as "Requires manual review" (or equivalent) and do not auto-deduct score, and mention the concrete signals to look for (e.g., typed config/DTO field targetServices and code usages like secretsmanager.GetM2MCredentials or m2m.NewM2MCredentialProvider) so reviewers know how to evaluate the one-condition case.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@default/skills/production-readiness-audit/SKILL.md`:
- Around line 3502-3505: The comment points out ambiguous references to
GetKeyFromContext: update all occurrences to the canonical, fully-qualified
symbol valkey.GetKeyFromContext (both in the GOOD examples and in the
deprecated/banned list) so the rule engine can distinguish the allowed call from
the deprecated/unqualified name; search for unqualified GetKeyFromContext usage
(e.g., the lines that set key := GetKeyFromContext(ctx, ...) and prefixedKey :=
GetKeyFromContext(ctx, transactionKey)) and replace them with
valkey.GetKeyFromContext, and update the deprecated list entry that forbids
GetKeyFromContext to explicitly forbid the unqualified symbol or adjust it to
reference a different unique identifier so valkey.GetKeyFromContext remains
compliant.
- Around line 3616-3618: The rule under "Canonical Environment Variables"
incorrectly requires all 9 MULTI_TENANT_* vars unconditionally; update the check
so it only mandates presence of APPLICATION_NAME plus the full set of
MULTI_TENANT_* vars when MULTI_TENANT_ENABLED is true (i.e., treat
MULTI_TENANT_ENABLED as the toggle), and when MULTI_TENANT_ENABLED is false
allow omission of MULTI_TENANT_* vars and do not generate HIGH findings for
their absence or for absence of a multi-tenant config; also suppress
non-canonical-name violations (e.g., TENANT_MANAGER_URL, TENANT_ENABLED) when
MULTI_TENANT_ENABLED=false while keeping the canonical-name enforcement active
when it is true.
- Around line 3609-3615: The "WARNING — not HARD GATE" item currently lives
inside the "HARD GATES (Score = 0 if any fails)" block which weakens semantics;
move that bullet out of the HARD GATES list (or convert it into a separate
"WARNINGS" or "NOTES" section) so the "HARD GATES (Score = 0 if any fails)"
header contains only mandatory hard gate items; locate the text by searching for
the header string "HARD GATES (Score = 0 if any fails)" and the bullet that
begins "5. (WARNING — not HARD GATE) Non-canonical source implementation files
detected" and update the document structure accordingly to keep scoring
deterministic.
---
Duplicate comments:
In `@default/skills/production-readiness-audit/SKILL.md`:
- Around line 3668-3672: The activation rule for M2M checks is ambiguous: it
currently requires BOTH (a) targetServices declared and (b) outbound credential
provider usage, but only specifies behavior when NEITHER is met; update the
logic to explicitly handle the case when exactly one condition is met. Modify
the text around "Activation rule" and the scoring decision for the M2M section
so it states: if BOTH conditions are true run checks; if NEITHER condition is
true mark M2M N/A; if ONLY ONE condition is true mark M2M as "Requires manual
review" (or equivalent) and do not auto-deduct score, and mention the concrete
signals to look for (e.g., typed config/DTO field targetServices and code usages
like secretsmanager.GetM2MCredentials or m2m.NewM2MCredentialProvider) so
reviewers know how to evaluate the one-condition case.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 9fe25261-bbf6-4f89-8b48-8445510e448e
📒 Files selected for processing (1)
default/skills/production-readiness-audit/SKILL.md
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (3)
default/skills/production-readiness-audit/SKILL.md (3)
3595-3602:⚠️ Potential issue | 🟠 MajorDisambiguate deprecated symbol names to avoid false non-compliance.
The deprecated list still bans unqualified
GetKeyFromContext, which conflicts with the canonicalvalkey.GetKeyFromContextexample and can misclassify valid code.Suggested clarification
-// GetKeyFromContext, GetPGConnectionFromContext, GetPGConnectionContext, +// Unqualified GetKeyFromContext (without package qualification), GetPGConnectionFromContext, GetPGConnectionContext, +// NOTE: valkey.GetKeyFromContext is canonical and MUST remain compliant.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@default/skills/production-readiness-audit/SKILL.md` around lines 3595 - 3602, The deprecated-symbols list is too generic and causes false positives for qualified usages (e.g., valkey.GetKeyFromContext); update the banned-symbols to use fully-qualified names (packageName.SymbolName) for entries like GetKeyFromContext, WithPostgresManager, WithMongoManager, GetMongoFromContext, GetPGConnectionFromContext, ResolvePostgres, ResolveMongo, ResolveModuleDB, SetTenantIDInContext, GetPostgresForTenant, GetMongoForTenant, ContextWithPGConnection, ContextWithMongo, ContextWithModulePGConnection, GetModulePostgresForTenant, MultiPoolMiddleware, DualPoolMiddleware, SettingsWatcher, NewSettingsWatcher so the rule only matches truly deprecated imports and not valid qualified references.
3607-3613:⚠️ Potential issue | 🟠 MajorKeep HARD GATE block semantically strict.
Line 3612 introduces a warning item inside the HARD GATES section, which makes score=0 logic ambiguous for implementers.
Suggested structure fix
HARD GATES (Score = 0 if any fails): ... -5. (WARNING — not HARD GATE) Non-canonical source implementation files detected: ... +5. (HARD GATE) <hard-gate item only> + +Warnings (do not force score=0): +W1. Non-canonical source implementation files detected: ...🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@default/skills/production-readiness-audit/SKILL.md` around lines 3607 - 3613, The HARD GATES block currently mixes a non-fatal warning item ("5. (WARNING — not HARD GATE) Non-canonical source implementation files...") into a section meant to be strictly fatal; remove or move that item out of the "HARD GATES" list and place it under a separate "WARNINGS" or "NOTES" section so the HARD GATES (items 1-4) remain semantically strict and unambiguous for score=0 logic; update the SKILL.md HARD GATES header and ensure references to the warning are relocated (the explicit text starting with "Non-canonical source implementation files..." is the content to move) while keeping items 1-4 intact.
3615-3617:⚠️ Potential issue | 🟠 MajorResolve env-var rule contradiction for single-tenant mode.
Line 3615 requires all 9 canonical vars unconditionally, but Line 3647 states single-tenant mode works without
MULTI_TENANT_*vars. These rules currently conflict.Suggested wording fix
-6. All 9 canonical env var names present with exact names: ... +6. When MULTI_TENANT_ENABLED=true, all 9 canonical env var names are present with exact names: ...-24. Service works with MULTI_TENANT_ENABLED=false (default) — no MULTI_TENANT_* vars required +24. Service works with MULTI_TENANT_ENABLED=false (default) — MULTI_TENANT_* vars are optional and absence is non-failingAlso applies to: 3647-3649
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@default/skills/production-readiness-audit/SKILL.md` around lines 3615 - 3617, The rules conflict because item requiring all nine canonical env vars (APPLICATION_NAME, MULTI_TENANT_ENABLED, MULTI_TENANT_URL, MULTI_TENANT_ENVIRONMENT, MULTI_TENANT_MAX_TENANT_POOLS, MULTI_TENANT_IDLE_TIMEOUT_SEC, MULTI_TENANT_CIRCUIT_BREAKER_THRESHOLD, MULTI_TENANT_CIRCUIT_BREAKER_TIMEOUT_SEC, MULTI_TENANT_SERVICE_API_KEY) is unconditional while another statement allows single-tenant deployments without MULTI_TENANT_* vars; update the wording so APPLICATION_NAME is required unconditionally and the MULTI_TENANT_* variables are required only when MULTI_TENANT_ENABLED is true (or when operating in multi-tenant mode), and adjust the examples/validation text to prohibit non-canonical names (e.g., TENANT_MANAGER_URL, TENANT_ENABLED) only in multi-tenant configurations.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@default/skills/production-readiness-audit/SKILL.md`:
- Around line 3595-3602: The deprecated-symbols list is too generic and causes
false positives for qualified usages (e.g., valkey.GetKeyFromContext); update
the banned-symbols to use fully-qualified names (packageName.SymbolName) for
entries like GetKeyFromContext, WithPostgresManager, WithMongoManager,
GetMongoFromContext, GetPGConnectionFromContext, ResolvePostgres, ResolveMongo,
ResolveModuleDB, SetTenantIDInContext, GetPostgresForTenant, GetMongoForTenant,
ContextWithPGConnection, ContextWithMongo, ContextWithModulePGConnection,
GetModulePostgresForTenant, MultiPoolMiddleware, DualPoolMiddleware,
SettingsWatcher, NewSettingsWatcher so the rule only matches truly deprecated
imports and not valid qualified references.
- Around line 3607-3613: The HARD GATES block currently mixes a non-fatal
warning item ("5. (WARNING — not HARD GATE) Non-canonical source implementation
files...") into a section meant to be strictly fatal; remove or move that item
out of the "HARD GATES" list and place it under a separate "WARNINGS" or "NOTES"
section so the HARD GATES (items 1-4) remain semantically strict and unambiguous
for score=0 logic; update the SKILL.md HARD GATES header and ensure references
to the warning are relocated (the explicit text starting with "Non-canonical
source implementation files..." is the content to move) while keeping items 1-4
intact.
- Around line 3615-3617: The rules conflict because item requiring all nine
canonical env vars (APPLICATION_NAME, MULTI_TENANT_ENABLED, MULTI_TENANT_URL,
MULTI_TENANT_ENVIRONMENT, MULTI_TENANT_MAX_TENANT_POOLS,
MULTI_TENANT_IDLE_TIMEOUT_SEC, MULTI_TENANT_CIRCUIT_BREAKER_THRESHOLD,
MULTI_TENANT_CIRCUIT_BREAKER_TIMEOUT_SEC, MULTI_TENANT_SERVICE_API_KEY) is
unconditional while another statement allows single-tenant deployments without
MULTI_TENANT_* vars; update the wording so APPLICATION_NAME is required
unconditionally and the MULTI_TENANT_* variables are required only when
MULTI_TENANT_ENABLED is true (or when operating in multi-tenant mode), and
adjust the examples/validation text to prohibit non-canonical names (e.g.,
TENANT_MANAGER_URL, TENANT_ENABLED) only in multi-tenant configurations.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 607872ee-d2ae-4fc0-9e94-81e951f9f4d2
📒 Files selected for processing (1)
default/skills/production-readiness-audit/SKILL.md
jeffersonrodrigues92
force-pushed
the
feat/production-readiness-full-multi-tenant-coverage
branch
from
63cea87 to
ad8c695
Compare
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
default/skills/production-readiness-audit/SKILL.md (2)
3613-3619:⚠️ Potential issue | 🟠 MajorMove WARNING out of the HARD GATES block to keep scoring deterministic.
The item
5. (WARNING — not HARD GATE)is currently nested underHARD GATES (Score = 0 if any fails), which makes gate semantics ambiguous for implementers.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@default/skills/production-readiness-audit/SKILL.md` around lines 3613 - 3619, The "WARNING — not HARD GATE" line (item 5) is incorrectly placed under the "HARD GATES (Score = 0 if any fails)" block, which makes gate semantics ambiguous; move the entire item 5 out of the HARD GATES list and place it in a separate "WARNINGS" or "NOT HARD GATES" section after the HARD GATES block so that the HARD GATES header and items 1–4 remain strictly deterministic and scoring remains unambiguous.
3621-3622:⚠️ Potential issue | 🟠 MajorFix env-var rule contradictions and canonical-count mismatch.
This section currently conflicts with itself: Line 3621 requires all canonical variables unconditionally, while Line 3655 states single-tenant mode must work without
MULTI_TENANT_*vars. Also, the “All 14 canonical env var names” count does not match the variables listed.Also applies to: 3655-3656
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@default/skills/production-readiness-audit/SKILL.md` around lines 3621 - 3622, The env-var rules conflict and the canonical count is wrong: update the canonical list to exactly match the variables enumerated (or adjust the enumeration to match the intended 14 names) and correct the numeric count, and change the unconditional requirement for "all canonical variables" to be conditional (require the full set of MULTI_TENANT_* vars only when multi-tenant mode is enabled) while keeping APPLICATION_NAME required always; also clarify that single-tenant mode must work without any MULTI_TENANT_* vars and explicitly forbid non-canonical names such as TENANT_MANAGER_URL, TENANT_ENABLED, and MULTI_TENANT_ENVIRONMENT to avoid contradictions.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@default/skills/production-readiness-audit/SKILL.md`:
- Around line 3677-3680: The activation wording is wrong: currently it skips M2M
only when "neither" condition is met which still activates checks when one
condition is missing; update the text and any related logic to state that M2M
checks apply ONLY when BOTH (a) `targetServices` is non-empty and (b) outbound
credential provider usage (e.g., `secretsmanager.GetM2MCredentials`,
`m2m.NewM2MCredentialProvider`) is detected; change the skip/fallback to "if
either condition is missing, mark M2M as N/A and do not deduct score" so the
rule clearly requires both conditions before activating M2M checks.
---
Duplicate comments:
In `@default/skills/production-readiness-audit/SKILL.md`:
- Around line 3613-3619: The "WARNING — not HARD GATE" line (item 5) is
incorrectly placed under the "HARD GATES (Score = 0 if any fails)" block, which
makes gate semantics ambiguous; move the entire item 5 out of the HARD GATES
list and place it in a separate "WARNINGS" or "NOT HARD GATES" section after the
HARD GATES block so that the HARD GATES header and items 1–4 remain strictly
deterministic and scoring remains unambiguous.
- Around line 3621-3622: The env-var rules conflict and the canonical count is
wrong: update the canonical list to exactly match the variables enumerated (or
adjust the enumeration to match the intended 14 names) and correct the numeric
count, and change the unconditional requirement for "all canonical variables" to
be conditional (require the full set of MULTI_TENANT_* vars only when
multi-tenant mode is enabled) while keeping APPLICATION_NAME required always;
also clarify that single-tenant mode must work without any MULTI_TENANT_* vars
and explicitly forbid non-canonical names such as TENANT_MANAGER_URL,
TENANT_ENABLED, and MULTI_TENANT_ENVIRONMENT to avoid contradictions.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: bf2d1fe2-961c-439a-a451-b32036ebb4ff
📒 Files selected for processing (1)
default/skills/production-readiness-audit/SKILL.md
jeffersonrodrigues92
force-pushed
the
feat/production-readiness-full-multi-tenant-coverage
branch
from
ad8c695 to
efd4ea0
Compare
Agent 33 (Multi-Tenant Patterns Auditor) was only covering ~60% of the canonical multi-tenant model defined in multi-tenant.md. This expands coverage from 9 checks to 34 checks, aligned with every requirement in the standard. New HARD GATES: non-canonical file detection, lib-commons v4 version verification. New CRITICAL checks: auth-before-tenant route ordering, global middleware detection. New HIGH checks: canonical env var names, circuit breaker, service API key, backward compatibility test, RabbitMQ vhost isolation, M2M credential security. New conditional M2M section (checks 30-34) for services with targetServices. Generated-by: Claude AI-Model: claude-opus-4-6
Resolve merge conflicts with main and address all review findings from gap analysis against multi-tenant.md: - Fix env var count: 9 → 14 (add REDIS_HOST/PORT/PASSWORD/TLS, TIMEOUT, CACHE_TTL_SEC, CONNECTIONS_CHECK_INTERVAL_SEC) - Remove invented MULTI_TENANT_ENVIRONMENT (not in standard) - Fix API names: valkey.GetKeyFromContext → valkey.GetKeyContext, s3.GetObjectStorageKeyForTenant → s3.GetS3KeyStorageContext - Fix metrics: remove invented tenant_connection_pool_size and tenant_config_cache_hits, add tenant_connection_errors_total (4 total) - Add *TenantSuspendedError → 403 to sentinel error mapping - Add event wiring checks: NewTenantPubSubRedisClient, NewTenantEventListener, TenantLoader.SetOnTenantLoaded - Add WithConnectionsCheckInterval check for pgManager - Add middleware=nil when MT disabled check - Remove organization_id/ledger_id entity scoping (domain concern, not multi-tenant isolation) - Downgrade non-canonical file detection from HARD GATE to WARNING - Total checks: 34 → 44 Generated-by: Claude AI-Model: claude-opus-4-6
jeffersonrodrigues92
force-pushed
the
feat/production-readiness-full-multi-tenant-coverage
branch
from
efd4ea0 to
aca4fd6
Compare
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (3)
default/skills/production-readiness-audit/SKILL.md (3)
3677-3680:⚠️ Potential issue | 🟠 MajorFix M2M activation fallback logic (
neithershould beeither missing).Activation requires BOTH conditions (a) and (b), but Line 3680 says skip only when “neither” is met. That incorrectly activates M2M checks when only one prerequisite is present.
Suggested fix
-If neither condition is met, mark M2M section as N/A and do not deduct score. +If either condition is missing, mark M2M section as N/A and do not deduct score.
3613-3619:⚠️ Potential issue | 🟠 MajorMove warning-only checks out of the HARD GATE list.
Line 3618 places a warning item inside
HARD GATES (Score = 0 if any fails), which makes scoring semantics ambiguous for implementers.Suggested fix
HARD GATES (Score = 0 if any fails): ... -5. (WARNING — not HARD GATE) Non-canonical source implementation files detected: ... +5. (HARD GATE) {hard-gate-only rule} + +Warnings (do not force score=0): +W1. Non-canonical source implementation files detected: custom tenant resolvers, manual pool managers, or wrapper middleware in source paths (internal/, pkg/, cmd/) outside canonical lib-commons integration paths. Excludes docs, tests, fixtures, vendored code.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@default/skills/production-readiness-audit/SKILL.md` around lines 3613 - 3619, The HARD GATES list in SKILL.md incorrectly includes a warning-only item: remove the line/item starting with "5. (WARNING — not HARD GATE) Non-canonical source implementation files detected: custom tenant resolvers, manual pool managers, or wrapper middleware..." from the HARD GATES block and place it under a separate WARNINGS or NOTES section (or a distinct list titled "Warnings" below the HARD GATES heading); update surrounding numbering/labels so HARD GATES remains only hard-fail items and ensure the warning is clearly marked as non-fatal and not scored as 0.
3620-3622:⚠️ Potential issue | 🟠 MajorResolve env-var requirement contradiction between multi-tenant and single-tenant modes.
Line 3621 currently mandates the full canonical set, but Line 3655 states single-tenant mode must work without
MULTI_TENANT_*vars. This produces false positives forMULTI_TENANT_ENABLED=falseservices.Suggested fix
-6. All 14 canonical env var names present with exact names: ... +6. When MULTI_TENANT_ENABLED=true, all canonical env var names are present with exact names: ... + When MULTI_TENANT_ENABLED=false, MULTI_TENANT_* vars are optional and must not be scored as missing.Also applies to: 3655-3656
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@default/skills/production-readiness-audit/SKILL.md` around lines 3620 - 3622, The doc currently requires the full canonical MULTI_TENANT_* env var set unconditionally, which conflicts with the later statement that single-tenant mode must work without those vars; update the policy language and any validation logic to make the canonical MULTI_TENANT_* requirements conditional on MULTI_TENANT_ENABLED=true: if MULTI_TENANT_ENABLED is true require the full canonical list (APPLICATION_NAME plus all MULTI_TENANT_* names listed), and if false require only APPLICATION_NAME (and still forbid non-canonical tenant-related names like TENANT_MANAGER_URL, TENANT_ENABLED, MULTI_TENANT_ENVIRONMENT); also adjust any automated checks to skip flagging missing MULTI_TENANT_* vars when MULTI_TENANT_ENABLED=false.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@default/skills/production-readiness-audit/SKILL.md`:
- Around line 3461-3476: The header stating "14 MANDATORY — APPLICATION_NAME +
13 MULTI_TENANT_*" is inconsistent with the enumerated list (which contains 15
entries including ApplicationName and 14 MultiTenant_* names such as
MultiTenantEnabled, MultiTenantURL, MultiTenantRedisHost, MultiTenantRedisPort,
MultiTenantRedisPassword, MultiTenantRedisTLS, MultiTenantMaxTenantPools,
MultiTenantIdleTimeoutSec, MultiTenantTimeout,
MultiTenantCircuitBreakerThreshold, MultiTenantCircuitBreakerTimeoutSec,
MultiTenantServiceAPIKey, MultiTenantCacheTTLSec,
MultiTenantConnectionsCheckIntervalSec); reconcile by either removing the extra
enum entry or updating the header to the correct count (15) and make the same
change to the other occurrence of this header elsewhere in the file so the
canonical env-var count matches the listed names.
---
Duplicate comments:
In `@default/skills/production-readiness-audit/SKILL.md`:
- Around line 3613-3619: The HARD GATES list in SKILL.md incorrectly includes a
warning-only item: remove the line/item starting with "5. (WARNING — not HARD
GATE) Non-canonical source implementation files detected: custom tenant
resolvers, manual pool managers, or wrapper middleware..." from the HARD GATES
block and place it under a separate WARNINGS or NOTES section (or a distinct
list titled "Warnings" below the HARD GATES heading); update surrounding
numbering/labels so HARD GATES remains only hard-fail items and ensure the
warning is clearly marked as non-fatal and not scored as 0.
- Around line 3620-3622: The doc currently requires the full canonical
MULTI_TENANT_* env var set unconditionally, which conflicts with the later
statement that single-tenant mode must work without those vars; update the
policy language and any validation logic to make the canonical MULTI_TENANT_*
requirements conditional on MULTI_TENANT_ENABLED=true: if MULTI_TENANT_ENABLED
is true require the full canonical list (APPLICATION_NAME plus all
MULTI_TENANT_* names listed), and if false require only APPLICATION_NAME (and
still forbid non-canonical tenant-related names like TENANT_MANAGER_URL,
TENANT_ENABLED, MULTI_TENANT_ENVIRONMENT); also adjust any automated checks to
skip flagging missing MULTI_TENANT_* vars when MULTI_TENANT_ENABLED=false.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: b0557a63-a141-4391-b964-495b949c15a6
📒 Files selected for processing (1)
default/skills/production-readiness-audit/SKILL.md
The skip condition said "if neither condition is met" which incorrectly activates M2M checks when only one condition is present. Changed to "if either condition is missing" to correctly require BOTH targetServices AND outbound credential provider usage before activating M2M checks. Generated-by: Claude AI-Model: claude-opus-4-6
The header claimed "14 MANDATORY — APPLICATION_NAME + 13 MULTI_TENANT_*" but the enumerated list has 14 MULTI_TENANT_* vars + APPLICATION_NAME = 15. Updated all 3 occurrences (GOOD reference comment, check #6, output format). Generated-by: Claude AI-Model: claude-opus-4-6
- Move item 5 (non-canonical files) from HARD GATES block into a separate WARNINGS section to keep gate semantics unambiguous - Make MULTI_TENANT_* env vars conditional on MULTI_TENANT_ENABLED=true; APPLICATION_NAME is always required; single-tenant mode must work without any MULTI_TENANT_* vars set - Update output format to reflect conditional env var reporting Generated-by: Claude AI-Model: claude-opus-4-6
jeffersonrodrigues92
deleted the
feat/production-readiness-full-multi-tenant-coverage
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
production-readiness-auditfrom 9 checks to 34 checks, achieving full alignment with the canonical multi-tenant model defined inmulti-tenant.mdGap analysis that motivated this change
Test plan
🤖 Generated with Claude Code