Symmetric Dogfooding

Symmetric Dogfooding

Bidirectional integration validation pattern where two repositories each consume the other for testing, ensuring both sides work correctly together before downstream adoption.

Self-Evolving Skill: This skill improves through use. If instructions are wrong, parameters drifted, or a workaround was needed — fix this file immediately, don't defer. Only update for real, reproducible issues.

Pattern Overview

┌─────────────────────────────────────────────────────────────────┐
│                    SYMMETRIC DOGFOODING                         │
│                                                                 │
│        Repo A ◄─────── mutual validation ───────► Repo B        │
│                                                                 │
│   EXPORTS:                              EXPORTS:                │
│   - Library/API                         - Library/API           │
│   - Data structures                     - Data structures       │
│                                                                 │
│   VALIDATES WITH:                       VALIDATES WITH:         │
│   - Repo B real outputs                 - Repo A real outputs   │
│   - Production-like data                - Production-like data  │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

When to Use This Skill

Use this skill when:

• Two repos have a producer/consumer relationship
• APIs evolve independently and need integration testing
• Data formats may drift between repos
• Both repos are actively developed

---

TodoWrite Task Templates

Template A: Setup Symmetric Dogfooding Between Two Repos

1. Identify integration surface (exports from A consumed by B and vice versa)
2. Document data formats, schemas, API signatures at boundary
3. Configure cross-repo dev dependencies in both repos
4. Pin versions explicitly (tags or SHAs, never main)
5. Create integration/ test directory in both repos
6. Write bidirectional validation tests (A validates with B outputs, B validates with A outputs)
7. Add validation tasks to mise.toml or Makefile
8. Document pre-release protocol in both CLAUDE.md files
9. Run full symmetric validation to verify setup
10. Verify against Symmetric Dogfooding Checklist below

Template B: Pre-Release Validation

1. Run validate:symmetric task in releasing repo
2. Check if other repo has pending changes affecting integration
3. If yes, test against other repo's feature branch
4. Document any failures in validation log
5. Fix integration issues before release
6. Update version pins after successful validation
7. Coordinate if breaking changes require simultaneous release
8. Verify against Symmetric Dogfooding Checklist below

Template C: Add New Integration Point

1. Identify new export/import being added
2. Update integration surface documentation
3. Add tests in both repos for new integration point
4. Run symmetric validation in both directions
5. Update version pins if needed
6. Verify against Symmetric Dogfooding Checklist below

Symmetric Dogfooding Checklist

After ANY symmetric dogfooding work, verify:

• [ ] Both repos have integration tests that import the other
• [ ] Version pins are explicit (tags or commit SHAs)
• [ ] Pre-release checklist includes cross-repo validation
• [ ] Integration tests use real data (not mocks of the other repo)
• [ ] Breaking changes coordination documented
• [ ] Validation task runnable via single command

---

Post-Change Checklist (Self-Maintenance)

After modifying THIS skill:

1. [ ] Templates cover common symmetric dogfooding scenarios 2. [ ] Checklist reflects current best practices 3. [ ] Example in references/ still accurate 4. [ ] Append changes to evolution-log.md

---

Implementation Guide

Phase 1: Discovery and Mapping

Identify the integration surface:

• List all exports from Repo A consumed by Repo B
• List all exports from Repo B consumed by Repo A
• Document data formats, schemas, API signatures

Map validation scenarios:

• What real-world data from B can validate A outputs?
• What real-world data from A can validate B outputs?
• Identify edge cases that only appear in production usage

Phase 2: Dependency Configuration

Configure cross-repo dev dependencies:

Python (uv/pip):

# Repo A pyproject.toml
[project.optional-dependencies]
validation = ["repo-b"]

[tool.uv.sources]
repo-b = { git = "https://github.com/org/repo-b", tag = "<tag>" }  # SSoT-OK

# Repo B pyproject.toml
[project.optional-dependencies]
validation = ["repo-a"]

[tool.uv.sources]
repo-a = { git = "https://github.com/org/repo-a", tag = "<tag>" }  # SSoT-OK

Rust (Cargo):

[dev-dependencies]
repo-b = { git = "https://github.com/org/repo-b", tag = "<tag>" }  # SSoT-OK

Node.js:

{
  "devDependencies": {
    "repo-b": "github:org/repo-b#<tag>"
  }
}

Critical: Pin to tags or commit SHAs. Never use main/master branches.

Phase 3: Test Infrastructure

Directory structure in both repos:

repo-a/
└── tests/
    ├── unit/              # Internal tests
    └── integration/       # Tests using repo-b real outputs
        └── test_with_repo_b.py

repo-b/
└── tests/
    ├── unit/              # Internal tests
    └── integration/       # Tests using repo-a real outputs
        └── test_with_repo_a.py

Bidirectional validation test pattern:

# repo-a/tests/integration/test_with_repo_b.py
"""Validate Repo A outputs work correctly with Repo B inputs."""

def test_a_output_consumed_by_b():
    # Generate output using Repo A
    a_output = repo_a.generate_data()

    # Feed to Repo B - should work without errors
    b_result = repo_b.process(a_output)

    # Validate the round-trip
    assert b_result.is_valid()

Phase 4: Task Automation

mise.toml example:

[tasks."validate:symmetric"]
description = "Validate against partner repo"
run = """
uv sync --extra validation
uv run pytest tests/integration/ -v
"""

[tasks."validate:pre-release"]
description = "Full validation before release"
depends = ["test:unit", "validate:symmetric"]

Phase 5: Pre-Release Protocol

Before releasing Repo A:

1. Run validate:symmetric in Repo A (tests against current Repo B) 2. If Repo B has pending changes, test against Repo B branch too 3. Update version pins after successful validation

Before releasing Repo B:

1. Run validate:symmetric in Repo B (tests against current Repo A) 2. If Repo A has pending changes, test against Repo A branch too 3. Update version pins after successful validation

Coordinating breaking changes:

• If A needs to break compatibility, update B first
• If B needs to break compatibility, update A first
• Consider simultaneous releases for tightly coupled changes

---

Anti-Patterns

---

References

• example-setup.md - Real-world trading-fitness/rangebar-py example
• evolution-log.md - Skill change history

External:

• Dogfooding (DevIQ)
• CDC Testing (Microsoft)

---

Troubleshooting

Post-Execution Reflection

After this skill completes, reflect before closing the task:

0. Locate yourself. — Find this SKILL.md's canonical path before editing. 1. What failed? — Fix the instruction that caused it. 2. What worked better than expected? — Promote to recommended practice. 3. What drifted? — Fix any script, reference, or dependency that no longer matches reality. 4. Log it. — Evolution-log entry with trigger, fix, and evidence.

Do NOT defer. The next invocation inherits whatever you leave behind.

Evolution Log

Reverse chronological record of skill changes.

---

2026-01-27: Initial Creation

• Created symmetric-dogfooding skill
• Added TodoWrite templates for setup, pre-release, and new integration points
• Added implementation guide with phase-based approach
• Added anti-patterns section
• Created example-setup.md reference with trading-fitness/rangebar-py case

Example: trading-fitness and rangebar-py

Real-world symmetric dogfooding implementation between two polyrepos.

Integration Surface

trading-fitness ◄──────────────────────► rangebar-py

trading-fitness EXPORTS:              rangebar-py EXPORTS:
- ITH metrics (PyO3 bindings)         - Range bar construction
- Bounded [0,1] LSTM features         - Microstructure features
- Rolling window computation          - Tick data aggregation

trading-fitness VALIDATES WITH:       rangebar-py VALIDATES WITH:
- rangebar range bars                 - trading-fitness ITH metrics
- Real Binance market data            - Real NAV series from bars

Dependency Configuration

trading-fitness side:

# packages/ith-python/pyproject.toml
[project.optional-dependencies]
validation = ["rangebar"]

[tool.uv.sources]
rangebar = { git = "https://github.com/terrylica/rangebar-py", tag = "<tag>" }  # SSoT-OK

rangebar-py side (if implementing full pattern):

# pyproject.toml
[project.optional-dependencies]
validation = ["trading-fitness-metrics"]

[tool.uv.sources]
trading-fitness-metrics = {
    git = "https://github.com/terrylica/trading-fitness",
    subdirectory = "packages/metrics-rust",
    tag = "<tag>"  # SSoT-OK
}

Validation Flow

1. trading-fitness runs E2E pipeline
   └── Uses rangebar to fetch range bars from Binance
   └── Computes ITH features on real market data
   └── Validates feature bounds [0,1]

2. rangebar-py (hypothetical) runs validation
   └── Uses trading-fitness ITH on constructed bars
   └── Validates metrics work on edge cases
   └── Confirms API compatibility

Pre-Release Coordination

When releasing rangebar-py:

1. Run trading-fitness E2E with new rangebar version 2. Verify no breaking changes in range bar format 3. Update trading-fitness version pin 4. Release rangebar-py

When releasing trading-fitness:

1. Run ITH tests with current rangebar version 2. Verify feature outputs remain bounded 3. Coordinate if API changes affect rangebar consumers 4. Release trading-fitness

Lessons Learned

1. Checksum verification - rangebar-py added SHA-256 verification after trading-fitness identified the need (issue #43) 2. Polars schema compatibility - Discovered datetime precision mismatch (μs vs ns) during cross-repo testing (issue #44) 3. Version pinning - Always pin to tags, not main branch, to avoid surprise breaks