v0.14.14 - Preset groups + true parallel ref fan-out

🎁 Preset groups + true parallel ref fan-out

Two long-requested features in one release. Both are fully backward-compatible — existing v0.14.13 configs continue to work and are auto-migrated on first use.

---

1. Preset groups (moa.presets + moa.activePreset)

Save multiple full-pipeline configurations as named presets and switch between them with one click. Each preset bundles refs + aggregator + recon + L3 — switching a preset swaps the entire pipeline.

New settings:

• moa.presets (object): Map of { name → { refModels, aggregator, reconModel, l3Summarizer, description? } }
• moa.activePreset (string): Key into moa.presets for the currently active group

New commands:

• MoA: Switch Preset — QuickPick showing all saved presets with a one-line preview (4 refs · agg=GLM-5.2 · recon=DeepSeek · L3=MiniMax-M3). One-click switch, no re-configuration needed.
• MoA: Configure Models (updated) — Now opens with a new Step 0/4 to pick / create / delete a preset group before editing. Steps 1-4 then edit the selected preset.

Backward compatibility:

• Legacy flat config (moa.refModels + moa.aggregator + ...) is auto-migrated to presets.default on extension activation (idempotent).
• Migration shows a one-time notification; legacy fields are NOT deleted (kept as read-only fallback).
• Runtime reads go through a new single-source-of-truth function getActivePresetConfig() in presetConfig.ts, used by both moaRunner.ts and moaOrchestrator.ts.

Typical usage:

• "code" preset: 4 refs + GLM aggregator + DeepSeek recon + MiniMax L3
• "research" preset: 6 refs + MiniMax aggregator + GLM recon + L3 disabled
• "quick" preset: 2 refs + GLM aggregator (no recon, no L3)

---

2. Real parallel ref fan-out (moa.parallelRefs)

Bug: The moa.parallelRefs setting has existed since v0.7.x and was documented as "Fan out reference advisors in parallel", but the code never read it — refs always ran sequentially. Setting parallelRefs: true had no effect.

Fix: Extracted ref execution into a new helper runSingleRef() (atomic, never throws) and the ref prompt body into buildRefPromptBody() (built once, shared by all refs since equal-mode MoA). The Phase 1 loop now has two branches:

• parallelRefs: true (new default) — Promise.allSettled(tasks.map(runSingleRef)). All ref requests fire simultaneously; wall-clock = slowest ref. N refs → theoretical N× speedup. Individual failures don't affect siblings.
• parallelRefs: false — sequential for-await (legacy behavior). Use this if your provider rate-limits concurrent requests.

Default change: moa.parallelRefs default flipped false → true. If you experience cascading 429/5xx errors, set it back to false.

---

Files changed

File	Change
NEW src/presetConfig.ts (~400 LOC)	MoaPreset lifecycle — getActivePresetConfig(), migrateLegacyToPreset(), savePreset(), deletePreset(), setActivePreset(), listPresets()
NEW src/types.ts	MoaPreset interface
src/moaRunner.ts	runSingleRef() + buildRefPromptBody() helpers; parallel/serial Phase 1 branches; preset reads
src/moaConfig.ts	pickOrCreatePreset() Step 0 UI; switchPreset() command
src/moaOrchestrator.ts	resolveModels() uses getActivePresetConfig()
src/l3Summarizer.ts	L3 model ID from preset
src/extension.ts	Registers moa.switchPreset; auto-migration on activate
package.json	2 new settings + 1 new command + version bump + parallelRefs default flip
README.md	5-step flow, Preset groups section, parallelRefs default = true
CHANGELOG.md	v0.14.14 entry
.vscodeignore	Exclude build artifacts (tsc_output.txt, *.bak, eslint.config.mjs, etc.)

---

Install

From Marketplace (recommended):

code --install-extension dudali095.moa-bridge

From this release:
Download moa-bridge-0.14.14.vsix below, then:

code --install-extension moa-bridge-0.14.14.vsix

After install, reload VSCode. If you had a previous MoA config, you'll see a one-time notification that it was migrated to the default preset group.

Full changelog

See CHANGELOG.md for the complete history.

v0.14.13 - README rewrite: clear loop shapes + closed-loop roadmap

📖 README rewrite — clear loop shapes + closed-loop roadmap

Why

User feedback: the original What it does flow diagram suggested a one-shot linear pipeline (recon → refs → aggregator → acting), which hid the existing loop mechanisms and gave no signal about the planned closed-loop direction.

What changed in the README

Path A — @moa chat participant (default, fast)

Now clearly shows the sufficiencyLoop spans Phase 0 ↔ Phase 1 ↔ Phase 1.5 (the original diagram misleadingly put the loop arrow inside Phase 1). Explicitly notes that no feedback paths exist after Phase 3 in the current implementation:

╔══════════════════════════════════════════════════╗
║       sufficiencyLoop  (default 3 rounds)         ║
║  [Phase 0]   Recon agent                          ║
║  [Phase 1]   N refs (parallel)                    ║
║  [Phase 1.5] Sufficiency gate                     ║
║              └── NO (majority insufficient) ──────┄──→ loop back
                  │ YES
[Phase 2]  Aggregator
[Phase 3]  Acting agent  →  final Markdown answer

Path B — #moa_orchestrate LM tool (Hermes-style full closed loop)

Documented as a separate entry point with the complete iteration loop:

║  aggregator emits next_action:                   ║
║    ├─ "recon_needed"        → #moa_continue       ║
║    ├─ "need_more_analysis"  → another iteration   ║
║    └─ "finalize"            → break               ║
║  convergence: completeness ≥ 0.8 or 3 stalled iters or MAX_ITER=12

New Roadmap section (v0.15.0+)

Sketches the design goal of fully LLM-driven closed-loop control:

• Dual-channel signaling: moa_request_more_recon LM tool + <MOA_STATUS> structured output block
• Default mode: LLM-judged — simple questions converge in 1 outer loop, complex ones run 3-5
• Hard guarantees: total char budget, iteration cap, convergence detection (similar missing-hints detection)

Other changes

• Marketplace badge added at top
• Install section: Marketplace is now Option A (recommended), GitHub Release Option B, source Option C
• Release badge updated to v0.14.12

Install

code --install-extension dudali095.moa-bridge

Or update from Extensions panel — v0.14.13 is live on Marketplace.

---

Full changelog: CHANGELOG.md

v0.14.12 - Fix relative path resolution in recon/acting agent

🐛 Bug fix — relative path resolution

Symptom

Recon/acting agent calling copilot_readFile with relative paths like GSEAlens/man/build_gsea_pathways.Rd failed uniformly with ENOENT. The error revealed the path was being resolved against D:\Users\Administrator\AppData\Local\Programs\Microsoft VS Code\ (the VSCode executable directory) instead of the workspace root.

Root cause

VSCode's copilot_* built-in tools resolve relative paths via process.cwd(), which for an extension host process is the VSCode executable directory — NOT the workspace root. The LLM has no way to know this and routinely emits relative paths.

Fix — two layers of defense

1. Tool-input normalization layer (actingAgent.ts):

   • New normalizeToolInput() + resolveRelativeToWorkspace() + isAbsolutePath() helpers (~100 LOC)
   • Intercepts every invokeTool call BEFORE dispatch
   • Rewrites relative path fields (filePath, path, file, includePattern, folder, query, pattern, etc. — 10 fields) to absolute paths
   • Multi-workspace smart matching: if the path's first segment matches a workspace folder name (case-insensitive), resolve against THAT folder. E.g. GSEAlens/man/foo.Rd with a workspace folder named GSEAlens → <workspaceRoot>/GSEAlens/man/foo.Rd
   • Skips glob patterns (*, ?, [, ])
   • Progress log shows every rewrite: [MoA] recon path normalization: filePath: "X" → "Y"

2. Recon system prompt update: added "Path handling (v0.14.12+)" section encouraging the LLM to prefer absolute paths. Defense in depth.

Why this matters

Without this fix, recon against any multi-folder workspace (very common setup) is effectively broken. The LLM has no signal that paths are wrong until ENOENT errors pile up.

Install

code --install-extension dudali095.moa-bridge

Or update from the Extensions panel — v0.14.12 is live on Marketplace.

---

Full changelog: CHANGELOG.md

v0.14.11 - First Marketplace release (publisher: dudali095)

🎉 First Marketplace release

v0.14.11 is the first version published to the public VSCode Marketplace.

Install

From Marketplace (recommended):

code --install-extension dudali095.moa-bridge

Or search "MoA Bridge" in the VSCode Extensions panel.

From this release: download moa-bridge-0.14.11.vsix below, then:

code --install-extension moa-bridge-0.14.11.vsix

Changed

• Publisher changed moa-bridge → dudali095 — registered VSCode Marketplace publisher ID.
• Functional code identical to v0.14.10. The bump is required because Marketplace uses unique <publisher>.<name> identifiers, and the previous placeholder publisher couldn't be used.

---

For full history see CHANGELOG.md.

v0.14.10 — .moa_cache/ self-documentation

What's new

moa-bridge as an open-source plugin that writes into the user's workspace now self-documents those writes at the point of impact.

Added

• src/cacheReadme.ts (new module): exports ensureCacheReadme() — idempotent, atomic write (tmp+rename), fails silently to console.warn
• Three-point integration: every code path that creates .moa_cache/ now calls ensureCacheReadme() on first creation:
  • l3Summarizer.ts::getCacheDir()
  • moaOrchestrator.ts::getCacheRoot()
  • moaRunner.ts::getReconDumpDir()
• Auto-generated .moa_cache/README.md (bilingual, Chinese-primary) covers:
  • Directory layout (recon/ / l3_summaries/ / <task_id>/)
  • Diagnostics (how to trace a weird @moa output; 1213 Part Diagnostics)
  • Cleanup strategies (whole / per-subdir / extract-then-delete)
  • .gitignore recommendation
  • Configuration reference (every moa.* setting that influences writes)
  • Privacy notes

Changed

• Main README: new "Local cache & workspace artifacts" section
• CHANGELOG: filled in v0.14.7-v0.14.9 history (including v0.14.8 YANKED)
• package.json: fixed placeholder repository.url, added homepage/bugs/keywords

Install

code --install-extension moa-bridge-0.14.10.vsix

See CHANGELOG.md for full history.

v0.14.1 — Configure Models UX polish

v0.14.1 — Configure Models UX polish

Install: Download moa-bridge-0.14.1.vsix below, then code --install-extension moa-bridge-0.14.1.vsix.

What's new since v0.13.0

v0.14.1 — Configure Models UX

• Single-select now actually shows checkmarks. VSCode's showQuickPick({ canPickMany: false }) silently ignores the picked field — checkmarks only render with canPickMany: true. Introduced singlePickWithCheckbox<T>() built on createQuickPick + canSelectMany: true with real-time onDidChangeSelection validation:
  • 0 selected → circle-slash icon
  • 1 selected → check icon (confirm enabled)
  • ≥2 selected → warning icon, confirm disabled with inline message
  • Three submit paths wired: Enter key, ✓ button click, onDidAccept.
• Configuration now persists to both User + Workspace tiers by default. saveConfiguration() signature changed from Promise<ConfigurationTarget | null> to Promise<boolean>; iterates [Global, Workspace] targets writing refs/aggregator/reconModel/l3Summarizer to both. Eliminates the previous awkward "which tier?" prompt and the silent precedence issue (User tier cannot override Workspace tier).

v0.14.0 — Recon & L3 model independence

• moa.reconModel config ({ provider, model } or empty): when non-empty, the recon phase uses this model instead of the aggregator. Empty value falls back to aggregator — preserves v0.13.x behavior.
• moa.l3Summarizer config ({ provider, model } or empty): when non-empty, the L3 grandchild agent uses this model. Empty value disables L3 entirely.
• Configure Models expanded to 4 steps: refs (multi) → aggregator (single) → reconModel (single, includes "= aggregator fallback") → l3Summarizer (single, includes "= disabled").

Full Changelog

https://github.com/DDL095/vscode-moa/blob/main/CHANGELOG.md