n7n-plugin-host 0.1.5

package n7n:fix-deps@0.1.0;

// `verify` — канонічна перевірка між ходами циклу `fix`, дзеркало поля
// `llm_lib::attempt::FixDeps::verify`
// (`Arc<dyn Fn() -> BoxFuture<'static, VerifyReport>>`).
//
// ВІДКРИТЕ ПИТАННЯ СПЕКИ (`docs/specs/2026-08-17-n7n-harness-local-models.md`,
// розділ "Відкриті питання"): "чи `verify` взагалі може бути
// wasm-компонентом. Канонічна перевірка часто означає запуск зовнішнього
// тулчейна, а guest процесів не спавнить."
//
// ВІДПОВІДЬ, ВИМІРЯНА на `7n-rules/crates/rules-core` і `rules-fix`
// (read-only, нічого там не змінено):
//
//   - `rules-core::concerns` реєструє 58 native-концернів
//     (`crate::concerns::*`, диспатч `run_concern`). З них РІВНО 2
//     спавнять зовнішній бінарник: `k8s_kubeconform.rs`
//     (`Command::new(bin)` на `kubeconform`) і
//     `k8s_manifests_kubescape.rs` (`Command::new(bin)` на
//     kubescape-бінар + `Command::new(kubectl)`). Решта 56 — чистий Rust
//     по тексту/AST/структурі дерева (`fs::read`/serde/regex-подібні
//     перевірки, БЕЗ жодного `std::process::Command` — grep по всьому
//     каталогу `concerns/` це підтверджує). Приклад чистого:
//     `rules_fix::verify::canonical_report` в один рядок обгортає
//     `rules_core::concerns::run_concern("text/forbidden-prettier", ...)`
//     — жодного spawn на всьому шляху.
//   - Тобто відповідь — ОБИДВІ, залежно від concern-а: для 56/58 виміряних
//     native-концернів `verify` МОЖЕ бути wasm-компонентом, що реалізує
//     інтерфейс нижче (жодного `wasi:cli/exec`-подібного імпорту в
//     `verify-plugin` world — компонент фізично не спроможний спавнити
//     процес); для 2/58 (`k8s/kubeconform`, `k8s/manifests` кубескейп-шар)
//     — ні, `verify` для НИХ лишається хостовою інʼєкцією.
//   - Другий нюанс, знайдений при перевірці: `rules_fix::verify::build_verify_fn`
//     компонує канонічний детектор З test-gate
//     (`harness::test_gate::compose_verify_report`, сестринський тест) —
//     а сам test-gate (`test_gate.rs:147`, `Command::new(program)`, типово
//     `bunx vitest run`) теж зовнішній процес. Тобто НАВІТЬ для чисто-Rust
//     детектора складений `verify` ОДНОГО attempt-у може спавнити процес,
//     якщо для торкнутого файлу існує сестринський тест — це властивість
//     КОМПОЗИЦІЇ verify для attempt-у (детектор + test-gate), не самого
//     детектора. Wasm-компонент, що реалізує `verify` нижче, несе ЛИШЕ
//     канонічний детектор-бік; test-gate лишається окремим хостовим
//     кроком композиції (той самий принцип, що T0-аплаєр лишається
//     хостовим для `EditPlan` — §3.9).
//
// Дизайн нижче навмисно НЕ забороняє жодного з двох випадків: хостовий
// реєстр (`crate::registry::PluginRegistry`, `crates/harness`) тримає
// `verify` за ОДНИМ інтерфейсом незалежно від бекенда — `InProcess`
// (сьогодні, для всіх 58) чи майбутній wasm-бекенд (лише для
// тулчейн-незалежних, коли той крок настане).

interface verify {
    use types.{verify-report};

    /// Один прогін канонічної перевірки.
    run: func() -> verify-report;
}

/// World одного verify-компонента: НАВІТЬ `host-fs` не обов'язковий
/// (чисто обчислювальна перевірка може взагалі не читати файли поза тим,
/// що вже передав детектор) — залишений як опційна зручність, не вимога;
/// принципове тут — відсутність БУДЬ-ЯКОГО імпорту, що дав би можливість
/// спавнити процес чи писати файл.
world verify-plugin {
    import host-fs;
    export verify;
}