// tier: vasic-util-secondary · order 24

DocProcessor activelicense: Apache-2.0

Go (1.25+)LLM agents (optional extraction)Heuristic parser (offline fallback)i18n Translator (pkg/i18n)Challenge harness

Source

DocProcessor — dual extractor → HelixQA convergence Dual-extractor switch one path or the other Coverage Documentation product docs DocProcessor Go 1.25+ extractor LLM agent path optional extraction Heuristic parser offline fallback Feature map documented features HelixQA proves evidence · convergence Coverage matrix documented vs verified %
// architecture

Змест Ператварыце дакументацыю ў правераную карту функцый для аўтаматызацыі кантролю якасці.

DocProcessor — гэта аўтаномны, цалкам дэкапліраваны модуль Go, які загружае дакументацыю праекта, стварае структурызаваныя карты функцый і адсочвае пакрыццё праверкі. Ён распрацаваны для працы з агентамі LLM для інтэлектуальнага вымання функцый, але таксама ўключае эўрыстычнае выманне для аўтаномнага выкарыстання.

Агностычны да праекта модуль Go для апрацоўкі дакументацыі і вымання карт функцый. Ён парсіць дакументы ў структурызаваныя карты функцый і адсочвае, якія функцыі правераны — выкарыстоўваючы агенты LLM для інтэлектуальнага вымання або эўрыстыку ў аўтаномным рэжыме — і забяспечвае аўтаматызацыю кантролю якасці анты-блефавай гарантыяй, якая заўсёды адпавядае рэальнасці.

Кожная каманда распрацоўшчыкаў жыве з адной і той жа павольнай хлуснёй: дакументацыя абяцае функцыі, тэсты пакрываюць нешта іншае, і ніхто не можа з упэўненасцю сказаць, ці апісваюць яны адзін і той жа прадукт. DocProcessor існуе, каб зрабіць гэтую прабелю бачнай і вымернай. На падставе дакументацыі праекта ён стварае структурызаваную карту функцый — пералічаны, прыдатны для машыннай апрацоўкі мадэль усяго, што прадукт абяцае рабіць — і адсочвае пакрыццё праверкі ў адносінах да яе, каб пытанне «ці правераная гэтая дакументаваная функцыя насамрэч?» перастала быць спрэчкай у калідоры і ператварылася ў запыт з адказам. Ён наўмысна двухрэжымны: выкарыстоўвае агенты LLM для інтэлектуальнага, семантычнага вымання функцый, калі яны даступныя, і пераходзіць на эўрыстычны парсер для поўнага аўтаномнага выкарыстання, каб ніколі не залежаць ад наяўнасці мадэлі і працаваць аднолькава як у ізаляваным CI-заданні, так і на ноўтбуку распрацоўшчыка ў рэжыме самалёта.

Архітэктурна гэта аўтаномны, не прывязаны да праекта, цалкам дэкапліраваны модуль Go (CONST-051(B)): ён не ўключае ніякіх спецыфічных для праекта значэнняў і ўбудоўваецца спажыўцамі як падмодуль з роўным кодэксам, каб любы праект мог яго прыняць без атрымання чужаземных здагадак. Ён таксама прытрымліваецца тых самых стандартаў, якія навязвае іншым — яго ўласныя сцвярджэнні падпарадкаваны анты-блефавай дамове (CONST-035) і правілам поўнага аўтаматызаванага пакрыцця (CONST-048), што азначае, што кожная магчымасць, абвешчаная ў яго README, правяраецца аўтаматызаваным тэстам або Challenge-скрыптам, які пацвярджае рэальную, прыдатную для канчатковага карыстальніка паводзіны, а не проста выходзіць з нулявым статусам; карыстальніцкія радкі праходзяць праз перакладчык інтэрнацыяналізацыі CONST-046. Сэнс усяго гэтага — замкнуты цыкл: DocProcessor з’яўляецца ўваходным бокам цыклу кантролю якасці, які замыкае HelixQA — ён выманяе карту функцый з дакументаў, HelixQA пацвярджае кожную нанесеную на карту функцыю захопленымі сведчаннямі часу выканання, і дакументацыя, тэсты і рэальная паводзіны прадукту вымушаны сыходзіцца, замест таго каб ціха разыходзіцца з версіі ў версію.

Дакументацыя і тэсты разыходзяцца: дакументы абяцаюць функцыі, якія не правяраюцца ніякімі тэстамі, а кантроль якасці не можа лёгка вызначыць, што азначае «поўнае пакрыццё». DocProcessor ператварае дакументы ў прыдатную для машыннай апрацоўкі карту функцый, каб пакрыццё праверкі можна было вымяраць у адносінах да таго, што было сапраўды абяцана.

Змесціва

Гэта ператварае найбольш нявызначанае пытанне ў дастаўцы праграмнага забеспячэння — *«Ці адпавядае тое, што мы адправілі, таму, што мы казалі, што адправілі?»* — у нешта, што можна аўтаматызаваць і правяраць бесперапынна. І робіць гэта без жорсткай залежнасці ад AI: LLM-экстракцыя, калі мадэль даступна, эўрыстыкі — калі не, так што адна і тая ж гарантыя дзейнічае ў любым асяроддзі — ад аўтаномнага апрацоўшчыка да поўнаагентнага канвеера.

  • Экстракцыя карты дакументацыі-да-функцыяналу з адсочваннем пакрыцця праверкі.
  • Двайная экстракцыя: на аснове LLM-агентаў ці эўрыстык/афлайн.
  • Незалежнасць ад праекта, дэкаплінг без канфігурацыі (CONST-051(B)).
  • Антыблефная самаправерка: сцвярджэнні ў README падмацаваны тэстамі/Challenge’амі (CONST-035/048).

  • Работа без мадэлі: вырашана праз эўрыстычны экстрактар-фалабек, што дазваляе модулю працаваць афлайн.
  • Сінхранізацыя дакументацыі і рэальнасці: вырашана праз структурызаваныя карты функцыяналу + адсочванне пакрыцця праверкі, інтэграваныя ў цыкл забеспячэння якасці.
  • Перавыкарыстанне: вырашана праз строгі дэкаплінг і спажыванне субмодуляў у адзінай кодовай базе.
  • Давер да ўласных сцвярджэнняў: вырашана праз антыблефныя тэсты/Challenge’і для кожнай дэклараванай магчымасці.

  • Go (1.25+) — ядро модуля; ліцэнзія Apache-2.0.
  • LLM-агенты — інтэлектуальная семантычная экстракцыя функцыяналу (неабавязкова).
  • Эўрыстычны парсер — фалабек для афлайн-экстракцыі функцыяналу.
  • i18n Translator (pkg/i18n) — лакалізаваныя радкі паводле CONST-046.
  • Challenge-харанес — антыблефная праверка ўласных сцвярджэнняў модуля.