nubos-pilot 1.1.1 → 1.2.0

package/CHANGELOG.md

@@ -0,0 +1,23 @@
+# Changelog
+
+All notable changes to nubos-pilot are documented in this file. Format
+follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); versioning
+follows [SemVer](https://semver.org/spec/v2.0.0.html).
+
+## [1.1.4] — 2026-05-25
+
+Public release.
+
+- Plan, execute, and verify code changes through a researcher + critic
+  agent loop.
+- Wave-based milestone execution; one atomic git commit per task.
+- Multi-runtime install for 14 host CLIs (Claude Code, Codex, Gemini,
+  OpenCode, Cursor, and more) via `npx nubos-pilot`.
+- Local vector memory for cross-task learnings.
+- Inter-agent messages, handoffs, and project archive with crash-safe
+  resume.
+- Hardened filesystem operations: symlink-rejecting locks, restricted
+  permissions on audit logs, path containment for file-input flags,
+  frontmatter sanitisation, and a memory-model allow-list.
+
+Full documentation at <https://pilot.nubos.cloud>.

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Nubos AI
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -5,7 +5,7 @@ AI-driven planning and execution tool for code projects. Installs into 14 host C
 - **No daemon.** Every command runs as a short-lived `node` invocation.
 - **Markdown-first.** Workflows and agents are plain `.md` files — the host reads them directly.
 - **Atomic per-task commits.** One `task(M<NNN>-S<NNN>-T<NNNN>): …` commit per unit of work. `/np:undo-task` and `/np:undo` are mechanical reverts.
-- **Multi-runtime.** One source tree, one install payload, four first-class host CLIs.
+- **Multi-runtime.** One source tree, one install payload, fourteen supported host CLIs.
 
 ## Install
 
@@ -95,16 +95,18 @@ task(M001-S001-T0002): wire login handler
 
 ## Agents
 
-Eleven subagents are installed into the host's agent directory:
+Thirteen spawnable subagents are installed into the host's agent directory (alongside three `np-critic-*` audit modules consumed by `np-critic`):
 
 - `np-planner` (opus) — breaks a milestone into slices + tasks
 - `np-plan-checker` (opus) — adversarial goal-backward review before execution
 - `np-architect` (sonnet) — optional ADR-style decisions before planning
 - `np-researcher` (sonnet) — milestone-level stack + pitfalls research
+- `np-researcher-reconciler` (sonnet) — reconciles disagreements across researcher-swarm outputs
 - `np-sc-extractor` (haiku) — derives observable Success Criteria from goal + CONTEXT
 - `np-codebase-documenter` (sonnet) — maintains `.nubos-pilot/codebase/` module docs
 - `np-executor` (sonnet) — one task per spawn, one commit per task
 - `np-build-fixer` (sonnet) — recovery patcher for executor verify failures (manual spawn)
+- `np-critic` (sonnet) — Nubosloop critic; audits executor output across style, tests and acceptance
 - `np-verifier` (sonnet) — post-execution Pass/Fail/Defer per success_criterion
 - `np-nyquist-auditor` (haiku) — requirement test-coverage audit
 - `np-security-reviewer` (sonnet) — OWASP-aligned read-only audit (manual spawn)
@@ -113,7 +115,7 @@ Every spawn runs with an **explicit tier** (`haiku` / `sonnet` / `opus`) resolve
 
 ## Model profile
 
-Five profiles (`frontier`, `quality`, `balanced`, `budget`, `inherit`) map each tier (`haiku` / `sonnet` / `opus`) to a concrete model. Set at install time (`Model-Profile?` prompt) or in `.nubos-pilot/config.json`. Full matrix in `docs/agent-frontmatter-schema.md`.
+Five profiles (`frontier`, `quality`, `balanced`, `budget`, `inherit`) map each tier (`haiku` / `sonnet` / `opus`) to a concrete model. Set at install time (`Model-Profile?` prompt) or in `.nubos-pilot/config.json`.
 
 ## Requirements
 
@@ -131,11 +133,11 @@ node np-tools.cjs help           # JSON: { commands: [ { name, category, descrip
 ## Doctor
 
 ```bash
-npx nubos-pilot doctor           # 6-check integrity scan
+npx nubos-pilot doctor           # 12-check integrity scan
 npx nubos-pilot doctor --fix     # auto-fix what's safely fixable
 ```
 
-Checks: payload manifest integrity, version mismatch, hooks presence, codex-toml sanity, askuser runtime availability, codebase docs freshness, milestone/slice directory layout.
+Checks: payload manifest integrity, version mismatch, hooks presence, codex-toml sanity, askuser runtime availability, codebase docs freshness, milestone/slice directory layout, the three Nubosloop checks (critics present, knowledge store, config), orphan temp files, and output schemas.
 
 ## Development
 
@@ -144,6 +146,35 @@ npm test                         # all unit tests via node:test
 node bin/check-workflows.cjs     # workflow linter
 ```
 
+See [`CONTRIBUTING.md`](./CONTRIBUTING.md) for setup, code conventions, ADR
+map and commit format.
+
+## Architecture Decisions
+
+ADRs live in the VitePress at
+[`pilot.nubos.cloud/v1/adr/`](https://pilot.nubos.cloud/v1/adr/). The
+load-bearing ones for users and contributors:
+
+| ADR | What it pins |
+|---|---|
+| 0004 | `workflow.commit_artifacts` controls whether `.nubos-pilot/` is committed |
+| 0010 | Nubosloop — researcher → executor → critic-schwarm is mandatory in `/np:execute-phase` |
+| 0012 | Completeness doctrine (12 rules in `templates/COMPLETENESS.md`) |
+| 0013 | Learnings-store schema evolution |
+| 0017 | Strict output-schema enforcement |
+| 0019 | Plan-side trust layer (`lib/plan-lint.cjs`) |
+
+## Security
+
+See [`SECURITY.md`](./SECURITY.md) for the vulnerability disclosure policy
+and threat model.
+
+## Support
+
+- Bugs / features: [GitHub issues](https://github.com/Nubos-AI/nubos-pilot/issues)
+- Security: `security@nubos.ai` (see [`SECURITY.md`](./SECURITY.md))
+- Docs: <https://pilot.nubos.cloud>
+
 ## License
 
-MIT
+MIT — see [`LICENSE`](./LICENSE).

package/SECURITY.md

@@ -0,0 +1,60 @@
+# Security Policy
+
+## Reporting a Vulnerability
+
+If you discover a security issue in nubos-pilot, **do not open a public issue**.
+Email **security@nubos.ai** with:
+
+- A description of the issue and its impact.
+- Steps to reproduce (PoC if possible).
+- The affected version (`npx nubos-pilot --version` or check `package.json`).
+- Your preferred contact channel for follow-up.
+
+We will acknowledge receipt within **3 business days** and provide a
+resolution plan within **14 business days**. Fixes are released as patch
+versions and announced in `CHANGELOG.md`.
+
+## Supported Versions
+
+| Version | Supported |
+|---------|-----------|
+| 0.2.x   | ✅ active |
+| < 0.2   | ❌ end of life |
+
+Only the latest minor on the current major receives security patches until
+1.0 is reached.
+
+## Threat Model
+
+nubos-pilot is a **local CLI** distributed via npm to developer workstations
+and CI. It is **not** a hosted service. The threat surface and assumptions:
+
+| What nubos-pilot reads | What it writes | What it executes |
+|---|---|---|
+| `.nubos-pilot/`, project source for context | `.nubos-pilot/` state, `~/.codex/`, `~/.claude/` config (install only) | `git`, `claude`/`codex` headless via `child_process.spawn` |
+
+**Trust boundaries:**
+
+- **Project source code** — untrusted in the sense that agent-authored
+  files (`PLAN.md`, `RESEARCH.md` etc.) may contain hostile YAML. nubos-pilot
+  rejects prototype-pollution keys, refuses symlink-escape via `safe-path`,
+  caps message bodies, and whitelists ML model identifiers.
+- **`.nubos-pilot/messages/`** — multi-agent inbox; entries are written
+  atomically with `O_CREAT|O_EXCL|O_NOFOLLOW` (POSIX) so a pre-planted
+  symlink cannot redirect writes.
+- **Subprocess spawn** — `claude`/`codex` are invoked via `spawnSync` (no
+  shell). The binary path is overridable via `NUBOS_PILOT_CLAUDE_BIN` /
+  `NUBOS_PILOT_CODEX_BIN`; treat operators who can set those env vars as
+  trusted.
+- **`workflow.commit_artifacts`** flag controls whether `.nubos-pilot/`
+  artifacts are committed to git. Default is `true`; downstream projects
+  that consider artifacts sensitive should set it to `false`.
+
+## What is Out of Scope
+
+- Vulnerabilities in `@huggingface/transformers`, `usearch`, or the
+  `yaml` package — report those upstream.
+- Operator-controlled config (`config.json`) that the operator themselves
+  wrote — config is trusted input from the project owner.
+- DoS from running nubos-pilot in obviously bad conditions
+  (no disk space, no Node 22+, broken `git`).

package/agents/np-architect.md

@@ -70,7 +70,7 @@ If the project already documents a module/pattern that fits, extend it instead o
 
 ## Output Contract
 
-**Granularity (ADR-0013).** Architecture decisions are intent-level: which library, which boundary, which protocol. They do NOT prescribe implementation — no schema DDL, no exact framework-generated filenames, no code-style edicts. Those are executor-territory and downstream `np-planner` will refuse plans that bake them in (Plan-side Trust Layer, ADR-0013). If you find yourself describing how a controller method should be structured, stop — that's not architecture.
+**Granularity (ADR-0019).** Architecture decisions are intent-level: which library, which boundary, which protocol. They do NOT prescribe implementation — no schema DDL, no exact framework-generated filenames, no code-style edicts. Those are executor-territory and downstream `np-planner` will refuse plans that bake them in (Plan-side Trust Layer, ADR-0019). If you find yourself describing how a controller method should be structured, stop — that's not architecture.
 
 ```markdown
 # M<NNN> — <milestone name> — Architecture

package/agents/np-build-fixer.md

@@ -58,9 +58,9 @@ The orchestrator provides these in your prompt context. Read every path it hands
    - `infra` (missing tool, network, env var) → STOP and emit `## INFRA BLOCKER` block; do not edit source.
 1a. **MANDATORY knowledge lookup (Rule 9 — non-optional, runs before any Edit).** Pick the failing symbol or error class from Step 1 and run:
     ```bash
-    node .nubos-pilot/bin/np-tools.cjs knowledge-search "<failing-symbol-or-error-class>" --limit 5
+    node .nubos-pilot/bin/np-tools.cjs knowledge-search "<failing-symbol-or-error-class>" --task <task-id> --limit 5
     ```
-    If a hit lives in `.nubos-pilot/codebase/<module>.md`, `Read` that doc before patching. Skipping this step stamps `rule-9-violation` in the Layer-C audit log and the loop routes back to the researcher swarm next round — it is **not** an opt-out.
+    The `--task <task-id>` flag is required: it records the Rule 9 evidence the tool-use audit cross-checks. A `knowledge-search` run without it leaves no ledger entry, so the audit treats the spawn as if it never searched (`rule-9-search-tool-unverified`). If a hit lives in `.nubos-pilot/codebase/<module>.md`, `Read` that doc before patching. Skipping this step stamps `rule-9-violation` in the Layer-C audit log and the loop routes back to the researcher swarm next round — it is **not** an opt-out.
 2. **Locate the failure surface** strictly inside `files_modified`. If the failure points outside that set, emit `## SCOPE EXPANSION REQUEST` and stop — do NOT edit out-of-scope files.
 3. **Propose the smallest patch** that addresses the root cause:
    - For `compile` / `lint`: edit the offending file directly.
@@ -72,10 +72,10 @@ The orchestrator provides these in your prompt context. Read every path it hands
 
 ## Mandatory Knowledge Lookup (Rule 9)
 
-**This is non-optional, not advisory.** Workflow Step 1a runs the lookup before any Edit. Skipping it stamps `rule-9-violation` in the audit log and forces a re-route to the researcher swarm.
+**This is non-optional, not advisory.** Workflow Step 1a runs the lookup before any Edit. Skipping it — or running it without `--task` — stamps `rule-9-violation` in the audit log and forces a re-route to the researcher swarm.
 
 ```bash
-node .nubos-pilot/bin/np-tools.cjs knowledge-search "<failing-symbol>" --limit 5
+node .nubos-pilot/bin/np-tools.cjs knowledge-search "<failing-symbol>" --task <task-id> --limit 5
 ```
 
 If a hit lives in `.nubos-pilot/codebase/<module>.md`, `Read` that doc before patching. Cross-task context belongs in `RULES.md` and `M<NNN>-CONTEXT.md`.

package/agents/np-executor.md

@@ -31,7 +31,7 @@ This agent operates under [`templates/COMPLETENESS.md`](../templates/COMPLETENES
 - **Rule 3 — Do it with tests.** Every commit ships tests for the production code it adds or changes. No "trivial enough to skip tests" exceptions.
 - **Rule 4 — Do it with documentation.** Update `.nubos-pilot/codebase/<module>.md` after every commit (`update-docs` is mandatory, not optional).
 - **Rule 7 — Never leave a dangling thread.** Dead imports, unused symbols, half-renamed identifiers — clean them up in the same commit that introduces the change.
-- **Rule 9 — Search before building.** Run `knowledge-search` for the symbols you plan to introduce before writing them. Reuse beats reinvention.
+- **Rule 9 — Search before building.** Before writing any new symbol, run `node np-tools.cjs knowledge-search "<symbol>" --task <task-id>` via Bash. The `--task <task-id>` flag is mandatory — it records the evidence the Rule 9 tool-use audit cross-checks; a lookup without it counts as no search. Reuse beats reinvention.
 - **Rule 10 — Test before shipping.** Verify must be green before you call `commit-task`. Manual "I ran it once" is not proof of work.
 
 Refusal of any rule is a hard-stop. Surface the violation to the orchestrator verbatim and abort the spawn.

package/agents/np-plan-checker.md

@@ -28,7 +28,7 @@ Refusal of any rule is a hard-stop. Surface the violation to the orchestrator ve
 
 ## Role
 
-Adversarial reader of milestone plans. You assume the planner made mistakes and look for them systematically. You enforce the canonical finding-category taxonomy published in `docs/agent-frontmatter-schema.md` — every issue you emit MUST use one of those codes verbatim.
+Adversarial reader of milestone plans. You assume the planner made mistakes and look for them systematically. You enforce the canonical finding-category taxonomy defined below — every issue you emit MUST use one of those codes verbatim.
 
 You are NOT the executor (`/np:execute-phase`) and NOT the post-execution verifier (`/np:validate-phase`). You verify plans WILL work before execution; the verifier confirms code DID work after execution. Same goal-backward methodology, different timing.
 
@@ -53,7 +53,7 @@ Additional context the orchestrator may inline in the prompt:
 
 ## Review Dimensions
 
-Each dimension maps to one or more canonical finding categories from `docs/agent-frontmatter-schema.md`. The 14 canonical codes are:
+Each dimension maps to one or more canonical finding categories. The 14 canonical codes are:
 
 - `missing-success-criterion` — a ROADMAP SC-X is not mapped to any task.
 - `non-atomic-task` — a task bundles multiple distinct deliverables that should be split.
@@ -66,9 +66,9 @@ Each dimension maps to one or more canonical finding categories from `docs/agent
 - `hook-field-present` — agent frontmatter contains `hooks:` (D-10).
 - `forbidden-agent-field` — agent frontmatter contains `model:` or `model_profile:` (D-10).
 - `unverified-assumption` — a slice plan's `<reality_check>` block is missing, empty, or contains an `<assumption>` without a non-empty `verified_by` attribute, OR a `<files_read>` path does not exist in the repo (Reality-Check rule, see Dimension 12).
-- `verify-command-unknown` — a `<verify>` block invokes a command that is not a known np-tools verb, declared composer/npm script, vendor binary, or POSIX baseline tool (Plan-side Trust Layer, ADR-0013). Mechanically detected by `np-tools.cjs plan-lint`; you mirror the verdict into your findings array so the loop handler treats it uniformly with semantic findings.
-- `parallel-task-implicit-dependency` — tasks marked `depends_on: []` in the same slice but one of them runs a working-tree-reading verify (`update-docs`, `phpstan analyse`, `git diff`, etc.) against files another sibling modifies. Implicit ordering must be made explicit (Plan-side Trust Layer, ADR-0013).
-- `plan-over-specifies-implementation` — PLAN.md body contains schema DDL, framework-controlled timestamped filenames, or large inline code snippets. Plans specify intent + boundary + acceptance, not implementation. Severity is `major` (advisory) — not a hard block, but you flag it so the planner course-corrects (Plan-side Granularity Doctrine, ADR-0013).
+- `verify-command-unknown` — a `<verify>` block invokes a command that is not a known np-tools verb, declared composer/npm script, vendor binary, or POSIX baseline tool (Plan-side Trust Layer, ADR-0019). Mechanically detected by `np-tools.cjs plan-lint`; you mirror the verdict into your findings array so the loop handler treats it uniformly with semantic findings.
+- `parallel-task-implicit-dependency` — tasks marked `depends_on: []` in the same slice but one of them runs a working-tree-reading verify (`update-docs`, `phpstan analyse`, `git diff`, etc.) against files another sibling modifies. Implicit ordering must be made explicit (Plan-side Trust Layer, ADR-0019).
+- `plan-over-specifies-implementation` — PLAN.md body contains schema DDL, framework-controlled timestamped filenames, or large inline code snippets. Plans specify intent + boundary + acceptance, not implementation. Severity is `major` (advisory) — not a hard block, but you flag it so the planner course-corrects (Plan-side Granularity Doctrine, ADR-0019).
 
 Note on the Nubosloop critic: as of 2026-05-05 a single `np-critic` agent covers style + tests + acceptance in one spawn (ADR-0010 §Single-Critic Revision). The legacy three-critic schwarm (`np-critic-style`/`np-critic-tests`/`np-critic-acceptance`) is removed. References in older plans should be updated.
 

package/agents/np-planner.md

@@ -277,7 +277,7 @@ Every PLAN.md you write will be consumed by an executor agent that:
 **Implications for your writing style:**
 
 - **Name the library, not the category.** "Use `jose` for JWT" > "use a JWT library".
-- **Name the file, not the area** — for *deterministic edits the planner can know up-front*. "Modify `src/api/auth/login.ts`" > "update the auth layer". For *scaffolding tasks where a framework generates files at install/publish time*, use a glob (`database/migrations/*_cashier_*.php`) or leave `files_modified` empty — the executor resolves the real paths from the actual publish output and `commit-task` falls back to `checkpoint.files_touched` (D-04, ADR-0013 Layer-D Granularity).
+- **Name the file, not the area** — for *deterministic edits the planner can know up-front*. "Modify `src/api/auth/login.ts`" > "update the auth layer". For *scaffolding tasks where a framework generates files at install/publish time*, use a glob (`database/migrations/*_cashier_*.php`) or leave `files_modified` empty — the executor resolves the real paths from the actual publish output and `commit-task` falls back to `checkpoint.files_touched` (D-04, ADR-0019 Layer-D Granularity).
 - **Name the command, not the intent.** "Run `npm test -- --filter=auth`" > "run the tests".
 - **Cite existing interfaces verbatim.** If `lib/core.cjs` exports `NubosPilotError(code, message, details)` — quote that signature in the task context so the executor doesn't mis-remember.
 - **Document deviations from canonical advice.** If you deviate from CONTEXT.md's stack choice, say so explicitly and note why.
@@ -286,7 +286,7 @@ If the executor has to stop and read three more files to figure out what you mea
 </downstream_awareness>
 
 <plan_granularity>
-## Plan Granularity Doctrine — Intent + Boundary + Acceptance, NOT Implementation (ADR-0013)
+## Plan Granularity Doctrine — Intent + Boundary + Acceptance, NOT Implementation (ADR-0019)
 
 A PLAN.md is a contract. It specifies **what** must be true at the end (intent), **where** the work is allowed to touch (boundary), and **how** success is measured (acceptance). It does NOT specify HOW the implementation looks. That's the executor's territory; you don't have ground-truth on it and pretending you do is the bug class that produced the M004 plan-bugs.
 

package/agents/np-researcher.md

@@ -24,7 +24,7 @@ Your output is prescriptive, not exploratory: "Use library X at version Y" beats
 This agent operates under [`templates/COMPLETENESS.md`](../templates/COMPLETENESS.md). The rules that bind this role:
 
 - **Rule 5 — Aim to genuinely impress.** Prescriptive beats exploratory. "Use `jose@6.0.10`" beats "consider a JWT library". Vague research produces vague plans, vague plans produce vague software.
-- **Rule 9 — Search before building.** This is your core job. Before any new claim, search the local knowledge index (`knowledge-search`), the codebase docs (`.nubos-pilot/codebase/`), and Context7 / WebFetch. Reuse prior learnings.
+- **Rule 9 — Search before building.** This is your core job. Before any new claim, search the local knowledge index via `node np-tools.cjs knowledge-search "<query>"` (pass `--task <task-id>` when spawned inside the execute-loop so the Rule 9 audit ledger records the call), the codebase docs (`.nubos-pilot/codebase/`), and Context7 / WebFetch. Reuse prior learnings.
 - **Rule 11 — Ship the complete thing.** RESEARCH.md is a deliverable, not a draft. Every claim has provenance, every assumption is tagged `[ASSUMED]`, every gap is listed in `Open Questions`. No half-research.
 
 Refusal of any rule is a hard-stop. Surface the violation to the orchestrator verbatim and abort the spawn.
@@ -37,7 +37,7 @@ Your per-spawn output MUST conform to the **`researcher-output`** schema. The or
 
 Hard rules from the schema:
 
-- Frontmatter must include `schema_version`, `agent: np-researcher`, `spawn_index`, `seed_delta`, `task_query_hash`, plus count fields (`decision_count`, `risk_count`, etc.).
+- Frontmatter must include `schema_version`, `agent: np-researcher`, `spawn_index`, `seed_delta`, `task_query_hash`, plus count fields (`decision_count`, `risk_count`, etc.). `spawn_index` and `seed_delta` are **integers** — copy them verbatim from the `index` / `seed_delta` fields of your spawn spec. The prose perspective nudge arrives on the spawn spec's separate `seed_nudge` field; it shapes HOW you investigate and never goes into frontmatter.
 - Five body sections are pflichtig (use `_None._` if empty): `## Decisions`, `## Risks`, `## Patterns`, `## Open Questions`, `## Sources`.
 - Every Decision / Risk / Pattern / Open Question / Source uses heading style `### <PREFIX>-N: <text>` where PREFIX ∈ {D, R, P, Q, S}.
 - **Every entry has a `**Reasoning:**` field** (mandatory). The Reasoning field documents what you weighed, what you discarded, and why this conclusion. The reconciler compares `Reasoning` traces across spawns to detect groupthink (identical reasoning → low independent evidence) vs orthogonal evidence (different reasoning paths to same conclusion → strong signal).

package/bin/check-workflows.cjs

@@ -66,8 +66,6 @@ function _scanMetricsCoverage(files) {
     const raw = fs.readFileSync(file, 'utf-8');
     const lines = raw.split(/\r?\n/);
 
-    
-
     let inAnyFence = false;
     let inBashFence = false;
     for (let i = 0; i < lines.length; i++) {
@@ -102,10 +100,6 @@ function _scanMetricsCoverage(files) {
   return warnings;
 }
 
-function _scan(dir) {
-  return _scanFiles(_walk(dir, [], { ext: ['.md'] }));
-}
-
 function _scanInstallerSurface(cwd) {
   const root = cwd || process.cwd();
   const files = [];
@@ -131,7 +125,7 @@ function checkWorkflows(dir) {
       violations.push(..._scanFiles(workflowFiles));
       warnings.push(..._scanMetricsCoverage(workflowFiles));
     }
-  } catch {  }
+  } catch {}
   violations.push(..._scanInstallerSurface());
   return { violations, warnings, exitCode: violations.length ? 1 : 0 };
 }
@@ -158,7 +152,6 @@ if (require.main === module) main();
 
 module.exports = {
   checkWorkflows,
-  _scan,
   _scanFiles,
   _scanInstallerSurface,
   _scanMetricsCoverage,