🔍 Simon Willison

import anthropic

client = anthropic.Anthropic()

def analyze_with_citations(data: str, question: str) -> str:
    """
    Анализ данных с обязательными цитатами источников.
    Willison-паттерн: каждое утверждение = ссылка на строку данных.
    """
    prompt = f"""Вот данные для анализа:

{data}

Вопрос: {question}

ВАЖНЫЕ ПРАВИЛА:
1. Для каждого факта или вывода — укажи точную строку/запись из данных
2. Используй формат: "Факт X (строка N: [цитата из данных])"
3. Если данных недостаточно для вывода — прямо скажи об этом
4. НЕ ДОДУМЫВАЙ факты которых нет в предоставленных данных
5. Разделяй: "данные показывают" vs "можно предположить"

Ответ:"""

    message = client.messages.create(
        model="claude-opus-4-8",
        max_tokens=2048,
        messages=[{"role": "user", "content": prompt}]
    )
    return message.content[0].text


# Пример использования
with open("sales_data.csv", "r") as f:
    data = f.read()

result = analyze_with_citations(
    data,
    "Какой месяц был самым прибыльным и почему?"
)
print(result)
# Вывод будет содержать: "Март (строка 47: 'март,145000,+23%')"
# а не просто "Март был лучшим месяцем"

import sqlite3
import anthropic

def cc_sql_pipeline(db_path: str, research_question: str) -> dict:
    """
    Willison-паттерн: CC пишет SQL, Python верифицирует,
    только потом CC интерпретирует.
    """
    conn = sqlite3.connect(db_path)
    cursor = conn.cursor()

    # Шаг 1: получить схему для CC
    cursor.execute("SELECT sql FROM sqlite_master WHERE type='table'")
    schema = "\n".join(row[0] for row in cursor.fetchall() if row[0])

    client = anthropic.Anthropic()

    # Шаг 2: CC пишет SQL запрос (только запрос, без интерпретации)
    sql_response = client.messages.create(
        model="claude-opus-4-8",
        max_tokens=512,
        messages=[{
            "role": "user",
            "content": f"""Схема БД:
{schema}

Напиши ТОЛЬКО SQL запрос (без объяснений) для ответа на:
"{research_question}"

Требования: только SELECT, без subqueries сложнее 2 уровней."""
        }]
    )

    sql_query = sql_response.content[0].text.strip()
    # Убрать markdown если CC обернул в ```sql
    if sql_query.startswith("```"):
        sql_query = sql_query.split("\n", 1)[1].rsplit("```", 1)[0].strip()

    # Шаг 3: выполнить запрос и получить РЕАЛЬНЫЕ данные
    try:
        cursor.execute(sql_query)
        results = cursor.fetchmany(100)  # Лимит для безопасности
        columns = [d[0] for d in cursor.description]
    except Exception as e:
        return {"error": str(e), "sql": sql_query}

    # Шаг 4: CC интерпретирует верифицированные данные
    results_text = "\n".join(str(dict(zip(columns, row))) for row in results[:20])
    interpretation = client.messages.create(
        model="claude-opus-4-8",
        max_tokens=1024,
        messages=[{
            "role": "user",
            "content": f"""Реальные результаты SQL запроса:
{results_text}

Вопрос исследования: {research_question}

Интерпретируй ТОЛЬКО то что видно в данных выше.
Каждый вывод — с цитатой из результатов."""
        }]
    )

    conn.close()
    return {
        "sql": sql_query,
        "row_count": len(results),
        "sample": results[:5],
        "interpretation": interpretation.content[0].text
    }

# [CC-DECISION 2026-03-15] Willison-аннотация:
# Задача была: разобрать CSV с непоследовательными датами (3 разных формата).
# CC выбрал dateutil.parser вместо strptime потому что в промпте
# было упомянуто "форматы неизвестны заранее". Если форматы стабилизируются —
# заменить на явный strptime для скорости.
from dateutil import parser as dateutil_parser

def parse_flexible_date(date_str: str):
    """Парсинг даты с неизвестным форматом."""
    return dateutil_parser.parse(date_str)


# [CC-DECISION 2026-03-15] Willison-аннотация:
# Пагинация через cursor вместо offset/limit — CC предложил это
# когда я описал проблему пропуска строк при параллельных вставках.
# offset/limit давал дублирование при изменении данных между запросами.
# Cursor-based pagination решает это. Источник: промпт содержал
# "данные могут изменяться во время экспорта".
def paginate_results(cursor_id: str = None, limit: int = 100):
    query = "SELECT * FROM events WHERE id > ? ORDER BY id LIMIT ?"
    params = (cursor_id or 0, limit)
    return db.execute(query, params).fetchall()

# Ситуация: CC написал что-то и ты не понимаешь зачем
# ПЛОХО: принять код потому что "наверное оно умнее знает"

# ХОРОШО: применить Five Minute Rule

# Промпт 1: объяснение для junior
"Объясни этот код как будто я Junior developer который
 никогда не видел этот паттерн. Почему именно такой подход?
 Какие альтернативы существуют и почему ты выбрал этот?"

# Промпт 2: упрощение
"Этот код решает задачу но я не понимаю зачем нужны
 эти 3 уровня абстракции. Можешь переписать проще,
 даже если будет чуть менее 'правильно'?"

# Промпт 3: явные ограничения
"Перепиши это решение с явными комментариями для каждого
 нетривиального шага. Если используешь паттерн — назови его."

# Промпт 4: trade-offs
"Ты использовал [паттерн X]. Объясни:
 1. Что это даёт в этом контексте
 2. Что это усложняет
 3. При каких условиях стоило бы сделать иначе"

import pytest
from hypothesis import given, strategies as st

# Код написан CC: функция нормализации email
# Тест написан ЧЕЛОВЕКОМ на основе бизнес-требований

from app.utils import normalize_email  # CC написал эту функцию

class TestNormalizeEmail:
    """
    Тесты написаны разработчиком — не CC.
    Каждый тест отражает БИЗНЕС-требование, а не реализацию.
    """

    # Property-based test: hypothesis генерирует сотни случаев
    @given(st.emails())
    def test_result_is_always_lowercase(self, email):
        """Email всегда должен быть в нижнем регистре."""
        result = normalize_email(email)
        assert result == result.lower()

    @given(st.emails())
    def test_result_has_no_leading_trailing_spaces(self, email):
        """Email никогда не должен иметь пробелы по краям."""
        result = normalize_email(f"  {email}  ")
        assert result == result.strip()

    def test_gmail_dots_are_removed(self):
        """Gmail игнорирует точки в local-части — наш нормализатор тоже."""
        assert normalize_email("si.mon.w@gmail.com") == "simonw@gmail.com"

    def test_gmail_plus_addressing_stripped(self):
        """Gmail plus-адреса нормализуются к базовому."""
        assert normalize_email("simon+test@gmail.com") == "simon@gmail.com"

    def test_preserves_non_gmail_plus(self):
        """Для не-Gmail доменов plus оставляем как есть."""
        result = normalize_email("user+tag@company.com")
        assert "+" in result  # company.com может использовать plus

    # Намеренно СЛОМАТЬ реализацию и убедиться что тест падает:
    # normalize_email = lambda x: x  # раскомментировать для проверки
    # pytest должен выдать FAILED — иначе тест бесполезен

# docs/cc-decisions/2026-05-10-payment-refactor.md

## Задача
Рефакторинг PaymentService для поддержки Stripe + YooKassa

## Что попросили CC сделать
"Рефакторни PaymentService чтобы добавить второй провайдер платежей.
 Используй Strategy pattern. Интерфейс должен не меняться для клиентов."

## Что CC предложил
Strategy pattern с PaymentProviderInterface.
Конкретные реализации: StripeProvider, YooKassaProvider.
PaymentService принимает провайдер через DI.

## Что мы изменили после ревью
- CC использовал abstract class вместо interface — изменили на interface
  потому что у нас есть mock для тестов и abstract class с ним плохо дружит
- CC не добавил retry logic — добавили вручную
- Имена методов изменили с execute() на charge() — более явная семантика

## Что НЕ проверяли (риск)
- Обработка webhooks от YooKassa не тестировалась на реальном sandbox
- Refund flow написан CC без покрытия тестами — TODO

## Кто делал ревью
@senior-dev — архитектура
@backend-dev — тесты
CC не участвовал в ревью своего же кода