ring%3adev-implementation（环%3adev 实施）

Code Implementation (Gate 0)

Overview

This skill executes the implementation phase of the development cycle:

• Selects the appropriate specialized agent based on task content
• Applies project standards from docs/PROJECT_RULES.md
• Follows TDD methodology (RED → GREEN → REFACTOR)
• Documents implementation decisions

CRITICAL: Role Clarification

This skill ORCHESTRATES. Agents IMPLEMENT.

Step 1: Validate Input

<verify_before_proceed>

• unit_id exists
• requirements exists
• language is valid (go|typescript|python)
• service_type is valid (api|worker|batch|cli|frontend|bff) </verify_before_proceed>

REQUIRED INPUT (from ring:dev-cycle orchestrator):
- unit_id: [task/subtask being implemented]
- requirements: [acceptance criteria or task description]
- language: [go|typescript|python]
- service_type: [api|worker|batch|cli|frontend|bff]

OPTIONAL INPUT:
- technical_design: [path to design doc]
- existing_patterns: [patterns to follow]
- project_rules_path: [default: docs/PROJECT_RULES.md]

if any REQUIRED input is missing:
  → STOP and report: "Missing required input: [field]"
  → Return to orchestrator with error

Step 2: Validate Prerequisites

<block_condition>

• PROJECT_RULES.md does not exist at project_rules_path </block_condition>

If condition is true, STOP and return error to orchestrator.

1. Check PROJECT_RULES.md exists:
   Read tool → project_rules_path (default: docs/PROJECT_RULES.md)

   if not found:
     → STOP with blocker: "Cannot implement without project standards"
     → Return error to orchestrator

2. Select implementation agent based on language:

   | Language | Service Type | Agent |
   |----------|--------------|-------|
   | go | api, worker, batch, cli | ring:backend-engineer-golang |
   | typescript | api, worker | ring:backend-engineer-typescript |
   | typescript | frontend, bff | frontend-bff-engineer-typescript |

   Store: selected_agent = [agent name]

Step 3: Initialize Implementation State

implementation_state = {
  unit_id: [from input],
  agent: selected_agent,
  tdd_red: {
    status: "pending",
    test_file: null,
    failure_output: null
  },
  tdd_green: {
    status: "pending",
    implementation_files: [],
    pass_output: null
  },
  files_created: [],
  files_modified: [],
  commit_sha: null
}

Step 4: Gate 0.1 - TDD-RED (Write Failing Test)

<dispatch_required agent="[selected_agent]"> Write failing test for unit_id following TDD-RED methodology. </dispatch_required>

Task:
  subagent_type: "[selected_agent]"  # e.g., "ring:backend-engineer-golang"
  description: "TDD-RED: Write failing test for [unit_id]"
  prompt: |
    ⛔ TDD-RED PHASE: Write a FAILING Test

    ## Input Context
    - **Unit ID:** [unit_id]
    - **Requirements:** [requirements]
    - **Language:** [language]
    - **Service Type:** [service_type]

    ## Project Standards
    Read and follow: [project_rules_path]

    ## Standards Source (Cache-First Pattern)

    **Standards Source (Cache-First Pattern):** This sub-skill reads standards from `state.cached_standards` populated by dev-cycle Step 1.5. If invoked outside a cycle (standalone), it falls back to direct WebFetch with a warning. See `shared-patterns/standards-cache-protocol.md` for protocol details.

    ## Ring Standards Reference (Modular)
    Go modules: `https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/golang/{module}.md`
    For TS: `https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/typescript.md`

    **Cache-first loading protocol:**
    For each required standards URL:
      IF state.cached_standards[url] exists:
        → Read content from state.cached_standards[url].content
        → Log: "Using cached standard: {url} (fetched {state.cached_standards[url].fetched_at})"
      ELSE:
        → WebFetch url (fallback — should not happen if orchestrator ran Step 1.5)
        → Log warning: "Standard {url} was not pre-cached; fetched inline"

    **Go minimum for tests:** Load `quality.md` via cache-first pattern → Testing section for test conventions.
    Multi-Tenant: Implement DUAL-MODE from the start (Go only). Use resolvers for all resources — they work transparently in both single-tenant and multi-tenant mode. See TDD-GREEN prompt for full Dual-Mode Implementation section and the sub-package import table.
    Load `https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/golang/multi-tenant.md` via cache-first pattern for patterns.

    ## Frontend TDD Policy (React/Next.js only)
    If the component is purely visual/presentational (layout, styling, animations,
    static display with no behavioral logic), TDD-RED is NOT required.
    Instead, implement the component directly and defer testing to Gate 4 (Visual
    Testing / Snapshots). Report: "Visual-only component → TDD-RED skipped, Gate 4 snapshots apply."

    Behavioral components (custom hooks, form validation, state management,
    conditional rendering, API integration) MUST follow TDD-RED below.

    ## Your Task
    1. Write a test that captures the expected behavior
    2. The test MUST FAIL (no implementation exists yet)
    3. Run the test and capture the FAILURE output

    ## Requirements for Test
    - Follow project naming conventions from PROJECT_RULES.md
    - Use table-driven tests (Go) or describe/it blocks (TS)
    - Test the happy path and edge cases
    - Include meaningful assertion messages

    ## Required Output Format

    ### Test File
    **Path:** [path/to/test_file]

[test code]

    ### Test Execution
    **Command:** [test command]
    **Result:** FAIL (expected)

    ### Failure Output (MANDATORY)

[paste actual test failure output here]

    ⛔ HARD GATE: You MUST include actual failure output.
    Without failure output, TDD-RED is not complete.

Step 5: Validate TDD-RED Output

<block_condition>

• failure_output is missing
• failure_output does not contain "FAIL" </block_condition>

If any condition is true, re-dispatch agent with clarification.

Parse agent output:

1. Extract test file path
2. Extract failure output

if failure_output is missing or does not contain "FAIL":
  → STOP: "TDD-RED incomplete - no failure output captured"
  → Re-dispatch agent with clarification

if failure_output contains "FAIL":
  → implementation_state.tdd_red = {
      status: "completed",
      test_file: [extracted path],
      failure_output: [extracted output]
    }
  → Proceed to Step 6

Step 6: Gate 0.2 - TDD-GREEN (Implementation)

PREREQUISITE: implementation_state.tdd_red.status == "completed"

<dispatch_required agent="[selected_agent]"> Implement code to make test pass following TDD-GREEN methodology. </dispatch_required>

Task:
  subagent_type: "[selected_agent]"
  description: "TDD-GREEN: Implement code to pass test for [unit_id]"
  prompt: |
    ⛔ TDD-GREEN PHASE: Make the Test PASS

    ## Input Context
    - **Unit ID:** [unit_id]
    - **Requirements:** [requirements]
    - **Language:** [language]
    - **Service Type:** [service_type]

    ## TDD-RED Results (from previous phase)
    - **Test File:** [implementation_state.tdd_red.test_file]
    - **Failure Output:**

[implementation_state.tdd_red.failure_output]

    ## Project Standards
    Read and follow: [project_rules_path]

    ## Standards Source (Cache-First Pattern)

    **Standards Source (Cache-First Pattern):** This sub-skill reads standards from `state.cached_standards` populated by dev-cycle Step 1.5. If invoked outside a cycle (standalone), it falls back to direct WebFetch with a warning. See `shared-patterns/standards-cache-protocol.md` for protocol details.

    ## Ring Standards Reference (Modular — Load by Task Type)

    **⛔ MANDATORY: Load the MODULAR standards files below via the cache-first pattern, NOT the monolithic golang.md.**
    The standards are split into focused modules. Load the ones relevant to your task type.

    **Cache-first loading protocol (applies to every URL listed below):**
    For each required standards URL:
      IF state.cached_standards[url] exists:
        → Read content from state.cached_standards[url].content
        → Log: "Using cached standard: {url} (fetched {state.cached_standards[url].fetched_at})"
      ELSE:
        → WebFetch url (fallback — should not happen if orchestrator ran Step 1.5)
        → Log warning: "Standard {url} was not pre-cached; fetched inline"

    ### Go — Module Loading Guide
    Base URL: `https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/golang/`

    | Task Type | REQUIRED Modules to Load (cache-first) |
    |-----------|----------------------------|
    | New feature (full) | `core.md` → `bootstrap.md` → `domain.md` → `quality.md` → `api-patterns.md` |
    | API endpoint | `core.md` → `api-patterns.md` → `domain.md` → `quality.md` |
    | Auth / Security | `core.md` → `security.md` |
    | Database work | `core.md` → `domain.md` → `domain-modeling.md` |
    | Messaging / RabbitMQ | `core.md` → `messaging.md` |
    | Infra / Bootstrap | `core.md` → `bootstrap.md` |
    | Any task | `core.md` is ALWAYS required (lib-commons, license headers, dependency management) |

    ### TypeScript
    URL: `https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/typescript.md`

    Multi-Tenant: Implement DUAL-MODE from the start. Use lib-commons v5 resolvers for ALL resources.
    Load via cache-first pattern: `https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/golang/multi-tenant.md`

    ## ⛔ Multi-Tenant Dual-Mode Implementation (Go backend only — skip for TypeScript/Frontend)

    **Applies only when `language == "go"`.** TypeScript and frontend projects have different patterns.

    All Go backend code must work in BOTH modes from the start. The lib-commons v5 resolvers handle both transparently — in single-tenant mode they return the default connection, in multi-tenant mode they resolve per-tenant. There is NO post-cycle adaptation step.

    ### Sub-Package Import Reference

    | Alias | Import Path | Purpose |
    |-------|-------------|---------|
    | `tmcore` | `github.com/LerianStudio/lib-commons/v5/commons/dispatch layer/core` | Resolvers, context helpers, types |
    | `tmmiddleware` | `github.com/LerianStudio/lib-commons/v5/commons/dispatch layer/middleware` | TenantMiddleware, WhenEnabled |
    | `tmpostgres` | `github.com/LerianStudio/lib-commons/v5/commons/dispatch layer/postgres` | PostgresManager |
    | `tmmongo` | `github.com/LerianStudio/lib-commons/v5/commons/dispatch layer/mongo` | MongoManager |
    | `tmrabbitmq` | `github.com/LerianStudio/lib-commons/v5/commons/dispatch layer/rabbitmq` | RabbitMQ Manager (vhost isolation) |
    | `valkey` | `github.com/LerianStudio/lib-commons/v5/commons/dispatch layer/valkey` | Redis key prefixing |
    | `s3` | `github.com/LerianStudio/lib-commons/v5/commons/dispatch layer/s3` | S3 key prefixing |

    ### Resource Resolver Rules (ALL resources the service uses)

    | Resource | Single-Tenant Pattern (WRONG) | Dual-Mode Pattern (CORRECT) |
    |----------|-------------------------------|------------------------------|
    | **PostgreSQL** | `r.connection.GetDB()` | `tmcore.GetPGContext(ctx)` with fallback to `r.connection` |
    | **PostgreSQL (multi-module)** | `r.connection.GetDB()` | `tmcore.GetPGContext(ctx, module)` with fallback to `r.connection` |
    | **MongoDB** | `r.mongoConn.GetDatabase()` | `tmcore.GetMBContext(ctx)` or `tmcore.GetMBContext(ctx, module)` with fallback |
    | **Redis/Valkey** | `redis.Set("key", val)` | `redis.Set(valkey.GetKeyContext(ctx, "key"), val)` |
    | **S3** | `s3.PutObject("path/obj")` | `s3.PutObject(s3.GetS3KeyStorageContext(ctx, "path/obj"))` |
    | **RabbitMQ** | `channel.Publish(exchange, ...)` | Use `tmrabbitmq.Manager` for vhost isolation + set `X-Tenant-ID` header |

    ### Route Registration with WhenEnabled

    Routes that need tenant context must use `WhenEnabled` — it's a no-op in single-tenant mode:

// Auth MUST run before tenant middleware (per-route, not global) app.Get("/accounts/:id", authMiddleware.Handle, // Always runs multiTenantMiddleware.WhenEnabled(), // No-op when MULTI_TENANT_ENABLED=false handler.GetAccount, )

    ### Backward Compatibility Rule

    The service must work correctly with ZERO `MULTI_TENANT_*` environment variables set. This is the single-tenant default. The resolvers handle this transparently — when `MULTI_TENANT_ENABLED` is not set or is `false`, they return the default connection.

    ### Verification (Go only)

    The agent must verify before completing Gate 0:
    - No direct `r.connection.GetDB()` or `r.mongoConn.GetDatabase()` — must use resolvers
    - No hardcoded Redis keys — must use `valkey.GetKeyContext`
    - No hardcoded S3 keys — must use `s3.GetS3KeyStorageContext`
    - No global DB singletons — connections injected via constructor
    - All methods accept `ctx context.Context` as first parameter
    - Routes use `WhenEnabled()` for tenant middleware (not global `app.Use`)
    - RabbitMQ uses `tmrabbitmq.Manager` (not direct channel operations)

    If any check fails → refactor before gate passes. Do NOT defer to a post-cycle step.

    ## ⛔ FILE SIZE ENFORCEMENT (MANDATORY)
    See [shared-patterns/file-size-enforcement.md](../shared-patterns/file-size-enforcement.md) for cohesion judgment.
    - Soft limit 1000 lines, hard block 1500 lines (including test files)
    - Files 1001-1500 lines: apply cohesion judgment — keep if the file is a single cohesive concern (state machine, parser, schema, table-driven tests, tightly-coupled domain logic) and splitting would force artificial boundaries; otherwise split
    - Splits must reduce cognitive load, not just line count
    - Split by responsibility boundaries (not arbitrary line counts)
    - **Go:** Each split file stays in the same package; all methods remain on the same receiver; verify with `go build ./... && go test ./...`
    - **TypeScript:** Split files stay in the same module/directory; update barrel exports (index.ts) if needed; verify with `tsc --noEmit && npm test`
    - Test files MUST be split to match source files
    - Files > 1500 lines = HARD BLOCK unless cohesion justification is documented in the PR description.
    - Reference: golang/domain.md → File Organization (MANDATORY), typescript.md → File Organization (MANDATORY)

    ## ⛔ CRITICAL: all Ring Standards Apply (no DEFERRAL)

    **You MUST check ALL sections from the modules you loaded.** Not just telemetry — ALL of them.
    See Ring Standards for mandatory requirements including (but not limited to):
    - lib-commons usage (HARD GATE — no duplicate utils/helpers)
    - License headers on all source files
    - Structured JSON logging with trace_id correlation
    - OpenTelemetry instrumentation (spans in every function)
    - Error handling (no panic, wrap with context, sentinel errors)
    - Context propagation
    - Input validation (validator v10)
    - SQL safety (parameterized queries)
    - Secret redaction in logs
    - HTTP status code consistency (201 create, 200 update)
    - Handler constructor pattern (DI via constructor)
    - File organization (≤1000 lines per file; 1001-1500 cohesion review; >1500 hard block)
    - Function design (single responsibility, max 20-30 lines)
    - Database naming (snake_case)

    **⛔ HARD GATE:** If you output "DEFERRED" for any Ring Standard → Implementation is INCOMPLETE.

    ## Your Task
    1. Write MINIMAL code to make the test pass
    2. Follow all Ring Standards (logging, tracing, error handling)
    3. **Instrument all code with telemetry** (100% of handlers, services, repositories)
    4. Run the test and capture the PASS output

    ## ⛔ MANDATORY: Telemetry Instrumentation (NON-NEGOTIABLE)

    <cannot_skip>
    - 90%+ instrumentation coverage required
    - Load standards file via cache-first pattern (state.cached_standards → fallback WebFetch) before implementation
    - Follow exact patterns from standards
    - Output Standards Coverage Table with evidence
    </cannot_skip>

    **every function that does work MUST be instrumented with telemetry.**
    This is not optional. This is not "nice to have". This is REQUIRED.

    ### What "Instrumented" Means
    1. **Extract logger/tracer from context** (not create new ones)
    2. **Create a child span** for the operation
    3. **Defer span.End()** immediately
    4. **Use structured logging** correlated with trace
    5. **Handle errors with span attribution** (business vs technical)

    ### Language-Specific Patterns (MANDATORY)

    **⛔ HARD GATE: Agent MUST load modular standards files (cache-first, WebFetch fallback) BEFORE writing any code.**

    Use the Module Loading Guide above to determine which modules to load.
    **Minimum for ANY Go task:** `core.md` (lib-commons, license headers, deps, MongoDB patterns)

    | Language | Standards Modules | REQUIRED Sections to Load (cache-first) |
    |----------|-------------------|-------------------------------|
    | **Go** | See Module Loading Guide above | ALL sections from loaded modules (use `standards-coverage-table.md` → `ring:backend-engineer-golang` section index) |
    | **TypeScript** | `typescript.md` | ALL 15 sections from `standards-coverage-table.md` → `ring:backend-engineer-typescript` |
    | **All** | N/A (post-cycle ring:dev-multi-tenant) | Multi-tenant adaptation happens after dev-cycle completes |

    **⛔ NON-NEGOTIABLE: Agent MUST implement EXACTLY the patterns from standards. no deviations. no shortcuts.**

    | Requirement | Enforcement |
    |-------------|-------------|
    | Load modular standards files (cache-first, WebFetch fallback) | MANDATORY before implementation |
    | Follow exact patterns | REQUIRED - copy structure from standards |
    | Output Standards Coverage Table | REQUIRED - with file:line evidence for ALL loaded sections |
    | 90%+ instrumentation coverage | HARD GATE - implementation REJECTED if below |
    | All loaded sections ✅ or N/A | HARD GATE - any ❌ = REJECTED |

    ### ⛔ FORBIDDEN Patterns (HARD BLOCK)

    **Agent MUST load standards (cache-first, WebFetch fallback) and check Anti-Patterns table. Violations = REJECTED.**

    - **Go:** `golang.md` → "Anti-Patterns" table - MUST check all rows
    - **TypeScript:** `typescript.md` → "Anti-Patterns" table - MUST check all rows

    **If agent uses any forbidden pattern → Implementation is INVALID. Start over.**

    ### Verification (MANDATORY)

    **Agent MUST output Standards Coverage Table per `standards-coverage-table.md`.**

    - all sections MUST show ✅ or N/A
    - any ❌ = Implementation REJECTED
    - Missing table = Implementation INCOMPLETE

    ## Required Output Format

    ### Implementation Files
    | File | Action | Lines |
    |------|--------|-------|
    | [path] | Created/Modified | +/-N |

    ### Code
    **Path:** [path/to/implementation_file]

[implementation code]

    ### Test Execution
    **Command:** [test command]
    **Result:** PASS

    ### Pass Output (MANDATORY)

[paste actual test pass output here]

    ### Standards Coverage Table (MANDATORY)

    **Standards Modules Loaded:** [list modules loaded via cache-first pattern; note cache hit/miss per module]
    **Total Sections Checked:** [N]

    | # | Section (from standards) | Status | Evidence |
    |---|------------------------|--------|----------|
    | 1 | [section name] | ✅/⚠️/❌/N/A | file:line or reason |
    | ... | ... | ... | ... |

    **Completeness:** [N] sections checked / [N] total = ✅ Complete

    ⛔ This table is MANDATORY. Missing table = Implementation INCOMPLETE.
    ⛔ Any ❌ = Implementation REJECTED. Fix before proceeding.

    ### Standards Compliance Summary

    **Quick reference derived from the Standards Coverage Table above.**
    If any item is ❌ here, it MUST also appear as ❌ in the Coverage Table with file:line evidence.

    - lib-commons Usage: ✅/❌
    - License Headers: ✅/❌
    - Structured Logging: ✅/❌
    - OpenTelemetry Spans: ✅/❌
    - Error Handling: ✅/❌
    - Context Propagation: ✅/❌
    - Input Validation: ✅/❌/N/A
    - SQL Safety: ✅/❌/N/A
    - File Size (≤1000 lines soft / ≤1500 hard; 1001-1500 cohesion review): ✅/❌

    ### Commit
    **SHA:** [commit hash after implementation]

Step 7: Validate TDD-GREEN Output

Parse agent output:

1. Extract implementation files
2. Extract pass output
3. Extract standards compliance
4. Extract commit SHA

if pass_output is missing or does not contain "PASS":
  → STOP: "TDD-GREEN incomplete - test not passing"
  → Re-dispatch agent with error details

if Standards Coverage Table is missing:
  → STOP: "Standards Coverage Table not provided - implementation INCOMPLETE"
  → Re-dispatch agent: "You MUST output a Standards Coverage Table with one row per section from the modules you loaded. See standards-coverage-table.md for format."

if any section in Standards Coverage Table is ❌:
  → STOP: "Standards not met - [list ❌ sections with evidence]"
  → Re-dispatch agent to fix specific sections

if any standards compliance summary is ❌:
  → STOP: "Standards not met - [list failing standards]"
  → Re-dispatch agent to fix

if pass_output contains "PASS" and all standards ✅ and Standards Coverage Table complete:
  → Run file-size verification (see shared-patterns/file-size-enforcement.md):
    Go: find . -name "*.go" ! -path "*/mocks*" ! -path "*/generated/*" ! -path "*/gen/*" ! -name "*.pb.go" ! -name "*.gen.go" -exec wc -l {} + | awk '$1 > 1000 && $NF != "total" {print}' | sort -rn
    TS: find . \( -name "*.ts" -o -name "*.tsx" \) ! -path "*/node_modules/*" ! -path "*/dist/*" ! -path "*/build/*" ! -path "*/generated/*" ! -path "*/__mocks__/*" ! -name "*.d.ts" ! -name "*.gen.ts" -exec wc -l {} + | awk '$1 > 1000 && $NF != "total" {print}' | sort -rn

  if any file > 1500 lines:
    → HARD BLOCK: "File [path] has [N] lines (hard block at 1500). MUST split before proceeding unless cohesion justification is documented in the PR description."
    → Re-dispatch agent with split instructions from shared-patterns/file-size-enforcement.md

  if any file 1001-1500 lines:
    → COHESION REVIEW: "File [path] has [N] lines. Apply cohesion judgment — keep if single cohesive concern (state machine, parser, schema, table-driven tests, tightly-coupled domain logic); split if fragmentable without artificial boundaries."
    → Re-dispatch agent with file path and cohesion-judgment prompt

  → Run linting verification (R4 — quality.md mandates 14 linters):
    Go: if .golangci.yml exists, run: golangci-lint run ./...
         if .golangci.yml does not exist, flag as warning (quality.md requires it)
    TypeScript: if eslint config exists, run: npx eslint . --ext .ts,.tsx

  if linting fails:
    → Re-dispatch agent: "Linting failed. Fix all lint issues before proceeding. Output: [lint errors]"

  → Run license header check (R5 — core.md License Headers MANDATORY):
    For each file in [files_created + files_modified] matching *.go, *.ts, *.tsx:
      Check first 10 lines for: copyright|licensed|spdx|license (case-insensitive)
      If not found → flag as missing

  if any file missing license header:
    → Re-dispatch agent: "Missing license headers in: [file list]. Add license headers per core.md → License Headers (MANDATORY)."

  if all checks pass:
    → implementation_state.tdd_green = {
        status: "completed",
        implementation_files: [extracted files],
        pass_output: [extracted output],
        commit_sha: [extracted SHA],
        file_size: "PASS",
        linting: "PASS",
        license_headers: "PASS"
      }
    → Proceed to Step 8

Step 7: Delivery Verification Exit Check (MANDATORY)

Before emitting the "Ready for Gate 1: YES" handoff, verify that every requirement in the task/subtask's acceptance criteria is DELIVERED (reachable, integrated, not dead code).

Checks to run

Check 1: Requirement Coverage Matrix (MANDATORY)

For each acceptance criterion in input.requirements:

• Locate the file(s) that implement it
• Verify it's callable from a public entry point (handler, route, CLI command)
• Mark as ✅ DELIVERED | ⚠️ PARTIAL | ❌ NOT DELIVERED

Check 2: Dead Code Detection (MANDATORY)

For each newly-created struct/interface/function in files_changed:

• Verify it's referenced from at least one caller (other than tests)
• If created but uncalled → dead code item

Check 3: Integration Verification (MANDATORY)

• New middleware MUST be wired into router/server
• New repositories MUST be registered in DI container
• New types MUST be exported where consumers expect them

Output (added to handoff to Gate 1)

delivery_verification:
  result: "PASS" | "PARTIAL" | "FAIL"
  requirements_total: N
  requirements_delivered: N
  requirements_missing: N
  dead_code_items: N

Decision gate

IF result!= "PASS":

• Re-run Step 6 (TDD-GREEN) with remediation instructions
• Max 2 retries before escalating to orchestrator

IF result == "PASS":

• Proceed to Handoff to Next Gate

Reference

The full delivery verification checklist is embedded in Step 7 below and in Gate 0.5G of ring:dev-cycle.

Step 8: Prepare Output

Generate skill output:

## Implementation Summary
**Status:** PASS
**Unit ID:** [unit_id]
**Agent:** [selected_agent]
**Commit:** [commit_sha]

## TDD Results
| Phase | Status | Output |
|-------|--------|--------|
| RED | ✅ | [first line of failure_output] |
| GREEN | ✅ | [first line of pass_output] |

## Files Changed
| File | Action | Lines |
|------|--------|-------|
[table from implementation_files]

**Files Created:** [count]
**Files Modified:** [count]
**Tests Added:** [count]

## Standards Compliance
- Structured Logging: ✅
- OpenTelemetry Spans: ✅
- Error Handling: ✅
- Context Propagation: ✅
- File Size (≤1000 lines soft / ≤1500 hard; 1001-1500 cohesion review): ✅
## Handoff to Next Gate
- Implementation status: COMPLETE
- Code compiles: ✅
- Tests pass: ✅
- Standards met: ✅
- Ready for Gate 1 (DevOps): YES
- Environment needs: [list any new deps, env vars, services]

delivery_verification:
  result: "PASS|PARTIAL|FAIL"
  requirements_total: integer
  requirements_delivered: integer
  requirements_missing: integer
  dead_code_items: integer

Severity Calibration

Report all severities. CRITICAL = immediate block. HIGH = fix before proceeding. MEDIUM = fix in iteration. LOW = document.

Pressure Resistance

See shared-patterns/shared-pressure-resistance.md for universal pressure scenarios.

Anti-Rationalization Table

See shared-patterns/shared-anti-rationalization.md for universal anti-rationalizations.

Gate 0-Specific Anti-Rationalizations

⛔ Post-Generation Panic Check (MANDATORY)

Before delivering ANY generated code, run these checks:

If any check fails: DO NOT deliver. Fix first.

Agent Selection Guide

ui-engineer Selection: When implementing frontend features with product-designer outputs (ux-criteria.md, user-flows.md, wireframes/), use ring:ui-engineer instead of ring:frontend-bff-engineer-typescript. The ui-engineer specializes in translating design specifications into production code while ensuring all UX criteria are satisfied.

Execution Report Format

## Implementation Summary
**Status:** [PASS|FAIL|PARTIAL]
**Unit ID:** [unit_id]
**Agent:** [agent]
**Duration:** [Xm Ys]

## TDD Results
| Phase | Status | Output |
|-------|--------|--------|
| RED | ✅/❌ | [summary] |
| GREEN | ✅/❌ | [summary] |

## Files Changed
| File | Action | Lines |
|------|--------|-------|
| [path] | [Created/Modified] | [+/-N] |

## Standards Compliance
- Structured Logging: ✅/❌
- OpenTelemetry Spans: ✅/❌
- Error Handling: ✅/❌
- Context Propagation: ✅/❌

## Handoff to Next Gate
- Implementation status: [COMPLETE|PARTIAL]
- Ready for Gate 1: [YES|no]
- Environment needs: [list]