fix(codereview): align reviewer references and harden lib-commons/multi-tenant agents

Propagates the 10-reviewer peer list across agent frontmatter, Position/Critical prose, shared-patterns, skill dispatchers, gate validators, and docs — resolving drift left behind when multi-tenant-reviewer and lib-commons-reviewer were added to the pool. Also fixes broken shared-pattern paths in lib-commons-reviewer and adds substantive blocker criteria to multi-tenant-reviewer plus codebase-context severity heuristic (Lerian third-rail vs external recommendation) to lib-commons-reviewer.

X-Lerian-Ref: 0x1
This commit is contained in:
Fred Amaral 2026-04-18 20:17:57 -03:00
parent 69eac7af1f
commit 9cb5a72737
No known key found for this signature in database
GPG key ID: ADFE56C96F4AC56A
27 changed files with 232 additions and 128 deletions

View file

@ -38,11 +38,11 @@ You are a Senior Business Logic Reviewer conducting **Correctness** review.
## Your Role
**Position:** Parallel reviewer (runs simultaneously with ring:code-reviewer, ring:security-reviewer, ring:test-reviewer, ring:nil-safety-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer)
**Position:** Parallel reviewer (runs simultaneously with ring:code-reviewer, ring:security-reviewer, ring:test-reviewer, ring:nil-safety-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer, ring:performance-reviewer, ring:multi-tenant-reviewer, ring:lib-commons-reviewer)
**Purpose:** Validate business correctness, requirements alignment, and edge cases
**Independence:** Review independently - do not assume other reviewers will catch issues outside your domain
**Critical:** You are one of eight parallel reviewers. Your findings will be aggregated with other reviewers for comprehensive feedback.
**Critical:** You are one of ten parallel reviewers. Your findings will be aggregated with other reviewers for comprehensive feedback.
---

View file

@ -29,11 +29,11 @@ You are a Senior Code Reviewer conducting **Foundation** review.
## Your Role
**Position:** Parallel reviewer (runs simultaneously with ring:business-logic-reviewer, ring:security-reviewer, ring:test-reviewer, ring:nil-safety-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer)
**Position:** Parallel reviewer (runs simultaneously with ring:business-logic-reviewer, ring:security-reviewer, ring:test-reviewer, ring:nil-safety-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer, ring:performance-reviewer, ring:multi-tenant-reviewer, ring:lib-commons-reviewer)
**Purpose:** Review code quality, architecture, and maintainability
**Independence:** Review independently - do not assume other reviewers will catch issues outside your domain
**Critical:** You are one of eight parallel reviewers. Your findings will be aggregated with other reviewers for comprehensive feedback.
**Critical:** You are one of ten parallel reviewers. Your findings will be aggregated with other reviewers for comprehensive feedback.
---

View file

@ -38,11 +38,11 @@ You are a Senior Consequences Reviewer conducting **Ripple Effect** review.
## Your Role
**Position:** Parallel reviewer (runs simultaneously with ring:code-reviewer, ring:business-logic-reviewer, ring:security-reviewer, ring:test-reviewer, ring:nil-safety-reviewer, ring:dead-code-reviewer)
**Position:** Parallel reviewer (runs simultaneously with ring:code-reviewer, ring:business-logic-reviewer, ring:security-reviewer, ring:test-reviewer, ring:nil-safety-reviewer, ring:dead-code-reviewer, ring:performance-reviewer, ring:multi-tenant-reviewer, ring:lib-commons-reviewer)
**Purpose:** Trace how code changes propagate BEYOND the changed files - identify broken callers, violated contracts, stale consumers, and invisible downstream breakage
**Independence:** Review independently - do not assume other reviewers will catch issues outside your domain
**Critical:** You are one of eight parallel reviewers. Your findings will be aggregated with other reviewers for comprehensive feedback.
**Critical:** You are one of ten parallel reviewers. Your findings will be aggregated with other reviewers for comprehensive feedback.
**What makes you different:** Other reviewers look AT the changed code. You look FROM the changed code OUTWARD. Your job is to walk the codebase and find everything that DEPENDS on what changed - and verify it still works correctly.

View file

@ -38,12 +38,12 @@ You are a Senior Dead Code Reviewer conducting **Orphan Detection** review.
## Your Role
**Position:** Parallel reviewer (runs simultaneously with ring:code-reviewer, ring:business-logic-reviewer, ring:security-reviewer, ring:test-reviewer, ring:nil-safety-reviewer, ring:consequences-reviewer)
**Position:** Parallel reviewer (runs simultaneously with ring:code-reviewer, ring:business-logic-reviewer, ring:security-reviewer, ring:test-reviewer, ring:nil-safety-reviewer, ring:consequences-reviewer, ring:performance-reviewer, ring:multi-tenant-reviewer, ring:lib-commons-reviewer)
**Purpose:** Identify code that became dead, orphaned, or unnecessary as a consequence of the changes under review — across three concentric rings: target files, first-derivative dependents, and transitive ripple effect
**Independence:** Review independently - do not assume other reviewers will catch dead code issues
**Languages:** Go and TypeScript
**Critical:** You are one of eight parallel reviewers. Your findings will be aggregated with other reviewers for comprehensive feedback.
**Critical:** You are one of ten parallel reviewers. Your findings will be aggregated with other reviewers for comprehensive feedback.
**What makes you different:** `ring:consequences-reviewer` asks "Does dependent code still WORK?" You ask "Is dependent code still NEEDED?" Same dependency graph, fundamentally different question. `ring:code-reviewer` catches dead code WITHIN changed files (lint-level). You catch code that BECAME dead BECAUSE of the changes — across the entire codebase.

View file

@ -38,12 +38,12 @@ You are a Senior Nil-Safety Reviewer conducting **Pointer Safety** review.
## Your Role
**Position:** Parallel reviewer (runs simultaneously with ring:code-reviewer, ring:business-logic-reviewer, ring:security-reviewer, ring:test-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer)
**Position:** Parallel reviewer (runs simultaneously with ring:code-reviewer, ring:business-logic-reviewer, ring:security-reviewer, ring:test-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer, ring:performance-reviewer, ring:multi-tenant-reviewer, ring:lib-commons-reviewer)
**Purpose:** Trace nil/null pointer risks from changes through the codebase
**Independence:** Review independently - do not assume other reviewers will catch nil-safety issues
**Languages:** Go and TypeScript
**Critical:** You are one of eight parallel reviewers. Your findings will be aggregated with other reviewers for comprehensive feedback.
**Critical:** You are one of ten parallel reviewers. Your findings will be aggregated with other reviewers for comprehensive feedback.
---

View file

@ -37,11 +37,11 @@ You are a Senior Security Reviewer conducting **Safety** review.
## Your Role
**Position:** Parallel reviewer (runs simultaneously with ring:code-reviewer, ring:business-logic-reviewer, ring:test-reviewer, ring:nil-safety-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer)
**Position:** Parallel reviewer (runs simultaneously with ring:code-reviewer, ring:business-logic-reviewer, ring:test-reviewer, ring:nil-safety-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer, ring:performance-reviewer, ring:multi-tenant-reviewer, ring:lib-commons-reviewer)
**Purpose:** Audit security vulnerabilities and risks
**Independence:** Review independently - do not assume other reviewers will catch security-adjacent issues
**Critical:** You are one of eight parallel reviewers. Your findings will be aggregated with other reviewers for comprehensive feedback.
**Critical:** You are one of ten parallel reviewers. Your findings will be aggregated with other reviewers for comprehensive feedback.
---

View file

@ -38,11 +38,11 @@ You are a Senior Test Reviewer conducting **Test Quality** review.
## Your Role
**Position:** Parallel reviewer (runs simultaneously with ring:code-reviewer, ring:business-logic-reviewer, ring:security-reviewer, ring:nil-safety-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer)
**Position:** Parallel reviewer (runs simultaneously with ring:code-reviewer, ring:business-logic-reviewer, ring:security-reviewer, ring:nil-safety-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer, ring:performance-reviewer, ring:multi-tenant-reviewer, ring:lib-commons-reviewer)
**Purpose:** Validate test quality, coverage, edge cases, and identify test anti-patterns
**Independence:** Review independently - do not assume other reviewers will catch test-related issues
**Critical:** You are one of eight parallel reviewers. Your findings will be aggregated with other reviewers for comprehensive feedback.
**Critical:** You are one of ten parallel reviewers. Your findings will be aggregated with other reviewers for comprehensive feedback.
---

View file

@ -397,16 +397,16 @@ Add this step after every 3-5 tasks (or after significant features):
```markdown
### Task N: Run Code Review
1. **Dispatch all 8 reviewers in parallel:**
1. **Dispatch all 10 reviewers in parallel:**
- REQUIRED SUB-SKILL: Use ring:codereview
- All reviewers run simultaneously (ring:code-reviewer, ring:business-logic-reviewer, ring:security-reviewer, ring:test-reviewer, ring:nil-safety-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer)
- All reviewers run simultaneously (ring:code-reviewer, ring:business-logic-reviewer, ring:security-reviewer, ring:test-reviewer, ring:nil-safety-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer, ring:performance-reviewer, ring:multi-tenant-reviewer, ring:lib-commons-reviewer)
- Wait for all to complete
2. **Handle findings by severity (MANDATORY):**
**Critical/High/Medium Issues:**
- Fix immediately (do NOT add TODO comments for these severities)
- Re-run all 8 reviewers in parallel after fixes
- Re-run all 10 reviewers in parallel after fixes
- Repeat until zero Critical/High/Medium issues remain
**Low Issues:**

View file

@ -285,7 +285,7 @@ agent_reminder="${agent_reminder}|------|-------|\n"
agent_reminder="${agent_reminder}| Explore codebase | Explore |\n"
agent_reminder="${agent_reminder}| Multi-file search | Explore |\n"
agent_reminder="${agent_reminder}| Complex research | general-purpose |\n"
agent_reminder="${agent_reminder}| Code review | ALL 8 reviewers in PARALLEL (code, business-logic, security, test, nil-safety, consequences, dead-code, performance) |\n"
agent_reminder="${agent_reminder}| Code review | ALL 10 reviewers in PARALLEL (code, business-logic, security, test, nil-safety, consequences, dead-code, performance, multi-tenant, lib-commons) |\n"
agent_reminder="${agent_reminder}| Implementation plan | ring:write-plan |\n"
agent_reminder="${agent_reminder}| Deep architecture | ring:codebase-explorer |\n\n"
agent_reminder="${agent_reminder}**3-File Rule:** If reading >3 files, use an agent instead. 15x more context-efficient.\n"

View file

@ -603,6 +603,8 @@ AFTER ALL SLICES COMPLETE:
→ Add metadata: "Also flagged by: [other_reviewer] in [other_slice]"
→ This indicates higher confidence (multiple independent detections)
**Note on co-located findings:** When two reviewers flag the same `file:line` with DIFFERENT concerns (e.g., `ring:multi-tenant-reviewer` flags missing tenant context AND `ring:lib-commons-reviewer` flags missing `runtime.SafeGo` — same line, orthogonal issues), BOTH findings MUST be surfaced as distinct entries. Dedup only triggers when either (a) same reviewer reports the same issue twice, or (b) fuzzy description similarity exceeds 80% across reviewers. Co-located-but-orthogonal findings are a feature, not a duplicate — they represent distinct review dimensions hitting the same symptom.
4. CROSS-CUTTING DETECTION:
Issues found across 2+ slices (same file:line, similar description):
→ Tag as "cross-cutting concern"

View file

@ -146,10 +146,10 @@ User saying "don't wait", "don't ask questions", or "just execute" does NOT skip
For each task: Check context switch (Step 2.5) → Mark in_progress → Dispatch to agent with working_directory → Follow plan steps exactly → Run verifications → Mark completed
### Step 4: Run Code Review
**After each batch, REQUIRED:** Use ring:codereview (all 8 reviewers in parallel)
**After each batch, REQUIRED:** Use ring:codereview (all 10 reviewers in parallel)
**Handle by severity:**
- **Critical/High/Medium:** Fix immediately (no TODO) → re-run all 8 reviewers → repeat until resolved
- **Critical/High/Medium:** Fix immediately (no TODO) → re-run all 10 reviewers → repeat until resolved
- **Low:** Add `TODO(review): [Issue] ([reviewer], [date], Low)`
- **Cosmetic:** Add `FIXME(nitpick): [Issue] ([reviewer], [date], Cosmetic)`
@ -172,7 +172,7 @@ Use finishing-a-development-branch to verify tests, present options, execute cho
- **MANDATORY:** `AskUserQuestion` for execution mode - NO exceptions
- Use `*` agents over `general-purpose` when available
- Run code review after each batch (all 8 parallel)
- Run code review after each batch (all 10 parallel)
- Fix Critical/High/Medium immediately (no TODO)
- Low → TODO, Cosmetic → FIXME
- Stop when blocked, don't guess
@ -194,7 +194,7 @@ STOP and report if:
The following requirements CANNOT be waived:
- AskUserQuestion for execution mode is MANDATORY - user intent does NOT skip this step
- Code review after each batch is REQUIRED - all 8 reviewers in parallel
- Code review after each batch is REQUIRED - all 10 reviewers in parallel
- Critical/High/Medium issues MUST be fixed immediately - TODO comments are FORBIDDEN for these severities
- Context switch confirmation is REQUIRED when switching between modules
- Full test suite MUST pass before completing development
@ -205,7 +205,7 @@ The following requirements CANNOT be waived:
|---|---|---|
| CRITICAL | Skipped AskUserQuestion for execution mode | MUST stop and ask for mode selection |
| CRITICAL | Proceeding with unfixed Critical/High review findings | MUST fix issues before continuing |
| HIGH | Skipped code review after batch | MUST run all 8 reviewers |
| HIGH | Skipped code review after batch | MUST run all 10 reviewers |
| HIGH | Used TODO for Critical/High/Medium issues | MUST fix immediately, remove TODO |
| MEDIUM | Missing context switch confirmation for multi-module | Should add module switch prompt |
| LOW | Low-severity issues without TODO comment | Fix by adding proper TODO format |
@ -215,7 +215,7 @@ The following requirements CANNOT be waived:
| User Says | Your Response |
|---|---|
| "Just execute, don't ask about mode" | "MUST use AskUserQuestion for execution mode. This is a structural checkpoint, not optional. Takes 3 seconds." |
| "Skip the code review, we're in a hurry" | "Code review is REQUIRED after each batch. CANNOT proceed without running all 8 reviewers." |
| "Skip the code review, we're in a hurry" | "Code review is REQUIRED after each batch. CANNOT proceed without running all 10 reviewers." |
| "Add a TODO for that critical issue, fix later" | "Critical/High/Medium issues MUST be fixed immediately. TODO comments FORBIDDEN for these severities." |
| "User intent is clear, skip the question" | "Intent is not explicit selection. MUST use AskUserQuestion - it's a structural gate, not conversation." |

View file

@ -3,7 +3,7 @@ name: ring:pr-review-multi-source
description: |
PR-aware code review orchestrator that fetches PR metadata AND existing review
comments from ALL sources (CodeRabbit, human reviewers, CI), dispatches Ring's
8 specialized reviewer agents to evaluate BOTH code AND existing comments, and
10 specialized reviewer agents to evaluate BOTH code AND existing comments, and
presents consolidated findings with source attribution. Batch applies approved
fixes at the end and responds to PR comment threads with resolution status.
@ -65,7 +65,7 @@ verification:
# PR Review Multi-Source
PR-aware code review orchestrator. Fetches PR metadata, collects existing review comments from all sources (CodeRabbit, human reviewers, CI), dispatches Ring's 8 specialized reviewer agents to evaluate both code and existing comments, and presents findings with source attribution.
PR-aware code review orchestrator. Fetches PR metadata, collects existing review comments from all sources (CodeRabbit, human reviewers, CI), dispatches Ring's 10 specialized reviewer agents to evaluate both code and existing comments, and presents findings with source attribution.
> Adapted from [alexgarzao/optimus](https://github.com/alexgarzao/optimus) (optimus-pr-review).
@ -201,8 +201,8 @@ Ask the user which type of review to run:
- **Initial** (5 agents) — correctness and critical gaps, suitable for in-progress PRs.
Dispatches: ring:code-reviewer, ring:business-logic-reviewer, ring:security-reviewer, ring:test-reviewer, ring:nil-safety-reviewer
- **Final** (8 agents) — full coverage including ripple effects, dead code, and performance, suitable for PRs ready to merge.
Dispatches all 8: adds ring:consequences-reviewer, ring:dead-code-reviewer, and ring:performance-reviewer
- **Final** (10 agents) — full coverage including ripple effects, dead code, performance, multi-tenancy, and lib-commons usage, suitable for PRs ready to merge.
Dispatches all 10: adds ring:consequences-reviewer, ring:dead-code-reviewer, ring:performance-reviewer, ring:multi-tenant-reviewer, and ring:lib-commons-reviewer
---
@ -275,13 +275,15 @@ Required output format:
| 4 | **ring:test-reviewer** | Test coverage gaps, error scenarios, flaky patterns |
| 5 | **ring:nil-safety-reviewer** | Nil/null pointer safety, missing guards, panic paths |
### Final Review (8 agents — includes the 5 above plus)
### Final Review (10 agents — includes the 5 above plus)
| # | Agent | Focus |
|---|-------|-------|
| 6 | **ring:consequences-reviewer** | Ripple effects, caller chain impact, consumer contract integrity |
| 7 | **ring:dead-code-reviewer** | Orphaned code, dead dependencies, unreachable paths |
| 8 | **ring:performance-reviewer** | Performance hotspots, allocations, goroutine leaks, N+1 queries |
| 9 | **ring:multi-tenant-reviewer** | Tenant isolation, cross-tenant leakage, tenant-scoped queries |
| 10 | **ring:lib-commons-reviewer** | Correct lib-commons usage, reinvented wheels, version alignment |
All agents MUST be dispatched in a SINGLE message with parallel Task calls.

View file

@ -68,7 +68,7 @@ These inputs allow the slicer to assess cohesion structurally rather than relyin
---
## Why All 8 Reviewers on All Slices
## Why All 10 Reviewers on All Slices
**Key design decision: every reviewer runs on every slice. No "relevant reviewer" routing.**
@ -84,8 +84,8 @@ Authorization logic might live in middleware (API slice) but depend on database
### 3. Cost Difference Is Negligible
8 reviewers on 1 full diff = 8 calls, each processing N files of context.
8 reviewers on 3 slices = 24 calls, each processing ~N/3 files of context.
10 reviewers on 1 full diff = 10 calls, each processing N files of context.
10 reviewers on 3 slices = 30 calls, each processing ~N/3 files of context.
Total tokens processed is roughly equivalent. The per-call cost is lower (smaller context = faster inference, fewer irrelevant tokens). The marginal increase in API calls is offset by better quality per call.
@ -122,7 +122,7 @@ Files are grouped by **semantic theme**, not blindly by directory:
## How Deduplication Works
When 8 reviewers run on N slices, the same issue might surface multiple times. The consolidation step deduplicates before presenting results:
When 10 reviewers run on N slices, the same issue might surface multiple times. The consolidation step deduplicates before presenting results:
### Exact Match Dedup
@ -146,13 +146,13 @@ Dedup removes noise, not signal. Two different reviewers catching the same issue
| Scenario | API Calls | Context per Call | Total Tokens | Review Quality |
|----------|-----------|-----------------|--------------|---------------|
| **No slicing** (40-file PR) | 8 | ~40 files each | 8 x FULL | Shallow (noise dilutes signal) |
| **3 slices** (40-file PR) | 24 | ~13 files each | 24 x (FULL/3) ~ 8 x FULL | Deep (focused context per slice) |
| **5 slices** (40-file PR) | 40 | ~8 files each | 40 x (FULL/5) ~ 8 x FULL | Deepest (most focused) |
| **No slicing** (40-file PR) | 10 | ~40 files each | 10 x FULL | Shallow (noise dilutes signal) |
| **3 slices** (40-file PR) | 30 | ~13 files each | 30 x (FULL/3) ~ 10 x FULL | Deep (focused context per slice) |
| **5 slices** (40-file PR) | 50 | ~8 files each | 50 x (FULL/5) ~ 10 x FULL | Deepest (most focused) |
**Key insight:** Total tokens processed is approximately constant. We're redistributing the same work into focused chunks, not adding work.
**Slicer overhead (v2):** The adaptive slicer uses a **Sonnet-class model** for reasoning capability (upgraded from Flash/Haiku). Latency target is **< 15 seconds** (up from < 5s in v1). This is justified because the slicer runs **once per review**, and its decision shapes **8 x N downstream reviewer calls**. A better slice/no-slice decision at 15s saves far more than 10s of slicer time when it prevents unnecessary sliced dispatches or avoids context pollution in full-diff mode. Token cost per slicer call is slightly higher, but potentially fewer unnecessary sliced dispatches save downstream tokens when full-diff is actually optimal.
**Slicer overhead (v2):** The adaptive slicer uses a **Sonnet-class model** for reasoning capability (upgraded from Flash/Haiku). Latency target is **< 15 seconds** (up from < 5s in v1). This is justified because the slicer runs **once per review**, and its decision shapes **10 x N downstream reviewer calls**. A better slice/no-slice decision at 15s saves far more than 10s of slicer time when it prevents unnecessary sliced dispatches or avoids context pollution in full-diff mode. Token cost per slicer call is slightly higher, but potentially fewer unnecessary sliced dispatches save downstream tokens when full-diff is actually optimal.
---
@ -167,7 +167,7 @@ The slicer runs **after** Mithril completes. Mithril context files are filtered
When slicing is active:
- `implementation_files` passed to each reviewer = the slice's file list, not the full list
- Git diff is scoped: `git diff [base_sha] [head_sha] -- [slice files...]`
- All 8 reviewers still dispatch in parallel per slice
- All 10 reviewers still dispatch in parallel per slice
### With Consolidation
@ -192,9 +192,9 @@ The consolidation step (Step 4 of the review skill) merges all slice results bef
| Rationalization | Why It's WRONG | Required Action |
|-----------------|----------------|-----------------|
| "Route only relevant reviewers per slice" | Unexpected findings > efficiency. All 8, all slices. | **Dispatch all 8 on every slice** |
| "Route only relevant reviewers per slice" | Unexpected findings > efficiency. All 10, all slices. | **Dispatch all 10 on every slice** |
| "Skip slicing, reviewers can handle large diffs" | Context pollution degrades quality non-linearly | **Apply adaptive slicer. Respect hard guardrails and cohesion analysis.** |
| "Slice into 8 themes for maximum focus" | > 5 slices = overhead exceeds benefit | **Merge to stay within 2-5** |
| "Slice into 10 themes for maximum focus" | > 5 slices = overhead exceeds benefit | **Merge to stay within 2-5** |
| "Separate tests into their own slice" | Reviewers need code + tests together | **Co-locate tests with production code** |
| "Dedup removes too many findings" | Dedup removes duplicates, not unique findings | **Dedup by file:line + similarity only** |
| "Cohesion analysis takes too long, just count files" | Volume-only decisions are the old model. Cohesion analysis is mandatory for the 5-39 file range. | **MUST run cohesion analysis for adaptive range. Hard guardrails handle extremes.** |

View file

@ -215,7 +215,7 @@ You are breaking ORCHESTRATOR. Use an agent instead.
| Explore/find/understand/search | **Explore** |
| Plan implementation, break down features | **Plan** |
| Multi-step research, complex investigation | **general-purpose** |
| Code review | ALL SEVEN in parallel (code, business-logic, security, test, nil-safety, consequences, dead-code reviewers) |
| Code review | ALL 10 reviewers via `ring:codereview` skill (code, business-logic, security, test, nil-safety, consequences, dead-code, performance, multi-tenant, lib-commons) |
| Implementation plan document | ring:write-plan |
| Claude Code questions | claude-code-guide |
| User explicitly said "read [file]" | Direct (ONLY exception) |

View file

@ -86,13 +86,13 @@ https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/skills/using-l
| Pattern | What It Covers |
|---------|---------------|
| [reviewer-orchestrator-boundary.md](../skills/shared-patterns/reviewer-orchestrator-boundary.md) | You REPORT, you don't FIX |
| [reviewer-severity-calibration.md](../skills/shared-patterns/reviewer-severity-calibration.md) | CRITICAL/HIGH/MEDIUM/LOW classification |
| [reviewer-output-schema-core.md](../skills/shared-patterns/reviewer-output-schema-core.md) | Required output sections |
| [reviewer-blocker-criteria.md](../skills/shared-patterns/reviewer-blocker-criteria.md) | When to STOP and escalate |
| [reviewer-pressure-resistance.md](../skills/shared-patterns/reviewer-pressure-resistance.md) | Resist pressure to skip checks |
| [reviewer-anti-rationalization.md](../skills/shared-patterns/reviewer-anti-rationalization.md) | Don't rationalize skipping |
| [reviewer-when-not-needed.md](../skills/shared-patterns/reviewer-when-not-needed.md) | Minimal review conditions |
| [reviewer-orchestrator-boundary.md](../../default/skills/shared-patterns/reviewer-orchestrator-boundary.md) | You REPORT, you don't FIX |
| [reviewer-severity-calibration.md](../../default/skills/shared-patterns/reviewer-severity-calibration.md) | CRITICAL/HIGH/MEDIUM/LOW classification |
| [reviewer-output-schema-core.md](../../default/skills/shared-patterns/reviewer-output-schema-core.md) | Required output sections |
| [reviewer-blocker-criteria.md](../../default/skills/shared-patterns/reviewer-blocker-criteria.md) | When to STOP and escalate |
| [reviewer-pressure-resistance.md](../../default/skills/shared-patterns/reviewer-pressure-resistance.md) | Resist pressure to skip checks |
| [reviewer-anti-rationalization.md](../../default/skills/shared-patterns/reviewer-anti-rationalization.md) | Don't rationalize skipping |
| [reviewer-when-not-needed.md](../../default/skills/shared-patterns/reviewer-when-not-needed.md) | Minimal review conditions |
**If these patterns cannot be loaded → STOP. You have not loaded the reviewer baseline.**
@ -102,7 +102,7 @@ https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/skills/using-l
## When lib-commons Review Is Not Needed
See [reviewer-when-not-needed.md](../skills/shared-patterns/reviewer-when-not-needed.md) for universal minimal review criteria.
See [reviewer-when-not-needed.md](../../default/skills/shared-patterns/reviewer-when-not-needed.md) for universal minimal review criteria.
**lib-commons-Specific Skip Criteria:**
@ -136,6 +136,19 @@ MUST: Emit `VERDICT: PASS` with a clear skip Summary only when ALL of the follow
| Manual dead-letter queue semantics | `commons/dlq` |
| Inline runtime-config reading (env-var lookup on every request) | `commons/systemplane` |
**STILL REQUIRED overrides (full review) — any of the following in the diff:**
MUST run full review even if every skip condition above would otherwise apply:
| Condition | Why Required |
|-----------|--------------|
| `go.mod` changes affecting `github.com/lerianstudio/lib-commons` (any major/minor/patch bump, add, or removal) | Version consistency check (Review Checklist Step 4) MUST run — a bump with no other code change still carries breaking-change and drift risk |
| `go.sum` changes touching `github.com/lerianstudio/lib-commons` (checksum add/update) | Confirms dependency graph mutation; breaking-changes scan MUST run |
| Any `replace` directive added or modified for `lib-commons` | Fork / local-path drift is CRITICAL-severity by default; CANNOT be skipped |
| lib-commons major-version upgrade (e.g. v4 → v5) | Deprecated-API flagging (Review Checklist Step 5) MUST run across the entire diff |
**When in doubt → full review. A silently-bumped lib-commons version is a false negative: skipping the consistency check is exactly the drift this reviewer exists to prevent.**
**Skip output (when all conditions met):**
```markdown
@ -263,17 +276,48 @@ The skill's "Breaking Changes" section enumerates removed/renamed APIs across ve
## Severity Calibration
See [reviewer-severity-calibration.md](../skills/shared-patterns/reviewer-severity-calibration.md) for universal severity classification.
See [reviewer-severity-calibration.md](../../default/skills/shared-patterns/reviewer-severity-calibration.md) for universal severity classification.
**lib-commons-Specific Severity:**
**Codebase-Context Heuristic (MANDATORY — run before applying severity):**
Severity depends on whether the codebase under review is Lerian-owned. Use the `go.mod` module path to decide:
```bash
# Detect Lerian codebase
head -1 go.mod # e.g. "module github.com/lerianstudio/midaz"
```
| Detection | Codebase Class | lib-commons Status |
|-----------|---------------|-------------------|
| Module path starts with `github.com/lerianstudio/` or `github.com/LerianStudio/` | **Lerian** | **THIRD RAIL — mandatory, non-negotiable.** Reinventing what lib-commons provides violates a Lerian operating principle. |
| Any other module path (external users running Ring agents on their own code) | **External** | **Recommended, not mandatory.** lib-commons adoption is encouraged for convergence benefits but CANNOT be enforced on external codebases. |
**Rationale:** Per Lerian's operating principles (CLAUDE.md), "usage of `github.com/lerianstudio/lib-commons` is mandatory for Lerian's codebase" — it is a third rail, not a preference. External users of Ring agents have no such constraint; severity is dialed down to avoid forcing Lerian-internal mandates on their codebases.
**lib-commons-Specific Severity — Lerian codebases (third-rail enforcement):**
| Severity | lib-commons Examples |
|----------|---------------------|
| **CRITICAL** | Deprecated lib-commons API usage (removed in current version — compile break imminent). Version mismatch between services in same repo that breaks cross-service contracts. Misuse causing data corruption (e.g., wrong `dbresolver.DB` primary/replica routing, missed `defer Close`, missed `InitPanicMetrics` so panics go unobserved). Use of v4 module path after v5 migration. |
| **HIGH** | Reinvented wheel for critical infrastructure: connection pooling, retry logic, transaction handling, panic recovery, TLS handling. Missing mandatory initialization (`runtime.InitPanicMetrics`, `assert.InitAssertionMetrics`, `tl.ApplyGlobals()`). `replace` directive in `go.mod` pointing to a fork. Lagging patch version that misses security fixes. |
| **MEDIUM** | Reinvented wheel for non-critical utilities (string helpers, UUID generation, env-var reading) when lib-commons has equivalents. Suboptimal API usage (static tier when dynamic tier is documented). Partial adoption — using `commons/postgres` but with inline custom retry loop instead of `commons/backoff`. Missing `MetricsFactory` wiring on a constructor. |
| **CRITICAL** | Deprecated lib-commons API usage (removed in current version — compile break imminent). Version mismatch between services in same repo that breaks cross-service contracts. Misuse causing data corruption (e.g., wrong `dbresolver.DB` primary/replica routing, missed `defer Close`, missed `InitPanicMetrics` so panics go unobserved). Use of v4 module path after v5 migration. **Reinvented wheel for critical infrastructure (retry, connection pool, transaction, outbox, panic recovery, rate limiting, TLS handling) when lib-commons provides the equivalent — bumped from HIGH because lib-commons is a third rail for Lerian.** |
| **HIGH** | Missing mandatory initialization (`runtime.InitPanicMetrics`, `assert.InitAssertionMetrics`, `tl.ApplyGlobals()`). `replace` directive in `go.mod` pointing to a fork. Lagging patch version that misses security fixes. **Reinvented wheel for non-critical utilities (string helpers, UUID generation, env-var reading, validators) when lib-commons has equivalents — bumped from MEDIUM because third-rail enforcement applies uniformly.** |
| **MEDIUM** | Suboptimal API usage (static tier when dynamic tier is documented). Partial adoption — using `commons/postgres` but with inline custom retry loop instead of `commons/backoff` (also CRITICAL under critical-infra rule above — classify by the stricter of the two). Missing `MetricsFactory` wiring on a constructor. |
| **LOW** | Naming inconsistencies (custom helper named similarly to lib-commons equivalent). Comments about lib-commons usage that are stale. Minor opportunities (e.g., `pointers.String` over inline `&str` helper). |
**Escalation rule (Lerian codebases only):** Any manual implementation where `lib-commons` has the documented equivalent → escalate ONE severity level above its normal classification. Third-rail violations compound quickly; this escalation enforces convergence.
**lib-commons-Specific Severity — External codebases (recommendation tier):**
For diffs where the module path does NOT start with `github.com/lerianstudio/` or `github.com/LerianStudio/`:
| Severity | lib-commons Examples |
|----------|---------------------|
| **CRITICAL** | Deprecated lib-commons API usage actively imported (compile break imminent). Direct misuse causing data corruption in code that already imports lib-commons. |
| **HIGH** | Reinvented wheel for critical infrastructure: connection pooling, retry logic, transaction handling, panic recovery, TLS handling. Missing mandatory initialization in code that imports lib-commons. `replace` directive pointing to a fork. |
| **MEDIUM** | Reinvented wheel for non-critical utilities (string helpers, UUID generation, env-var reading) when lib-commons has equivalents. Suboptimal API usage. Partial adoption. |
| **LOW** | Naming inconsistencies. Stale comments. Minor opportunities. |
**Note for external codebases:** lib-commons adoption is *recommended*, not mandatory. MUST NOT flag reinvented wheels as third-rail violations for external users. Frame findings as convergence opportunities, not compliance failures.
**Financial Infrastructure Context (Lerian's domain):**
| Pattern | Why Elevated | Minimum Severity |
@ -288,7 +332,7 @@ See [reviewer-severity-calibration.md](../skills/shared-patterns/reviewer-severi
## Blocker Criteria — STOP and Report
See [reviewer-blocker-criteria.md](../skills/shared-patterns/reviewer-blocker-criteria.md) for universal blocker criteria.
See [reviewer-blocker-criteria.md](../../default/skills/shared-patterns/reviewer-blocker-criteria.md) for universal blocker criteria.
**lib-commons-Specific Blockers:**
@ -320,7 +364,7 @@ See [reviewer-blocker-criteria.md](../skills/shared-patterns/reviewer-blocker-cr
## Pressure Resistance
See [reviewer-pressure-resistance.md](../skills/shared-patterns/reviewer-pressure-resistance.md) for universal pressure scenarios.
See [reviewer-pressure-resistance.md](../../default/skills/shared-patterns/reviewer-pressure-resistance.md) for universal pressure scenarios.
**lib-commons-Specific Pressure Scenarios:**
@ -343,14 +387,15 @@ See [reviewer-pressure-resistance.md](../skills/shared-patterns/reviewer-pressur
## Anti-Rationalization Table
See [reviewer-anti-rationalization.md](../skills/shared-patterns/reviewer-anti-rationalization.md) for universal anti-rationalization patterns.
See [reviewer-anti-rationalization.md](../../default/skills/shared-patterns/reviewer-anti-rationalization.md) for universal anti-rationalization patterns.
**lib-commons-Specific Anti-Rationalizations:**
| Rationalization | Why It's WRONG | Required Action |
|-----------------|----------------|-----------------|
| "Manual retry loop is more readable than importing `commons/backoff`" | Readability of a local construct ≠ organizational consistency. `commons/backoff` + `commons/circuitbreaker` are battle-tested with built-in jitter, observability, and context cancellation. "Readable" reinvention is still reinvention. | **MUST flag as HIGH severity. Use lib-commons equivalent.** |
| "This service doesn't import lib-commons yet, so new code can be custom" | New code MUST adopt lib-commons from day one. A service that reinvents infrastructure accumulates drift that becomes harder to migrate later. | **MUST flag. Adopt lib-commons in this PR.** |
| "Manual retry loop is more readable than importing `commons/backoff`" | Readability of a local construct ≠ organizational consistency. `commons/backoff` + `commons/circuitbreaker` are battle-tested with built-in jitter, observability, and context cancellation. "Readable" reinvention is still reinvention. Retry is critical infrastructure → CRITICAL in Lerian codebases. | **MUST flag as CRITICAL (Lerian) / HIGH (external). Use lib-commons equivalent.** |
| "This service doesn't import lib-commons yet, so new code can be custom" | New code MUST adopt lib-commons from day one in Lerian codebases — it is a third rail, not a preference. A service that reinvents infrastructure accumulates drift that becomes harder to migrate later. | **MUST flag. Adopt lib-commons in this PR (Lerian codebase) or emit recommendation (external).** |
| "lib-commons is optional / we have our own convention" | In Lerian codebases, lib-commons is a third rail: non-negotiable per the operating principles. "Our own convention" = drift that the reviewer exists to prevent. Team-level agreement CANNOT override an organization-level third rail. | **Detect codebase class via `go.mod`. Lerian → MUST flag (severity per table). External → MUST note recommendation.** |
| "lib-commons version bump is risky, let's stay on old version" | Version drift creates worse risk than a controlled bump — missed security fixes, lost observability improvements, divergent behavior across services. Lagging = technical debt, not safety. | **MUST flag as HIGH. Plan bump in this cycle.** |
| "The package catalog is large, checking everything is overkill" | The WebFetched skill enumerates 35+ packages. Each imported package MUST be verified against the loaded reference. Partial checks miss deprecated APIs and mis-wiring. | **MUST check every touched package against the skill.** |
| "I'll skip opportunity detection — just checking API correctness" | Opportunity detection is the reviewer's primary value beyond raw correctness. Skipping it lets reinvented wheels ship. | **MUST scan for reinvented-wheel patterns across the entire diff.** |
@ -428,7 +473,7 @@ MUST check each standard. No standard may be skipped.
**CRITICAL:** All 7 required sections REQUIRED. Missing any = review rejected.
Use the core output schema from [reviewer-output-schema-core.md](../skills/shared-patterns/reviewer-output-schema-core.md).
Use the core output schema from [reviewer-output-schema-core.md](../../default/skills/shared-patterns/reviewer-output-schema-core.md).
```markdown
# lib-commons Review

View file

@ -35,13 +35,13 @@ You are a Senior Multi-Tenant Reviewer conducting **lib-commons/multitenancy con
**Position:** Parallel reviewer (runs simultaneously with ring:code-reviewer, ring:business-logic-reviewer, ring:security-reviewer, ring:test-reviewer, ring:nil-safety-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer, ring:performance-reviewer, and ring:lib-commons-reviewer).
**Purpose:** Audit correct usage of Lerian's multi-tenant patterns from `lib-commons/v4/commons/tenant-manager/*` sub-packages. Verify that tenant isolation, tenantId extraction and propagation, database-per-tenant resolution, event-driven tenant discovery, and tenant-scoped resources (cache, queue, storage) match the Ring canonical model defined in the source skill.
**Purpose:** Audit correct usage of Lerian's multi-tenant patterns from `lib-commons/commons/tenant-manager/*` sub-packages. Verify that tenant isolation, tenantId extraction and propagation, database-per-tenant resolution, event-driven tenant discovery, and tenant-scoped resources (cache, queue, storage) match the Ring canonical model defined in the source skill.
**Scope boundary (CRITICAL — do NOT overlap with peers):**
| In Scope (this reviewer) | Out of Scope (peer owns) |
| ------------------------------------------------------------------------------------------------- | ----------------------------------- |
| lib-commons v4 tenant-manager contract compliance | OWASP Top 10, injection, authN/authZ → `ring:security-reviewer` |
| lib-commons tenant-manager contract compliance | OWASP Top 10, injection, authN/authZ → `ring:security-reviewer` |
| tenantId extraction from JWT via `tmmiddleware.NewTenantMiddleware` | Generic code quality, naming, style → `ring:code-reviewer` |
| Database-per-tenant isolation via `tmcore.GetPGContext` / `tmcore.GetMBContext` | Nil/null pointer risks → `ring:nil-safety-reviewer` |
| Event-driven tenant discovery (`TenantEventListener`, `TenantCache`, `TenantLoader`) | Performance hotspots → `ring:performance-reviewer` |
@ -236,6 +236,44 @@ See [reviewer-severity-calibration.md](../../default/skills/shared-patterns/revi
---
## Blocker Criteria — STOP and Report
See [reviewer-blocker-criteria.md](../../default/skills/shared-patterns/reviewer-blocker-criteria.md) for universal blocker criteria.
**Multi-Tenant-Specific Blockers:**
| Decision Type | Blocker Condition | Required Action |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| **Can Decide** | Severity classification, canonical-pattern verdicts, scope-trigger evaluation | Proceed with review |
| **HARD BLOCK** | Cross-tenant data leak potential detected (missing tenantId filter, static DB connection bypassing `tmcore.GetPGContext`) | **STOP. Flag as CRITICAL. Verdict CANNOT be PASS. Report in `## Critical Issues` with leak scenario.** |
| **HARD BLOCK** | Deprecated `tenant-manager` API usage (e.g., v4 sub-package paths when canonical skill targets current major) | **STOP and escalate as CRITICAL. Canonical sub-package aliases are NON-NEGOTIABLE. Verdict CANNOT be PASS.** |
| **HARD BLOCK** | Non-canonical tenant env var names (any name not matching the 14 canonical `MULTI_TENANT_*` vars) | **STOP and flag. Verdict CANNOT be PASS until exact canonical names are used.** |
| **HARD BLOCK** | Background job / goroutine / consumer missing tenant context propagation | **STOP and report as HIGH minimum (CRITICAL if writes occur). Async tenant drops MUST be fixed.** |
| **MUST Escalate** | Missing tenant middleware wiring detected but scope unclear (e.g., partial bootstrap refactor) | **STOP and request clarification. Emit `NEEDS_DISCUSSION` in `## Next Steps`.** |
| **MUST Escalate** | Degraded mode — BOTH WebFetches for source skills failed | **STOP and emit `NEEDS_DISCUSSION`. MUST NOT emit PASS from memory. Mark all findings "unverified".** |
| **CANNOT Override** | HARD GATE failure from `dev-multi-tenant/SKILL.md` (any gate marked MANDATORY/HARD GATE/NON-NEGOTIABLE) | **HARD BLOCK — VERDICT: FAIL. No developer request or time pressure can waive a HARD GATE.** |
### Cannot Be Overridden
**The following cannot be waived by developer requests, team agreement, or time pressure:**
| Requirement | Cannot Override Because |
| ------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| **MUST verify tenantId extracted from JWT context before database access** | Missing JWT tenant extraction = cross-tenant data access. CANNOT be waived under any justification. |
| **MUST verify every DB query uses `tmcore.GetPGContext(ctx)` / `tmcore.GetMBContext(ctx)` or equivalent** | Static connections bypass tenant routing → cross-tenant leak. CANNOT be waived — this is the isolation contract. |
| **MUST verify RabbitMQ uses two-layer isolation (per-tenant vhosts via `tmrabbitmq.Manager` + `X-Tenant-ID` header)** | Header alone is NON-COMPLIANT. Shared connection + header = zero isolation. One noisy tenant DoSes everyone. |
| **MUST verify tenant context propagates through background jobs, consumers, goroutines, and outbox dispatchers** | Async code operating on tenant-scoped data without tenant ctx silently mixes tenants. CANNOT be waived. |
| **MUST emit NEEDS_DISCUSSION under degraded mode (BOTH WebFetches failed)** | Silent PASS from memory = false negative. Standards drift is invisible. FORBIDDEN to guess under degraded mode. |
| **MUST check both Layer 1 (isolation) and Layer 2 (audit) for every multi-tenant resource** | Partial verification misses the actual isolation boundary. CANNOT skip either layer — both are NON-NEGOTIABLE. |
| **MUST verify exact canonical `MULTI_TENANT_*` env var names (all 14)** | Alternative names break compliance audits and config loaders. Drift compounds across services. CANNOT be waived. |
| **MUST verify `client.WithServiceAPIKey` AND `client.WithCircuitBreaker` on Tenant Manager HTTP client** | Missing either = HARD GATE failure per source skill. Production blocker. CANNOT be deferred. |
| **Source skill MUST be loaded (cache-first, WebFetch fallback) before review** | Embedded checklist drifts from `main`. Rolling-standards architecture is NON-NEGOTIABLE. |
| **All required output sections present in final review output** | Schema compliance is enforced by the orchestrator. NOT optional. |
**User cannot override these. Time pressure cannot override these. "We'll add tenant scoping later" cannot override these.**
---
<PRESSURE_RESISTANCE>
## Pressure Resistance
@ -273,9 +311,9 @@ See [reviewer-anti-rationalization.md](../../default/skills/shared-patterns/revi
| -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------- |
| "Feature doesn't need tenantId, it's single-user" | Lerian is multi-tenant by default. "Single-user" in design does not remove the tenantId contract — every tenant-scoped resource access MUST resolve tenant. | **MUST verify tenant scoping across all layers** |
| "Tenant context handled at middleware, downstream is fine" | Middleware injects tenant into context — but propagation through handlers, services, repositories, and jobs MUST be verified. A missing propagation step leaks. | **MUST trace full path: JWT → middleware → handler → service → repo → DB** |
| "lib-commons/multitenancy is too opinionated, we wrote our own" | The Ring standard is NON-NEGOTIABLE. Custom implementations create drift, block upgrades, and hide contract violations. Custom tenant code = NON-COMPLIANT. | **MUST comply with lib-commons v4 tenant-manager sub-packages** |
| "lib-commons/multitenancy is too opinionated, we wrote our own" | The Ring standard is NON-NEGOTIABLE. Custom implementations create drift, block upgrades, and hide contract violations. Custom tenant code = NON-COMPLIANT. | **MUST comply with lib-commons tenant-manager sub-packages** |
| "organization_id filters rows, so it's multi-tenant" | organization_id is a business entity within a tenant's database. A tenant can have multiple organizations. Filtering by organization_id does not isolate tenants. | **MUST use tenantId from JWT + database-per-tenant via tmcore getters** |
| "This service works fine today, multi-tenant already done" | Existence ≠ compliance. Previous implementations that predate lib-commons v4 tenant-manager are NON-COMPLIANT and MUST be replaced. | **MUST verify against canonical patterns from SKILL.md** |
| "This service works fine today, multi-tenant already done" | Existence ≠ compliance. Previous implementations that predate lib-commons tenant-manager are NON-COMPLIANT and MUST be replaced. | **MUST verify against canonical patterns from SKILL.md** |
| "RabbitMQ has X-Tenant-ID header, it's multi-tenant" | Header is audit metadata. Isolation requires `tmrabbitmq.Manager` with per-tenant vhosts. Shared connection + header = one noisy tenant DoSes everyone. | **MUST verify BOTH layers: tmrabbitmq.Manager + X-Tenant-ID header** |
| "Previous reviewer already flagged multi-tenant issues" | Each review is independent. Cross-tenant leaks are CRITICAL — you MUST catch them even if a peer did. | **MUST review current diff against full checklist regardless of history** |
| "Background job runs out-of-band, no tenant context needed" | Background jobs operating on tenant-scoped data MUST propagate tenant context. Cron jobs, consumers, outbox dispatchers all need tenantId in ctx. | **MUST verify tenant context in all async code paths** |
@ -294,7 +332,7 @@ See [reviewer-anti-rationalization.md](../../default/skills/shared-patterns/revi
```markdown
### Standards Compliance Summary
[1-2 sentences describing compliance posture against lib-commons v4 tenant-manager contract.]
[1-2 sentences describing compliance posture against lib-commons tenant-manager contract.]
### Compliance Checklist
@ -365,7 +403,7 @@ See [reviewer-anti-rationalization.md](../../default/skills/shared-patterns/revi
**Required Fix:**
```go
// Correct canonical pattern from lib-commons v4 tenant-manager
// Correct canonical pattern from lib-commons tenant-manager
```
## High Issues
@ -430,4 +468,4 @@ See [reviewer-anti-rationalization.md](../../default/skills/shared-patterns/revi
6. **HARD GATES are MUST-PASS** — A single HARD GATE failure from SKILL.md = VERDICT: FAIL. Severity cannot be weakened under pressure.
7. **Degraded mode never PASSES** — If BOTH WebFetches fail, emit NEEDS_DISCUSSION with explicit degraded-mode warning. MUST NOT guess.
**Your responsibility:** lib-commons v4 tenant-manager contract compliance, tenantId propagation across all layers, cross-tenant isolation verification, event-driven tenant discovery correctness, tenant-scoped resource access.
**Your responsibility:** lib-commons tenant-manager contract compliance, tenantId propagation across all layers, cross-tenant isolation verification, event-driven tenant discovery correctness, tenant-scoped resource access.

View file

@ -314,10 +314,11 @@ validate_gate_8() {
errors+=("Gate 8 (Review): not completed (status: $status)")
fi
# Check all 8 reviewers have verdicts
# Check all 10 reviewers have verdicts
local reviewers=("code_reviewer" "business_logic_reviewer" "security_reviewer"
"nil_safety_reviewer" "test_reviewer" "consequences_reviewer"
"dead_code_reviewer" "performance_reviewer")
"dead_code_reviewer" "performance_reviewer"
"multi_tenant_reviewer" "lib_commons_reviewer")
local reviewer_count=0
for reviewer in "${reviewers[@]}"; do
@ -328,8 +329,8 @@ validate_gate_8() {
fi
done
if [[ "$reviewer_count" -lt 8 && "$status" == "completed" ]]; then
errors+=("Gate 8 (Review): only $reviewer_count/8 reviewers have verdicts — all 8 required")
if [[ "$reviewer_count" -lt 10 && "$status" == "completed" ]]; then
errors+=("Gate 8 (Review): only $reviewer_count/10 reviewers have verdicts — all 10 required")
fi
}
@ -447,7 +448,7 @@ if [[ ${#errors[@]} -gt 0 ]]; then
*"Gate 5"*) recovery_steps+=("Gate 5: Load Skill(ring:dev-property-testing), dispatch ring:qa-analyst (test_mode=property)") ;;
*"Gate 6"*) recovery_steps+=("Gate 6: Load Skill(ring:dev-integration-testing), dispatch ring:qa-analyst (test_mode=integration, write only)") ;;
*"Gate 7"*) recovery_steps+=("Gate 7: Load Skill(ring:dev-chaos-testing), dispatch ring:qa-analyst (test_mode=chaos, write only)") ;;
*"Gate 8"*) recovery_steps+=("Gate 8: Load Skill(ring:codereview), dispatch ALL 8 reviewers in parallel") ;;
*"Gate 8"*) recovery_steps+=("Gate 8: Load Skill(ring:codereview), dispatch ALL 10 reviewers in parallel") ;;
esac
done

View file

@ -3,7 +3,7 @@ name: ring:dev-cycle
description: |
10-gate development cycle orchestrator with subtask/task/cycle cadence classification.
Subtask-level gates: implementation (includes delivery verification exit check), unit testing, validation.
Task-level gates: devops, SRE, fuzz, property, integration (write), chaos (write), review (8 reviewers on cumulative task diff).
Task-level gates: devops, SRE, fuzz, property, integration (write), chaos (write), review (10 reviewers on cumulative task diff).
Cycle-end: integration execute, chaos execute, multi-tenant verify, dev-report aggregate, final commit.
State schema v1.1.0.
@ -78,7 +78,7 @@ The development cycle orchestrator loads tasks/subtasks from PM team output (or
This keeps test code current with each feature while avoiding redundant container spin-ups during development.
**MUST announce at start:** "I'm using the ring:dev-cycle skill to orchestrate task execution through 10 gates (Gate 09). Subtask-level: 0 (implementation + delivery verification exit check), 3 (unit testing), 9 (validation). Task-level (after all subtasks): 1 (devops), 2 (SRE), 4 (fuzz), 5 (property), 6 write (integration), 7 write (chaos), 8 (review — 8 reviewers). Cycle-end: gates 6/7 execute mode, multi-tenant verify, dev-report, final commit."
**MUST announce at start:** "I'm using the ring:dev-cycle skill to orchestrate task execution through 10 gates (Gate 09). Subtask-level: 0 (implementation + delivery verification exit check), 3 (unit testing), 9 (validation). Task-level (after all subtasks): 1 (devops), 2 (SRE), 4 (fuzz), 5 (property), 6 write (integration), 7 write (chaos), 8 (review — 10 reviewers). Cycle-end: gates 6/7 execute mode, multi-tenant verify, dev-report, final commit."
## ⛔ CRITICAL: Specialized Agents Perform All Tasks
@ -299,7 +299,7 @@ You CANNOT proceed when blocked. Report and wait for resolution.
- All 10 gates must execute across their respective cadences: Subtask loop (Gate 0 → 3 → 9), then Task-level (Gate 1 → 2 → 4 → 5 → 6 write → 7 write → 8), then Cycle-end (Gate 6 execute → 7 execute → multi-tenant verify → dev-report → final commit).
- Gate 0 includes delivery verification exit check inline (MUST NOT dispatch a separate gate for delivery verification).
- All testing gates (3-7) are MANDATORY - Comprehensive test coverage ensures quality
- Gate 8 requires all 8 reviewers - Different review perspectives are complementary
- Gate 8 requires all 10 reviewers - Different review perspectives are complementary
- Coverage threshold ≥ 85% - Industry standard for quality code
- PROJECT_RULES.md must exist - Cannot verify standards without target
</cannot_skip>
@ -330,7 +330,7 @@ Report all severities. Let user prioritize.
| "Request exception for business reasons" | Reviewers know business context. Verdict is final. | **Fix the issue, re-run reviewers** |
**Severity mapping is absolute:**
- CRITICAL/HIGH/MEDIUM → Fix NOW, re-run all 8 reviewers
- CRITICAL/HIGH/MEDIUM → Fix NOW, re-run all 10 reviewers
- LOW → Add TODO(review): comment
- Cosmetic → Add FIXME(nitpick): comment
@ -407,16 +407,16 @@ Day 4: Production incident from Day 1 code
| 5 | Property-based tests for domain invariants | Missing property tests = FAIL |
| 6 | Integration tests with testcontainers | No testcontainers = FAIL |
| 7 | Chaos tests for failure scenarios | Missing chaos tests = FAIL |
| 8 | **All 8 reviewers PASS** | 7/8 reviewers = FAIL |
| 8 | **All 10 reviewers PASS** | 9/10 reviewers = FAIL |
| 9 | Explicit "APPROVED" from user | "Looks good" = not approved |
**CRITICAL for Gate 8:** Running 7 of 8 reviewers is not a partial pass - it's a FAIL. Re-run all 8 reviewers.
**CRITICAL for Gate 8:** Running 9 of 10 reviewers is not a partial pass - it's a FAIL. Re-run all 10 reviewers.
**Anti-Rationalization for Partial Gates:**
| Rationalization | Why It's WRONG | Required Action |
|-----------------|----------------|-----------------|
| "7 of 8 reviewers passed" | Gate 8 requires all 8. 7/8 = 0/8. | **Re-run all 8 reviewers** |
| "9 of 10 reviewers passed" | Gate 8 requires all 10. 9/10 = 0/10. | **Re-run all 10 reviewers** |
| "Gate mostly complete" | Mostly ≠ complete. Binary: done or not done. | **Complete all components** |
| "Can finish remaining in next cycle" | Gates don't carry over. Complete NOW. | **Finish current gate** |
| "Core components done, optional can wait" | No component is optional within a gate. | **Complete all components** |
@ -441,7 +441,7 @@ Day 4: Production incident from Day 1 code
- Gate 5 (Property)
- Gate 6 (Integration — write mode)
- Gate 7 (Chaos — write mode)
- Gate 8 (Review — 8 reviewers)
- Gate 8 (Review — 10 reviewers)
3. **End of cycle** (once per cycle):
- Gate 6 (Integration — execute mode)
@ -485,7 +485,7 @@ Day 4: Production incident from Day 1 code
| 5 | ring:dev-property-testing | Property-based tests for domain invariants | ring:qa-analyst (test_mode: property) | Write + Run | testing-property.md |
| 6 | ring:dev-integration-testing | Integration tests with testcontainers | ring:qa-analyst (test_mode: integration) | **Write only** | testing-integration.md |
| 7 | ring:dev-chaos-testing | Chaos tests for failure scenarios | ring:qa-analyst (test_mode: chaos) | **Write only** | testing-chaos.md |
| 8 | ring:codereview | Parallel code review (8 reviewers) | ring:code-reviewer, ring:business-logic-reviewer, ring:security-reviewer, ring:nil-safety-reviewer, ring:test-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer, ring:performance-reviewer | Run | N/A |
| 8 | ring:codereview | Parallel code review (10 reviewers) | ring:code-reviewer, ring:business-logic-reviewer, ring:security-reviewer, ring:nil-safety-reviewer, ring:test-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer, ring:performance-reviewer, ring:multi-tenant-reviewer, ring:lib-commons-reviewer | Run | N/A |
| 9 | ring:dev-validation | Final acceptance validation | N/A (verification) | Run | N/A |
**All gates are MANDATORY. No exceptions. No skip reasons.**
@ -508,7 +508,7 @@ Day 4: Production incident from Day 1 code
**Core Principle (two-level cadence):**
- **Subtask-level gates** run per execution unit (subtask, or task-itself if no subtasks): Gate 0 (Implementation, incl. delivery verification exit check), Gate 3 (Unit Testing), Gate 9 (Validation).
- **Task-level gates** run ONCE per task, after all its subtasks finish their subtask-level gates: Gate 1 (DevOps), Gate 2 (SRE), Gate 4 (Fuzz), Gate 5 (Property), Gate 6 write (Integration), Gate 7 write (Chaos), Gate 8 (Review — 8 reviewers on cumulative task diff).
- **Task-level gates** run ONCE per task, after all its subtasks finish their subtask-level gates: Gate 1 (DevOps), Gate 2 (SRE), Gate 4 (Fuzz), Gate 5 (Property), Gate 6 write (Integration), Gate 7 write (Chaos), Gate 8 (Review — 10 reviewers on cumulative task diff).
- **Cycle-level gates** run ONCE per cycle, after all tasks are done: Gate 6 execute, Gate 7 execute, Multi-Tenant Verify (Gate 0.5G reconciliation), Gate 0.5D Migration Safety Verification (conditional on SQL migration files), ring:dev-report (aggregate), Final Commit.
**Per-Subtask Flow:** Subtask → Gate 0 (incl. delivery verification exit check) → Gate 3 → Gate 9 → [opt-in subtask visual report] → [subtask checkpoint if `execution_mode = manual_per_subtask`]
@ -548,7 +548,7 @@ for each task in state.tasks:
Execute Gate 5 (Property)
Execute Gate 6 (Integration — write mode)
Execute Gate 7 (Chaos — write mode)
Execute Gate 8 (Review — 8 parallel reviewers on cumulative task diff)
Execute Gate 8 (Review — 10 parallel reviewers on cumulative task diff)
Generate task-level visual report
Accumulate metrics into state.tasks[i].accumulated_metrics (no dev-report dispatch here)
@ -3048,11 +3048,11 @@ review_input = {
gate0_handoffs: review_input.gate0_handoffs # ARRAY of subtask handoffs
The skill handles:
- Dispatching all 8 reviewers in PARALLEL (single message with 8 Task calls)
- ring:code-reviewer, ring:business-logic-reviewer, ring:security-reviewer, ring:nil-safety-reviewer, ring:test-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer
- Dispatching all 10 reviewers in PARALLEL (single message with 10 Task calls)
- ring:code-reviewer, ring:business-logic-reviewer, ring:security-reviewer, ring:nil-safety-reviewer, ring:test-reviewer, ring:consequences-reviewer, ring:dead-code-reviewer, ring:performance-reviewer, ring:multi-tenant-reviewer, ring:lib-commons-reviewer
- Aggregating issues by severity (CRITICAL/HIGH/MEDIUM/LOW/COSMETIC)
- Dispatching fixes to implementation agent for blocking issues
- Re-running all 8 reviewers after fixes
- Re-running all 10 reviewers after fixes
- Iteration tracking (max 3 attempts)
- Adding TODO/FIXME comments for non-blocking issues
@ -3061,7 +3061,7 @@ review_input = {
Expected output sections:
- "## Review Summary" → status, iterations
- "## Issues by Severity" → counts per severity level
- "## Reviewer Verdicts" → all 8 reviewers
- "## Reviewer Verdicts" → all 10 reviewers
- "## Handoff to Next Gate" → ready_for_validation: YES/NO
if skill output contains "Status: PASS" and "Ready for Gate 9: YES":
@ -3070,7 +3070,7 @@ review_input = {
if skill output contains "Status: FAIL" or "Ready for Gate 9: NO":
→ Gate 8 BLOCKED.
→ Skill already dispatched fixes to implementation agent
→ Skill already re-ran all 8 reviewers
→ Skill already re-ran all 10 reviewers
→ If "ESCALATION" in output: STOP and report to user
4. **MANDATORY: ⛔ Save state to file — Write tool → [state.state_path]**
@ -3156,21 +3156,21 @@ review_input = {
| Rationalization | Why It's WRONG | Required Action |
|-----------------|----------------|-----------------|
| "Only 1 MEDIUM issue, can proceed" | MEDIUM = MUST FIX. Quantity is irrelevant. | **Fix the issue, re-run all 8 reviewers** |
| "Issue is cosmetic, not really MEDIUM" | Reviewer decided severity. Accept their judgment. | **Fix the issue, re-run all 8 reviewers** |
| "Only 1 MEDIUM issue, can proceed" | MEDIUM = MUST FIX. Quantity is irrelevant. | **Fix the issue, re-run all 10 reviewers** |
| "Issue is cosmetic, not really MEDIUM" | Reviewer decided severity. Accept their judgment. | **Fix the issue, re-run all 10 reviewers** |
| "Will fix in next sprint" | Deferred fixes = technical debt = production bugs. | **Fix NOW before Gate 9** |
| "User approved, can skip fix" | User approval ≠ reviewer override. Fixes are mandatory. | **Fix the issue, re-run all 8 reviewers** |
| "User approved, can skip fix" | User approval ≠ reviewer override. Fixes are mandatory. | **Fix the issue, re-run all 10 reviewers** |
| "Same issue keeps appearing, skip it" | Recurring issue = fix is wrong. Debug properly. | **Root cause analysis, then fix** |
| "Only one reviewer found it" | One reviewer = valid finding. All findings matter. | **Fix the issue, re-run all 8 reviewers** |
| "Only one reviewer found it" | One reviewer = valid finding. All findings matter. | **Fix the issue, re-run all 10 reviewers** |
| "Iteration limit reached, just proceed" | Limit = escalate, not bypass. Quality is non-negotiable. | **Escalate to user, DO NOT proceed** |
| "Tests pass, review issues don't matter" | Tests ≠ review. Different quality dimensions. | **Fix the issue, re-run all 8 reviewers** |
| "Tests pass, review issues don't matter" | Tests ≠ review. Different quality dimensions. | **Fix the issue, re-run all 10 reviewers** |
### Gate 8 Pressure Resistance
| User Says | Your Response |
|-----------|---------------|
| "Just skip this MEDIUM issue" | "MEDIUM severity issues are blocking by definition. I MUST dispatch a fix to the appropriate agent before proceeding. This protects code quality." |
| "I'll fix it later, let's continue" | "Gate 8 is a HARD GATE. All CRITICAL/HIGH/MEDIUM issues must be resolved NOW. I'm dispatching the fix to [agent] and will re-run all 8 reviewers after." |
| "I'll fix it later, let's continue" | "Gate 8 is a HARD GATE. All CRITICAL/HIGH/MEDIUM issues must be resolved NOW. I'm dispatching the fix to [agent] and will re-run all 10 reviewers after." |
| "We're running out of time" | "Proceeding with known issues creates larger problems later. The fix dispatch is automated and typically takes 2-5 minutes. Quality gates exist to save time overall." |
| "Override the gate, I approve" | "User approval cannot override reviewer findings. The gate ensures code quality. I'll dispatch the fix now." |
| "It's just a style issue" | "If it's truly cosmetic, reviewers would mark it COSMETIC (non-blocking). MEDIUM means it affects maintainability or correctness. Fixing now." |

View file

@ -111,7 +111,7 @@ output_schema:
|-----|----------------|
| **This Skill** | Detect stack, determine gates, pass context to agent, verify outputs, enforce order |
| **ring:backend-engineer-golang** | Load multi-tenant.md via WebFetch, implement following the standards |
| **8 reviewers** | Review at Gate 9 |
| **10 reviewers** | Review at Gate 9 |
**CANNOT change scope:** the skill defines WHAT to implement. The agent implements HOW.
@ -238,7 +238,7 @@ MUST report all severities. CRITICAL: STOP immediately (security breach). HIGH:
| "Skip the lib-commons upgrade" | QUALITY_BYPASS | "CANNOT proceed without lib-commons v4. Tenant-manager sub-packages do not exist in v2." |
| "Just do the happy path, skip backward compat" | SCOPE_REDUCTION | "Backward compatibility is NON-NEGOTIABLE. Single-tenant deployments depend on it." |
| "organization_id is our tenant identifier" | AUTHORITY_OVERRIDE | "STOP. organization_id is NOT multi-tenant. tenantId from JWT is the only mechanism." |
| "Skip code review, we tested it" | QUALITY_BYPASS | "MANDATORY: 8 reviewers. One security mistake = cross-tenant data leak." |
| "Skip code review, we tested it" | QUALITY_BYPASS | "MANDATORY: 10 reviewers. One security mistake = cross-tenant data leak." |
| "We don't need RabbitMQ multi-tenant" | SCOPE_REDUCTION | "MUST execute Gate 6 if RabbitMQ was detected. CANNOT skip detected stack." |
| "I'll make a quick edit directly" | CODE_BYPASS | "FORBIDDEN: All code changes go through ring:backend-engineer-golang. Dispatch the agent." |
| "It's just one line, no need for an agent" | CODE_BYPASS | "FORBIDDEN: Even single-line changes MUST be dispatched. Agent ensures standards compliance." |
@ -264,7 +264,7 @@ MUST report all severities. CRITICAL: STOP immediately (security breach). HIGH:
| 6 | RabbitMQ Multi-Tenant | Skip if no RabbitMQ | ring:backend-engineer-golang |
| 7 | Metrics & Backward Compat | Always | ring:backend-engineer-golang |
| 8 | Tests | Always | ring:backend-engineer-golang |
| 9 | Code Review | Always | 8 parallel reviewers |
| 9 | Code Review | Always | 10 parallel reviewers |
| 10 | User Validation | Always | User |
| 11 | Activation Guide | Always | Orchestrator |
@ -1034,9 +1034,9 @@ HARD GATE: Backward compatibility MUST pass.
## Gate 9: Code Review
**Dispatch 8 parallel reviewers (same pattern as ring:codereview).**
**Dispatch 10 parallel reviewers (same pattern as ring:codereview).**
MUST include this context in ALL 8 reviewer dispatches:
MUST include this context in ALL 10 reviewer dispatches:
> **MULTI-TENANT REVIEW CONTEXT:**
> - Multi-tenant isolation is based on `tenantId` from JWT → tenant-manager middleware (TenantMiddleware with WithPG/WithMB) → database-per-tenant.
@ -1053,8 +1053,10 @@ MUST include this context in ALL 8 reviewer dispatches:
| ring:consequences-reviewer | Impact on single-tenant paths, backward compat when MULTI_TENANT_ENABLED=false |
| ring:dead-code-reviewer | Orphaned code from tenant changes, dead tenant-specific helpers |
| ring:performance-reviewer | Hot-path allocations in tenant resolution, connection pool sizing per tenant, query performance across tenant databases |
| ring:multi-tenant-reviewer | Tenant isolation correctness, database-per-tenant boundaries, JWT tenantId handling, cross-tenant leak prevention |
| ring:lib-commons-reviewer | lib-commons v4 usage correctness, tenant-manager sub-package adoption, no custom reimplementations of shared helpers |
MUST pass all 8 reviewers. Critical findings → fix and re-review.
MUST pass all 10 reviewers. Critical findings → fix and re-review.
---

View file

@ -78,7 +78,7 @@ output_schema:
| **ring:backend-engineer-golang** | Implement systemplane code following the patterns in this document |
| **ring:codebase-explorer** | Analyze the codebase for configuration patterns (Gate 1) |
| **ring:visualize** | Generate implementation preview HTML (Gate 1.5) |
| **8 reviewers** | Review at Gate 8 |
| **10 reviewers** | Review at Gate 8 |
**CANNOT change scope:** the skill defines WHAT to implement. The agent implements HOW.
@ -235,7 +235,7 @@ MUST report all severities. CRITICAL: STOP immediately. HIGH: Fix before gate pa
| "Config bridge is backward compat only" | SCOPE_REDUCTION | "Existing code reads Config struct. Without StateSync, it reads stale bootstrap values forever. MUST implement Gate 6." |
| "Reconcilers are optional" | SCOPE_REDUCTION | "Without reconcilers, workers and HTTP policies ignore config changes. Hot-reload is partial." |
| "The service already has systemplane" | COMPLIANCE_BYPASS | "Existence ≠ compliance. MUST run compliance audit. If it doesn't match canonical patterns exactly, it is non-compliant." |
| "Skip code review, we tested it" | QUALITY_BYPASS | "MANDATORY: 8 reviewers. One wiring mistake = silent config corruption or resource leak." |
| "Skip code review, we tested it" | QUALITY_BYPASS | "MANDATORY: 10 reviewers. One wiring mistake = silent config corruption or resource leak." |
| "Agent says out of scope" | AUTHORITY_OVERRIDE | "Skill defines scope, not agent. Re-dispatch with gate context." |
| "ChangeFeed can be added later" | SCOPE_REDUCTION | "Without ChangeFeed, hot-reload is broken. Config changes in DB are invisible to the service. MUST start DebouncedFeed." |
| "Active bundle state is internal detail" | SCOPE_REDUCTION | "Without thread-safe accessor, request handlers cannot read live config. Race conditions. MUST implement active_bundle_state.go." |
@ -255,7 +255,7 @@ MUST report all severities. CRITICAL: STOP immediately. HIGH: Fix before gate pa
| 5 | Identity + Authorization | Always | ring:backend-engineer-golang |
| 6 | Config Manager Bridge | Always | ring:backend-engineer-golang |
| 7 | Wiring + HTTP Mount + Swagger + ChangeFeed | Always ⛔ NEVER SKIPPABLE | ring:backend-engineer-golang |
| 8 | Code Review | Always | 8 parallel reviewers |
| 8 | Code Review | Always | 10 parallel reviewers |
| 9 | User Validation | Always | User |
| 10 | Activation Guide | Always | Orchestrator |
@ -1342,9 +1342,9 @@ go build ./...
## Gate 8: Code Review
**Dispatch 8 parallel reviewers (same pattern as ring:codereview).**
**Dispatch 10 parallel reviewers (same pattern as ring:codereview).**
MUST include this context in ALL 8 reviewer dispatches:
MUST include this context in ALL 10 reviewer dispatches:
> **SYSTEMPLANE REVIEW CONTEXT:**
> - Systemplane is a three-tier configuration system: bootstrap (env, immutable) → runtime (DB, hot-reload) → live-read (snapshot, per-request).
@ -1365,8 +1365,10 @@ MUST include this context in ALL 8 reviewer dispatches:
| ring:consequences-reviewer | Impact on existing config reads, backward compat via StateSync, degradation when store unavailable, shutdown resource cleanup |
| ring:dead-code-reviewer | Orphaned env-reading code, dead config helpers replaced by systemplane, unused YAML/viper imports, stale .env files |
| ring:performance-reviewer | Hot-path allocations in config reads, caching efficiency, systemplane polling overhead, connection pool sizing |
| ring:multi-tenant-reviewer | Systemplane key scoping across tenants, tenant isolation in config snapshots, cross-tenant config leakage prevention |
| ring:lib-commons-reviewer | lib-commons v4 systemplane package adoption, canonical patterns vs custom reimplementations, shared helper reuse |
**⛔ MANDATORY:** All 8 reviewers must PASS. 7/8 = FAIL. Critical findings → fix and re-review.
**⛔ MANDATORY:** All 10 reviewers must PASS. 9/10 = FAIL. Critical findings → fix and re-review.
---
@ -1391,7 +1393,7 @@ MUST approve: present checklist for explicit user approval.
- [ ] Shutdown: clean 5-step resource release on SIGTERM
- [ ] Backward compat: service starts normally without systemplane store (degrades to defaults)
- [ ] Tests pass: `go test ./...`
- [ ] Code review passed: all 8 reviewers PASS
- [ ] Code review passed: all 10 reviewers PASS
```
---
@ -1529,7 +1531,7 @@ Save to `docs/dev-systemplane-migration/current-cycle.json` for resume support:
| "Service already has systemplane code" | Existence ≠ compliance. Code that doesn't follow canonical patterns is WRONG and must be fixed. | STOP. Run compliance audit (Gate 0 Phase 2). Fix every NON-COMPLIANT component. |
| "Partial systemplane is good enough" | Partial = broken. Without ChangeFeed, no hot-reload. Without Mount, no API. Without StateSync, stale config. | STOP. Every component is required. Execute all gates. |
| "The current approach works fine" | Working ≠ compliant. Custom config management creates drift and blocks standardization. | Replace with canonical systemplane implementation. |
| "Skip code review, we tested it" | One wiring mistake = resource leak, config corruption, or silent degradation. 8 reviewers catch what tests miss. | MANDATORY: All 8 reviewers must PASS. |
| "Skip code review, we tested it" | One wiring mistake = resource leak, config corruption, or silent degradation. 10 reviewers catch what tests miss. | MANDATORY: All 10 reviewers must PASS. |
| "ChangeFeed can be added later" | Later = never. Without ChangeFeed, the database is a dead store — changes are invisible. | MUST start DebouncedFeed in Gate 7 |
| "Agent says out of scope" | Skill defines scope, not agent. | Re-dispatch with gate context |
| "Active bundle state is an implementation detail" | Without it, request handlers cannot safely read live config. Race conditions and nil panics. | MUST implement in Gate 7 |

View file

@ -22,7 +22,7 @@ CRITICAL: The following gates enforce mandatory requirements that custom instruc
| Gate | What CANNOT Be Overridden |
|------|---------------------------|
| Gate 3 (Testing) | MUST enforce 85% coverage threshold, TDD RED phase |
| Gate 4 (Review) | MUST dispatch all 8 reviewers |
| Gate 4 (Review) | MUST dispatch all 10 reviewers |
| Gate 5 (Validation) | MUST require user approval |
## Conflict Detection

View file

@ -16,7 +16,7 @@ Runs for every subtask (or task itself if no subtasks). Input scoped to a single
Runs once per task, after all subtasks complete their subtask-level gates. Input is
UNION of all subtasks' changes.
- Backend: Gate 1 (DevOps), Gate 2 (SRE), Gate 4 (Fuzz), Gate 5 (Property), Gate 6 write
(Integration), Gate 7 write (Chaos), Gate 8 (Review — 8 reviewers)
(Integration), Gate 7 write (Chaos), Gate 8 (Review — 10 reviewers)
- Frontend: Gate 1 (DevOps), Gate 2 (Accessibility), Gate 4 (Visual), Gate 5 (E2E),
Gate 6 (Performance), Gate 7 (Review — 5 reviewers)

View file

@ -66,10 +66,10 @@ These rationalizations are always wrong, regardless of context:
|-----------------|----------------|-----------------|
| "Trivial change, skip review" | Security vulnerabilities fit in 1 line. all changes require review. | **Review all changes** |
| "Only N lines changed" | Line count is irrelevant. SQL injection is 1 line. | **Review all changes** |
| "One reviewer is enough" | 8 reviewers catch different issues. All required. | **Dispatch all 8 reviewers** |
| "Run reviewers sequentially" | Sequential = 8x slower. Parallel is REQUIRED. | **Single message, 8 Task calls** |
| "One reviewer is enough" | 10 reviewers catch different issues. All required. | **Dispatch all 10 reviewers** |
| "Run reviewers sequentially" | Sequential = 10x slower. Parallel is REQUIRED. | **Single message, 10 Task calls** |
| "Only MEDIUM issues, can proceed" | MEDIUM = Fix NOW. No deferral, no FIXME. | **Fix MEDIUM issues** |
| "Small fix, no re-review needed" | Small fixes can have big impacts. | **Re-run all 8 reviewers after any fix** |
| "Small fix, no re-review needed" | Small fixes can have big impacts. | **Re-run all 10 reviewers after any fix** |
---

View file

@ -344,6 +344,14 @@ All workflows converge to the 10-gate development cycle:
| **9: Validation** | User approval: APPROVED/REJECTED | User decision |
| **Post-cycle: Multi-Tenant** | Adapt all code for multi-tenant | `ring:backend-engineer-golang` (via `ring:dev-multi-tenant`) |
**Note: Review ≠ Adaptation.**
The `ring:multi-tenant-reviewer` in Gate 8 **audits** multi-tenant compliance but does NOT adapt code. The **Post-cycle: Multi-Tenant** step (via `ring:dev-multi-tenant`) is still required to **actually adapt** code for multi-tenancy — tenant context propagation, database-per-tenant wiring, event-driven tenant discovery registration. The two steps are complementary:
- **Gate 8 (review)**: detects non-compliance in the task's diff.
- **Post-cycle (adaptation)**: performs the actual code changes for multi-tenancy.
Removing the Post-cycle step because "we have a reviewer now" would be a functional regression — reviewers detect, they do not adapt.
**Gate 0 Agent Selection for Frontend:**
- If `docs/pre-dev/{feature}/ux-criteria.md` exists → use `ring:ui-engineer`

View file

@ -81,7 +81,7 @@ These provide context but dilute emphasis when capitalized:
Examples:
- MUST dispatch agent before proceeding to next gate
- STOP and report if PROJECT_RULES.md is missing
- HARD GATE: All 8 reviewers must pass before Gate 5
- HARD GATE: All 10 reviewers must pass before Gate 5
- FORBIDDEN: Reading source code directly as orchestrator
- REQUIRED: WebFetch Ring standards before implementation
- MANDATORY: Save state after every gate transition

View file

@ -231,7 +231,7 @@ Each plugin auto-loads a `using-{plugin}` skill via SessionStart hook to introdu
- Gate 5 — Property Testing
- Gate 6 — Integration Testing (write mode)
- Gate 7 — Chaos Testing (write mode)
- Gate 8 — Review (8 parallel reviewers on cumulative task diff)
- Gate 8 — Review (10 parallel reviewers on cumulative task diff)
**Cycle cadence** (runs once per cycle at the end):
- Gate 6 execute — Integration Testing (execute mode)
@ -246,17 +246,19 @@ Inputs for task-cadence gates receive UNION of changed files across all subtasks
## Parallel Code Review
### Instead of sequential (140 min)
### Instead of sequential (200 min)
```python
review1 = Task("ring:code-reviewer") # 20 min
review2 = Task("ring:business-logic-reviewer") # 20 min
review3 = Task("ring:security-reviewer") # 20 min
review4 = Task("ring:test-reviewer") # 20 min
review5 = Task("ring:nil-safety-reviewer") # 20 min
review6 = Task("ring:consequences-reviewer") # 20 min
review7 = Task("ring:dead-code-reviewer") # 20 min
review8 = Task("ring:performance-reviewer") # 20 min
review1 = Task("ring:code-reviewer") # 20 min
review2 = Task("ring:business-logic-reviewer") # 20 min
review3 = Task("ring:security-reviewer") # 20 min
review4 = Task("ring:test-reviewer") # 20 min
review5 = Task("ring:nil-safety-reviewer") # 20 min
review6 = Task("ring:consequences-reviewer") # 20 min
review7 = Task("ring:dead-code-reviewer") # 20 min
review8 = Task("ring:performance-reviewer") # 20 min
review9 = Task("ring:multi-tenant-reviewer") # 20 min
review10 = Task("ring:lib-commons-reviewer") # 20 min
```
### Run parallel (20 min total)
@ -270,13 +272,15 @@ Task.parallel([
("ring:test-reviewer", prompt),
("ring:consequences-reviewer", prompt),
("ring:dead-code-reviewer", prompt),
("ring:performance-reviewer", prompt)
]) # Single message, 8 tool calls
("ring:performance-reviewer", prompt),
("ring:multi-tenant-reviewer", prompt),
("ring:lib-commons-reviewer", prompt)
]) # Single message, 10 tool calls
```
### Key rule
Always dispatch all 8 reviewers in a single message with multiple Task tool calls.
Always dispatch all 10 reviewers in a single message with multiple Task tool calls.
---

View file

@ -324,7 +324,7 @@ print_summary() {
echo -e " ${BOLD}/ring:brainstorm${NC} - Socratic design refinement"
echo -e " ${BOLD}/ring:dev-cycle${NC} - 10-gate development cycle"
echo -e " ${BOLD}/ring:pre-dev-feature${NC} - Lightweight pre-dev workflow"
echo -e " ${BOLD}/ring:codereview${NC} - Parallel code review (8 reviewers)"
echo -e " ${BOLD}/ring:codereview${NC} - Parallel code review (10 reviewers)"
echo ""
fi
}