Какие файлы нужно тронуть, чтобы изменить одну функцию? Достаточно указать один operationId.
Проблема
В fullstack-приложении «одна функция» не живёт в одном файле.
Допустим, нужно изменить функцию «Принять предложение (AcceptProposal)». Она присутствует в API-спецификации, в сервисной логике, в схеме базы данных, в политике авторизации, в диаграмме состояний, во внешних вызовах функций, в тестовых сценариях и во фронтенде.
Раньше существовало два способа понять весь охват изменений:
- Запустить grep десятки раз
- Вручную отследить код
Оба медленные, оба дают пропуски. Особенно сложно человеку без пробелов проследить ссылки, пересекающие слои — из API-спецификации в сервис, из сервиса в схему БД, из сервиса в политику авторизации.
Но если источники каждого слоя символически ссылаются друг на друга, достаточно проследовать по этим ссылкам — и весь охват раскроется автоматически.
Что такое Feature Chain
Feature Chain — это извлечение всех узлов исходного кода, связанных с одной API-функцией (operationId).
Начиная с одного operationId, инструмент следует по символическим ссылкам между источниками и выводит все связанные файлы с номерами строк за одну команду. Десятки grep-запросов заменяются одной командой.
fullend chain AcceptProposal specs/
── Feature Chain: AcceptProposal ──
OpenAPI api/openapi.yaml:296 POST /proposals/{id}/accept
SSaC service/proposal/accept_proposal.ssac:19 @get @empty @auth @state @put @call @post @response
DDL db/gigs.sql:1 CREATE TABLE gigs
DDL db/proposals.sql:1 CREATE TABLE proposals
DDL db/transactions.sql:1 CREATE TABLE transactions
Rego policy/authz.rego:3 resource: gig
StateDiag states/gig.md:7 diagram: gig → AcceptProposal
StateDiag states/proposal.md:6 diagram: proposal → AcceptProposal
FuncSpec func/billing/hold_escrow.go:8 @func billing.HoldEscrow
Gherkin scenario/gig_lifecycle.feature:4 Scenario: Happy Path - Full Gig Lifecycle
Gherkin scenario/gig_lifecycle.feature:42 Scenario: Unauthorized Access
Вся структура одной функции видна на одном экране. Слои без связи не выводятся.
Почему это возможно
Никакой магии. Это работает потому, что источники уже ссылаются друг на друга.
В фреймворке fullend каждый слой SSOT (Single Source of Truth) символически указывает на другие слои:
- SSaC
@get Model.Method→ таблица DDL - SSaC
@auth action resource→ политика авторизации Rego - SSaC
@state diagramID→ диаграмма состояний Mermaid - SSaC
@call pkg.Func→ реализация Func Spec - OpenAPI operationId → имя файла SSaC
- Gherkin action step → operationId
- STML endpoint → OpenAPI path
Эти ссылки изначально разработаны для crosscheck — инструмента проверки согласованности между SSOT. Поскольку crosscheck уже парсит эти ссылки, повторное использование той же инфраструктуры позволяет извлечь feature chain простым обходом графа.
Путь обхода
Начиная с operationId, граф ссылок разворачивается следующим образом:
operationId (начальная точка)
├── OpenAPI → path + method
├── SSaC → файл сервисной функции
│ ├── @get → таблицы DDL
│ ├── @auth → правила политики Rego
│ ├── @state → переходы Mermaid stateDiagram
│ ├── @call → реализации Func Spec
│ └── @publish → подписчики очереди
├── Gherkin → сценарии, ссылающиеся на operationId
└── STML → файлы фронтенда, ссылающиеся на endpoint
Каждая ветвь следует лишь одному уровню символических ссылок. Это широкий, а не глубокий обход. Всё, что функция затрагивает в каждом слое, становится видимым.
Что это меняет
Определение охвата изменений
«Что нужно тронуть, чтобы исправить эту функцию?»
Чтобы ответить на этот вопрос, мы читаем код, запускаем grep, спрашиваем коллег. Feature Chain заменяет этот вопрос одной командой. Ни один файл не пропустится — пока существует символическая ссылка.
Правки кода с помощью AI
Самое сложное при поручении правки функции AI — «объяснить область изменений». Чтобы AI точно внёс правки, нужно положить все связанные файлы в контекстное окно, но человек должен сам решить, какие файлы связаны.
С Feature Chain всё иначе. Достаточно указать один operationId — и весь охват изменений определяется автоматически. Контекст для AI подготовлен без пропусков.
Code review
При ревью PR подозрение «если эту функцию изменили, значит и тот файл должен был измениться» легко проверить, сопоставив с chain. Структура, а не человек, ловит несоответствия между слоями.
Онбординг
Когда новый разработчик спрашивает «хочу понять, как работает AcceptProposal», достаточно показать один Feature Chain. От API до БД, от политики авторизации до тестовых сценариев — вся топография функции видна с первого взгляда.
Почему именно operationId
Выбор начальной точки имеет значение. Feature Chain остановился на operationId.
Причина проста. В fullstack-приложении единица функциональности — это API-эндпоинт. Пользователь нажимает кнопку → вызывается API → выполняется сервисная логика → читается БД → проверяется авторизация → происходит переход состояния. Начальная точка всего этого потока — operationId.
operationId уже определён в OpenAPI-спецификации и является именем, которое разделяет вся команда. Когда говорят «нужно изменить AcceptProposal», и backend-разработчик, и frontend-разработчик, и QA представляют одно и то же. Одно универсальное имя, пронизывающее весь стек, — такова идея Feature Chain.
Предварительные условия
Для работы Feature Chain необходимо следующее:
Источники должны символически ссылаться друг на друга. Директивы
@get,@auth,@state,@callв SSaC должны явно указывать на другие SSOT. Если ссылки неявные — например, имя таблицы БД существует лишь как строка внутри кода — отследить их невозможно.Crosscheck должен проходить. Feature Chain следует по символическим ссылкам, поэтому недействительные ссылки дадут неверный результат. Crosscheck гарантирует согласованность ссылок, Feature Chain работает поверх этого.
Именно поэтому Feature Chain — не универсальный инструмент. Его нельзя применить к любому проекту. Он работает только в проектах с явными ссылками между источниками — структурах, подобных fullend, где SSOT явно указывают друг на друга.
Будущее: GEUL + SILK
Сейчас Feature Chain обходит парсеры каждого SSOT поочерёдно. Он вызывает парсеры SSaC, DDL, Rego, Mermaid по отдельности и объединяет результаты.
Когда все SSOT будут преобразованы в граф GEUL, Feature Chain станет запросом к единому индексу. С помощью побитовой операции AND в SIDX фреймворка SILK все узлы, связанные с operationId, можно будет извлечь одним запросом.
От пообходного обхода парсеров к запросу к графу. Интерфейс Feature Chain останется прежним, но внутреннее устройство изменится кардинально.
Итог
В fullstack-приложении «функция» не живёт в одном файле. Она распределена по слоям, и эти слои ссылаются друг на друга. Feature Chain следует по этим ссылкам и автоматически извлекает весь охват одной функции.
Один operationId на входе — от API-спецификации до схемы БД, от политики авторизации до тестовых сценариев. Десятки grep-запросов заменяются одной командой.